building KF5 projects against a different Qt5 version (than the one the KF5 frameworks were built against)

[René J.V. Bertin]

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.

>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...

>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)?
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. Allowing code to include only the exact few headers it needs is nice, but is there a reason to disallow code from doing the opposite if it wants to shorten the list of #includes?

>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. KDevelop doesn't include the flag in its options for the clang-based parser.