detect the Qt version KF5 frameworks were built against in CMake?

[René J. V. Bertin]

Friedrich W. H. Kossebau wrote:

> Can you specifiy some more what you mean by "pull in"?

Adding indirect dependencies of the target framework needed for it to link 
successfully, as you deduced below.

> It also assumes you use compatible build flags for Qt and do not have e.g.

Of course, the usual "all other things being equal" (or at least compatible).

> find_package(KFFoo). Those ensure that required dependencies for the public
> interface are found as well, by having lines like
> 
> find_dependency(Qt5Core "5.9.0")

Those aren't required on all platforms, btw; on Mac you can leave those out 
(possibly because dependencies on shared libraries are registered with the full 
path to said dependency).

> This find_dependency() call will find whatever Qt is to be found first in the
> environment where find_package(KF5Foo) is called. So not necessarily the Qt
> installation which was used to build KF5Foo.

Hmmm, direct calls of the type `find_package(qt5 ...)` in the project cmake files 
do indeed find the Qt version I'm trying to build against. But I still end up 
with references to Qt components that I am not using directly, those can only 
come from KF5 framework dependencies.

CMake should find the requested Qt components in the intended version, indeed. 
Apparently it doesn't, and Qt5 cmake files evidently reference only resources 
from the version (install) to which they belong.

BTW, the problem here is not so much with libraries but with headers.

> Talking about, this actually could be also wrong sometimes, both in case
> someone accidentally combines an older, yet old enough for the minimum Qt
> version, which would fail only at link/load time then if symbols only
> available in the newer Qt version had been used before.

I don't really want to do that mind exercise :) but I think it wouldn't hurt to 
set a CMake constant containing the Qt version against which a framework was 
built.

> And the question would be, what is your actual case you need the info for?

What I am doing ATM can be compared to simulating a Qt5 upgrade (using an "out-
of-prefix" Qt install) without rebuilding all frameworks, and then rebuilding a 
3rd party application that uses some KF5 frameworks.

> version was build against. So perhaps your need could/should be solved some
> other way.

Not wrong. The actual thing that I was tinkering with that led to this question 
was simulating a *downgrade* (rather, I wanted to check if some issue occurred 
with Qt 5.8 as it does with Qt 5.9). The software where the link failure 
occurred builds against Qt 5.8 so I was very surprised when I saw that a 
QT_VERSION > 5.8 test succeeded. It is then that I saw noticed the -I arguments 
pointing to my Qt 5.9 install, for components like QtNetwork only used in the 
framework dependencies, not in the code I was building.
I did try to include qglobal.h hoping it would be found in the target Qt 
directory, but no such luck.

Of course this is not officially supported, bound to fail at runtime, so I gave 
up and disabled the part of the build depending on KDE. But the question seemed 
valid.

An equivalent error as the one I was seeing could arise when the (say) Qt 5.9 
version of the code uses a deprecated method no longer available in (say) Qt 
5.12. Just like in my case the QT_VERSION check ended up using a function from 
the *newer* Qt version (= the one used to build the KF5 frameworks), the 
QT_VERSION test could also go awry and use a deprecated method no longer 
available in Qt 5.12 .