Such a case can happen when cross-compiling. Tools currently are not
built when cross-compiling, so if the desktop tool was not built,
accessing properties on that target would fail when trying to set up
the documentation building.
Change-Id: I2ffcbb9623df3e4daacdf4be3f48c4b2dd13851b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QT_STATIC must be defined for static builds to have the right
import/export symbol macros defined. Originally, this macro is wrapped
in a condition. That's why we extend qt_feature_definition to be able
to write a prerequisite to qconfig.h.
Change-Id: I610e60acc7f5bdc031eff6d53a76e0b229a5c8c2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function qt_generate_module_pri_file did not take into account the
CONFIG_MODULE_NAME argument of qt_add_module.
This resulted in wrong file names and content, e.g. qt_lib_test.pri
instead of qt_lib_testlib.pri.
Fixes: QTBUG-83176
Change-Id: Id6991396cf9ea5a1d155aa15402c0d84a8a9d082
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
When cross-compiling with CMake, before this patch pkgconfig calls would
find libraries which are part of the host system and not the target
system.
The current approach used is based of the discussion present in
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4478, and should
be considered a temporary solution until the issue is properly addressed
in upstream CMake.
Change-Id: I535d4d48c2a5d34689082b80501b3b6ae30d7845
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For INSTALL_*DIR variables that have the the same value as
CMAKE_INSTALL_PREFIX, a second cmake run cleared the value. This is
because file(RELATIVE_PATH) returns the empty string if we pass the same
absolute paths.
Fix this by checking the return value of file(RELATIVE_PATH) for the
empty string and setting it to ".".
It's a limitation of qmake that empty strings are not handled as ".".
Change-Id: I8fc4d1eabcc9d5634be2f3741b0002a347dd17e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
PCH files were only used while building qtbase. Make sure the value
is exported to the BuildInternalsConfig file, so the value is re-used
when building other repositories.
Also disable PCH when building simulator_and_device iOS builds, because
CMake doesn't currently generate separate PCH files per architecture.
Change-Id: I79955ebc557b800bc3c704deac519fe80012c229
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Repos like qtshadertools need it when configuring their own
bundled libraries.
Amends 572c03eb7a
Change-Id: I540e99d5bd2938299a10220a1a5e0d97091077b3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
qt_add_module checks for the existence of the following directory
include/QtFoo/6.0.0/Foo when deciding whether a private module target
should contain that path in its INTERFACE_INCLUDE_DIRECTORIES.
There are 2 cases when it's created, when running syncqt, and inside
qt_install_injections. If syncqt doesn't create it because there are no
private headers (like in qttools/src/global), qt_install_injections
created it at generation time (for injected configure headers like
qttools-config_p.h)
Unfortunately that caused the existence check mentioned above to fail,
not exporting the path in the QtToolsPrivate's include directories,
and failing the qttools build.
To fix that, create the injection files (and directories) at configure
time, using qt_configure_file instead of file(GENERATE).
Change-Id: Idd9b6ec36e986c4de95d11557170e1c70927211c
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It has the same kind of signature as file(GENERATE) but
creates the files at configure time rather than generation time.
CMake provides a few ways to generate files
file(WRITE) -> always overrides content
configure_file() -> only overrides if content changes, creates file
at configure time, can only take a file as input
file(GENERATE) -> only overrides if content changes, creats file
at generation time, can take a string or file
as input
Because dealing with an input file is a hassle (need to create one,
make sure it's installed, make sure it's used correctly in the
various build types like super-build, non-prefix-build, etc)
people tend to use file(GENERATE) instead, which can take a string
argument, and is thus easier to use.
Unfortunately that introduces subtle bugs because the
file is created at generation time, but there are existence
checks which are done at configuration time.
Thus qt_configure_file allows creation of files at configure time,
without having to provide an input file. Underneath it uses
configure_file(). Once CMake 3.18 is released, the implementation
can be switched to use file(CONFIGURE).
Change-Id: Ic8f8d88541ef0b25d01af143352c8c9ba390ad5f
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Before this patch there were a few ways to build tests
- Configure all tests as part of the repo build
- Configure all tests as part of the repo build, but don't build
tests by default (-DQT_NO_MAKE_TESTS=ON)
- Configure all tests as a standalone project in a separate build
dir using -QT_BUILD_STANDALONE_TESTS=ON
All of the above incur some time overhead due to the necessity
of configuring all tests.
Sometimes you just want to build ONE test (or a few).
To facilitate that use case, a new shell script called
bin/qt-cmake-standalone-test(.bat) can now be used to configure
and build one or more tests.
The script takes one single argument pointing to the desired test
project path and configures a generic template project that sets up
all the necessary Qt CMake private API, afterwards calling
add_subdirectory on the passed in project.
Example
$ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon
or
$ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image
After that, simply run 'ninja && ctest' to build and run the test(s).
This is the CMake equivalent of calling qmake on a test .pro file
(or on a tests SUBDIRS .pro file)
There are 3 details worth mentioning.
Due to the add_subdirectory call, the built artifacts will not
be in the top-level build dir, but rather in a nested build_dir.
The script currently can't handle more than one argument
(the path to the project), so you can't pass additional
-DFoo=bar arguments.
If a test uses a 3rd party library (like Threads::Threads)
which was not a public dependency for any of the Qt modules,
configuration will fail saying that the target was not found.
Perhaps we should consider recording these packages when
generating the StandaloneConfig.cmake files.
Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously you could use either module-specific or
repo-specific 'docs' targets.
For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'.
Now there's a global / top-level target called
'docs', so 'ninja docs' works.
For super builds it will build the documentation of all
configured repositories.
For a single repo build, it's equivalent to calling
'ninja docs_repo_name'.
Also for consistency, add the "docs_Core" target, which was missing
before. So now a 'docs' target exsits for repo names AND targets.
New global target names are
- docs
- prepare_docs
- generate_docs
- html_docs
- qch_docs
- install_html_docs_docs
- install_qch_docs_docs
- install_docs_docs
Amends 0095ff4e06
Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Simplify the handling of simd specific sources. The previous
implementation was causing simd instructions to bleed into the main
library.
The tests were failing because the avx instruction were leaking into
Qt6Gui due to the previous problem. This in turn caused any test which
required Qt6Gui code run to crash since it is not possible to run avx
instruction in the VMs.
This patch also disables PCH for the simd sources as they result in
warnings related related to using PCH header not compiled for the
architecture in question. The latter can cause the build to fail in
conjunction with warnings as errors.
Change-Id: I1be98f2f5e967f33793d6a2e6134a24ef1709566
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
The exported INTERFACE_LINK_LIBRARIES property now looks a lot more
sane.
Change-Id: I093fcb242607023dd0b103298562b299cb803028
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The default Info.plist shipped with CMake lacks an NSPrincipalClass
entry, which is crucial for making macOS apps run in full resolution
on retina screens.
We make sure the file is only picked up on macOS, not iOS and friends,
since those platforms require another principal class. If needed we can
extract the value out as a CMake variable and use the same file for all
Apple platforms. Doing so would assume all keys are single-platform
only, so if that's not the case we need platform-specific files.
We should probably extract the package type out as a variable too,
so that the file can be used for both apps, plugins, and frameworks,
but doing so requires setting up that variable somewhere based on
the target type, which CMake doesn't allow in an easy way.
The file itself is based on the file CMake ships, combined with
keys inherited from Qt's existing plist templates for qmake, and
adjusted to match what Xcode generates by default these days.
Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Uncovered while building qtdeclarative.
Change-Id: If1a36f2640a3a5d765e7ca74b0ba1d39ef2a18f0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's needed when building qtdeclarative.
Needs to be copy_or_install to support non-prefix builds as well.
Change-Id: Ied59f6a1f8403be3721a0ad46f5a3b2f569028ca
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Aka the version of C++ that needs to be supported when compiling
applications that use Qt headers (C++17 at the moment).
Change-Id: I64dec297e8329f31b1d9864f216a95782049ed06
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It is needed when cross-building Qt using CMake, where the zstd
feature might have different values between the host and target,
in which case the build system tells rcc not to use zstd when
the feature is disabled.
Amends d20c980576
Change-Id: I9dc55b59b1be5272b79aa5f1e2daf2b516a157d6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The minimum required CMake version to build Qt on any platform is
3.16.0 at the moment. That's the first version that ships the
implementation-specific AutogenInfo.json files, which we parse
to implement the Qt moc --collect-json functionality.
Change-Id: I6160cd74fa228aa330f4c1e512ffb766afc5f8a3
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The only two uses (QtHarfbuzz and QtDoubleConversion) have been removed,
so now the code is not needed anymore.
Change-Id: Id9ef628fa139f1431395bcdd1705463dfafb1051
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We recomputed INSTALL_LIBDIR for every new repo that is configured,
which is incorrect due losing any custom provided libdir when
configuring qtbase.
Save that information (and all other path components) in
QtBuildInternalsConfigExtra.cmake.
Make sure not to-recompute that information when configuring a project
other than QtBase.
Allow providing absolute paths instead of relative paths for these
variables.
Note that only absolute paths pointing somewhere under
the prefix will currently work, otherwise configuraion will fail. If
we need to support such a use case, we'll have to carefully check all
code that use these path components to make sure they handle absolute
paths correctly (current assumption is relative paths everywhere).
Use the computed paths when generating the qconfig.cpp file which is
used for qmake -query.
Task-number: QTBUG-81289
Change-Id: I331aa00e47988fe0ee4e533b5f95c4df11c4d96f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Teaches configurejson2cmake about summaries / reports, so things
like enabled features, configure sections, notes, etc.
Add relevant CMake API for adding summary sections and entries,
as well as configure reports. The commands record the passed data,
and the data is later evaluated when the summary needs to be printed.
This is needed, to ensure that all features are evaluated by the
time the summary is printed.
Some report and summary entries are not generated if they mention a
feature that is explicitly exclduded by configurejson2cmake's feature
mapping dictionary. This is to prevent CMake from failing at configure
time when trying to evaluate an unknown feature. We should re-enable
these in the future.
A few custom report types are skipped by configurejson2cmake (like
values of qmake CONFIG or buildParts).
These will have to be addressed a case-by-case basis if still needed.
Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Same value as QMAKE_IOS_DEPLOYMENT_TARGET in
mkspecs/macx-ios-clang/qmake.conf, etc.
Change-Id: I1f6a07d73c2126d0286e8d26f7e61a690607c8ce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
For this, we have to uninline the separate_debug_info configure test,
because supporting the conversion of this in configurejson2cmake is not
worth the hassle.
Separate debug information can be turned on for a target by calling the
function qt_enable_separate_debug_info. For Qt's shared libraries and
tools separate debug information is generated if the
'separate_debug_info' feature is manually turned on.
Change-Id: Ic2ffc15efef3794dc0aa42f3d853ef6d651a751c
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Depends on a new bleeding edge feature in as-of-yet unreleased
CMake 3.18, that allows building macOS frameworks using the
Ninja Multi-Config generator targeting more than
one configuration.
It uses the new CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG
property which tells CMake to create properly named debug artifacts
in the Multi-Config ninja file.
Without it, both debug and release artifacts would have the same
location (no _debug) postfix, so it would be unclear which file
ends up being compiled as last (the debug or release variant).
Change-Id: I3e10832551731a18317da8f9667d96cec3dc3028
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When a Qt module has this property set, when we generate the
QtModuleDepends header file and find this module it will not be added.
This is required to be able to create a Core_qobject module, as it does
not have any headers.
Change-Id: Iaea1080919d05ace12e48693e02d8c0f4c669339
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
This feature is read-only. It's controlled by the multi-config feature
of CMake. It mainly exists for the qmake support.
Change-Id: I322459598fe92568eda4d42319ded444537e95d4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Most of the NMC-specific variables were renamed to be more general.
Change-Id: I8ee2874fecb9e57480ce51db9183c6cf3dd100af
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
And in order to do this we must teach qt_config_compile_test a
COMPILE_OPTIONS argument.
Change-Id: I66fa45142b544e3a2fc599af1c1a4c69b442b318
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The original toolchain file may set CMAKE_FIND_ROOT_PATH instead of
appending it, which overrides the Qt's path.
Change-Id: I69a4bf4be6a999854bb8a84cf5032c6a9b739b2e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add support to generate win32 resources files through CMake. The
functionality is implemented via qt6_generate_win32_rc_file() in
Qt6CoreMacros.cmake.
Currently qt_add_test(), qt_add_module() and add_qt_gui_executable()
call the above function when building on windows. The function itself
has been written as part of the public API so it can be called from
other locations if required.
Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch adds missing linker flags for MSVC in order to match
qmake's msvc-desktop.conf.
Change-Id: Ieb1206dae4517e8d9f36175f8fcebccd30e52d01
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As reduce-relocations implies bsymbolic_functions, we also add the
-Bsymbolic-functions linker flag.
Also, handle the .dynlist files that are passed to the linker by
bsymbolic_functions.prf in the qmake build.
Change-Id: I535c33fba888596d2f8975b16864bbe9f0a7caa4
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Only existing directory paths should be added to
INTERFACE_INCLUDE_DIRECTORIES, otherwise projects fail to configure.
If after running syncqt there is no private headers directory created
(due to the module not having any _p.h files), such a path should not
be added as an interface include path.
This fixes consumers of QtZlib, where there are no private headers.
Change-Id: I3fd1a7b5eb8f816d178d6d91223baa6f377e6f9f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Introduce an internal qt_feature_evaluate_features() function
which takes a list of configure.cmake paths, and evaluates the
features declared in those files, thus setting a bunch of cache
variables.
This is required to implement the equivalent of what qtbase/src.pro
does, which includes the feature .pri files to decide whether
bundled 3rd party libraries need to be built.
Change-Id: I5552f488671c001eb3f204245b905ab981017a9f
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
On Windows, when WrapRt is qt_find_pacakge()'d the first time, the
result is "not found", whereas a second time it would claim that the
package is found.
This is due to the WrapRt target being always created even if it has
no transitive dependencies, and thus a second search would check only
for the existence of the target.
Fix the module to only create the target if the relevant library
is found.
Change-Id: I5c838cbfbafb4029f96da815a0f72e4a8e6716b0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Libraries created with qt_add_3rdparty_library should be installed
when the qmake 'installed' value is set in CONFIG. Introduce a new
INSTALL option to handle that in CMake projects.
If the value is provided, the library should always be installed
regardless of whether it's a shared or static library.
Fix the libraries to be installed to BINDIR/LIBDIR instead of
the config install dir.
Also install the CMake config files into the config install dir.
Change-Id: I86f1ef47680f08669a77db77e0d986f47d5fae2d
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Useful for header only modules that are declared in the same directory
as a regular module, but which doesn't have any features and thus has
no qtfoo-config.h file.
Will be used for the qtzlib module, which is built when system_zlib
feature is disabled.
Change-Id: I60c5f73c3e2a3a481a16c5872e06d5d109a04b10
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
