The setup:
- build Qt with '-static -qt-zlib'
- configure a user project with plain cmake and -DQt6_DIR pointing to
the Qt6 package
In this case, the implicit find_dependency(BundledZlib) call will
fail with:
CMake Error at lib/cmake/Qt6/QtFindWrapHelper.cmake:120 (message):
Can't find Qt6::BundledZLIB.
Call Stack (most recent call first):
lib/cmake/Qt6/FindWrapZLIB.cmake:6 (qt_find_package_system_or_bundled)
cmake/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76
(find_package)
lib/cmake/Qt6/QtPublicDependencyHelpers.cmake:36 (find_dependency)
lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:39
(_qt_internal_find_third_party_dependencies)
lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include)
lib/cmake/Qt6/Qt6Config.cmake:233 (find_package)
CMakeLists.txt:7 (find_package)
For example it would fail for the rasterwindow example configured with:
cmake ~/qtbase/examples/gui/rasterwindow \
-DQt6_DIR=$HOME/builds/dev-mac-static/qtbase/lib/cmake/Qt6
The failure happens because we don't pass any additional paths to the
find_package call that looks for BundledZlib, as opposed to how we do
it for module packages.
The project configuration does not fail if it is configured with any
of the following variables:
- Qt6_ROOT or
- CMAKE_PREFIX_PATH or
- the Qt generated toolchain file.
That's because these implicitly add relevant paths where to look for
Qt packages.
This came up in qtdeclarative RunCMake CI tests, where we only pass
Qt6_DIR to the test projects. It didn't come up in qtbase, because
none of the current qtbase RunCMake tests try to find Qt6Core.
To fix this particular case, conditionally pass the same paths that
Qt6Config.cmake uses when looking for module packages, to the
find_package call that looks for the bundled target.
We do it conditionally for bundled targets only, because for system
libraries we want to default looking for the module
FindWrapSystemFoo.cmake files.
Add a RunCMake test which will try to find a few Qt modules solely
based on having only Qt6_DIR set.
Pick-to: 6.8 6.9
Change-Id: I4d4e548f4c10370c4964ab8968b5772e26855dd4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The QtFindWrapHelper.cmake file retrieves the version of the
underlying system package version or bundled package version, and
passes that to find_package_handle_standard_args to show which version
was found.
But it did not set a ${PACKAGE_NAME}_VERSION variable, which means
we didn't record the version in qt_find_package, and thus in the final
SBOM.
Make sure we set the variable.
Amends 7ad8c347feb5e336c3833d6d3ac021a0a14b714a
Pick-to: 6.8
Change-Id: Ia0d5b895de36017949e6607d17093459dca302b3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The QtFindWrapHelper include used in FindWrap scripts can choose to
call find_package() on one of two packages. The packages might set a
VERSION variable. We should set the same version for the FindWrap
package as well.
There are two sources where the version will be queried from. First
from the underlying ${package_name}_VERSION variable.
And if that is empty, from a property that is set by qt_find_package()
The former might be empty because find_package might be called from
a function instead of a macro, which is the case for any find_package
call in configure.cmake files that get loaded by the
qt_feature_evaluate_features function.
Thus we need the indirection via the property that qt_find_package
will set.
Change-Id: I57fd818cb9dedf5e27a6d805e3d817d8d18be36d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously the FindWrap modules checked for hardcoded features
when deciding whether to use a bundled library or not. This proved
not to work correctly because features were not available when
the find modules were processed.
Introduce a new CMake API call that needs to be manually called
after an add_subdirectory call which declares a bundled library.
The call will check for the existence of the bundled target, and will
then set a cache variable QT_USE_BUNDLED_Bundled<TargetName>.
The same variable is written into a FindWrapFooConfigExtra.cmake file
which will be loaded by the appropriate FindWrap module. The module
can that use that variable to decided whether to link against the
bundled library or the system library.
Change-Id: I75e9a4f4e14d88d4490916a79ad12f1ce57891e0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
A few things are needed to accomplish that:
- the python scripts do not ignore certain system_foo features anymore
(it is a hardcoded list for now just to be safe)
- configurejson2cmake now outputs
qt_find_package(WrapSystemFoo) calls for bundled libraries
(see below)
- the harfbuzz .pro file is modified to accommodate pro2cmake
not being able to correctly parse some conditional scopes
- the freetype .pro file is modified to make sure linking of the
library succeeds without duplicate symbol errors, which qmake
doesn't encounter due to magical exclusion of cpp files that are
included in other cpp files (presumably for include moc_foo.cpp
support)
- feature evaluation for Core, Gui, Network now happens in the
qtbase/src directory, so that bundled libraries can be conditionally
built
- for each bundled library there are now two FindWrap scripts:
- FindWrapSystemFoo which finds an installed library in the system
- FindWrapFoo which either uses the system installed library or
the built bundled one depending on a condition
- projects that intend to use bundled libraries need to link against
WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets
(this is handled by pro2cmake).
Unfortunately manually added qt_find_package(WrapFoo) calls might
still be needed as is the case for WrapFreetype and others.
- a new cmake/QtFindWrapHelper.cmake file is added that provides
a macro to simplify creation of WrapFoo targets that link against
a bundled or system library. The implementation is fairly ugly
due to CMake macro constraints, but it was deemed better than
copy-pasting a bunch of almost identical code across all
FindWrapFoo.cmake files.
- a qtzlib header-only module is now created when using bundled
zlib, to provide public syncqt created headers for consumers
that need them. These are projects that have
'QT_PRIVATE += zlib-private' in their .pro files
(e.g. qtimageformats, qtlocation, qt3d, etc.)
This is unfortunately needed due to QtNetwork using zlib
types in its private C++ API.
The change includes support for building the following bundled
libraries:
- zlib
- libpng
- libjpeg
- Freetype
- Harfbuzz-ng
- PCRE2
The following 3rd party libraries are still using an old
implementation within the CMake build system, and should be migrated
to the new one in the near future:
- double-conversion
- Old harfbuzz
The are a few libraries that are not yet ported:
- system-sqlite
- systemxcb
- maybe others
Among other things, this change allows building qtbase on Windows
without requiring vcpkg.
Task-number: QTBUG-82167
Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
