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
