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

[Friedrich W. H. Kossebau]

Am Mittwoch, 28. August 2019, 19:19:21 CEST schrieb René J.V. Bertin:
> Hi,
> 
> Some KF5 framework libraries pull in Qt5 headers and/or libraries via their
> CMake modules, right?

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

> Take the somewhat unusual situation where you have your KF5 frameworks built
> against, say, Qt 5.9 from the system and you want to test an application
> against a different, newer Qt build installed with Qt's installer. Qt
> guarantees this should work as long as you don't use private APIs. 

It also assumes you use compatible build flags for Qt and do not have e.g. 
different feature flags like for deprecated methods or things like D-Bus or 
other flags which affect symbol names, e.g. Qt namespacing.

> Those
> aforementioned KF5 frameworks will pull in "their" Qt5 headers (e.g. for
> Qt5Network in the project I'm tinkering with), meaning that QT_VERSION
> #ifdefs can behave in an unexpected way.

This sounds like you are talking about "pulling in" at build time, right?
KF modules install CMake config files to be found via cmake's 
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")

where the number is generated at build time of the KF5Foo module, taken 
usually from the min version variable via @@ substitution from a templare 
file.
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.

> Is there a way to detect this kind of situation at the cmake level, i.e. is
> there some constant that holds the Qt value the frameworks were built
> against?

Not that I am aware, the installed CMake config files currently just forward 
which minimum version would be expected at build time.

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.

Or in the case of relying on private Qt symbols, even if in non-published API, 
the CMake config file should actually require the exact version already from 
the start, to also catch unexpected surprises at link/load time.
E.g. by adding "EXACT" to the find_dependency call, with the very version 
found and used at build time:

CMakeLists.txt:
set(USED_QT_VERSION ${Qt5Core_VERSION})

KF5XmlGuiConfig.cmake.in:
find_dependency(Qt5Core @USED_QT_VERSION@ EXACT)

Guess we should change things at least for those KF modules using private Qt 
symbolds, will do and prepare some patches for review and discussion.
This should also improve things for KDE CI when bumping installed Qt versions 
and wondering why some things might fail when reusing previously built 
binaries.

So for the actual question, how to know which Qt version a KF module was build 
again, I think there is no direct info to query.

And the question would be, what is your actual case you need the info for?
In general any variant of the API should be queryable directly by properties 
of the build system or config.h files, not indirectly over knowing which Qt 
version was build against. So perhaps your need could/should be solved some 
other way.

Cheers
Friedrich