On Sunday, April 26, 2020 4:32:46 PM CEST René J.V. Bertin wrote: > On Sunday April 26 2020 15:46:35 David Faure wrote: > >Well, yeah, you can't have it all. > > I suppose that the appropriate ECM could provide a function that returns the > path to the "official" Qt headers (or an expression that evaluates to that > path) unless something like QT_HEADER_PATH is defined. Idem for linker > paths. Of course then individual frameworks would still accept to use those > functions.
None of that would work with imported targets. > >Or, you can, but you need two full builds. > > Yeah, I don't think that what I was trying is important enough to warrant > the investment that comes with having another build... Your choice. > >There's no such central header in KF5 frameworks (which are more modular, > >by definition), so you need to include the framework_version.h header. > > Don't you think it'd make sense to expect the version to be defined if you > include the KFoo header if framework Foo provides one (I count 17 that do, > among the 60+ frameworks I installed)? No. There's no "main header" concept. As you say, this would only work for 17/60 frameworks anyway, not really a good solution. > As a side-note, I'd even argue that > it would make sense to provide an all-inclusive header per framework, just > like Apple's frameworks do. It's said to improve compilation times with precompiled headers, but in practice nobody knows if the person compiling the code has that, so I fail to see the point. Who needs all of <KCoreAddons>? Nobody. > >We have -Wundef by default. > > Yes, in the compiler settings, which is why I caught the FOO_VERSION not > defined thing purely by chance rather than because of unexpected behaviour > at runtime. I wouldn't call this "purely by chance". I set -Wundef there for a reason :-) > KDevelop doesn't include the flag in its options for the > clang-based parser. OK, talk to the KDevelop people then :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
