The function append the unique entries to the CMAKE_CONFIGURE_DEPENDS
property. This suppress the ninja recompat issue, which complains
about the duplicated entries in that come from the
CMAKE_CONFIGURE_DEPENDS property. It's likely the CMake issue, but
we may work around it.
Pick-to: 6.8 6.9 6.10
Change-Id: I2f10834b0dca3d2aa08fe13fba69849e97fa77d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously QT_CMAKE_EXPORT_NAMESPACE was set by calling
find_package(QtBuildInternals) at repo dir scope, even in a top-level
build.
Starting with ddcafa0a51c65d86f6b5481f06fce5faeb75920d in
qtdeclarative, we now have a deferred call of
_qt_internal_write_deferred_qmlls_build_ini_file in the
CMAKE_BINARY_DIR scope, which lacks the QT_CMAKE_EXPORT_NAMESPACE
variable.
This caused errors in a top-level standalone tests build:
Error evaluating generator expression $
No target "::qtpaths"
CMakeLists.txt:DEFERRED
To avoid the error we now set QT_CMAKE_EXPORT_NAMESPACE in the
top level scope.
To avoid duplicating the code into the QtBaseTopLevelHelpers,
we extract the qt_internal_top_level_setup_cmake_and_export_namespace
function into a new QtBuildInternalsHelpers.cmake file, which is
included by both QtBaseTopLevelHelpers.cmake and
QtBuildInternalsConfig.cmake.
We also copy and install that file.
This has less side effects than trying to call
find_package(QtBuildInternals) in the top-level scope.
Pick-to: 6.10
Change-Id: I8e54e21d3f07ee86860cad49d6e43e0fdefbcee3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We didn't copy the standalone test template files into the build dir
when configuring a prefix build.
We also need to copy the mkspecs.
Pick-to: 6.8 6.9 6.10
Change-Id: I517165b2b8db84b0766935e3d535a7a1ef2b6ad9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
These files should not have executable permissions.
Pick-to: 6.9
Fixes: QTBUG-125534
Change-Id: I893d4d373ee098864b64200dc6c88b57d05d6209
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Dynamic linking on WebAssembly involves preloading .so libraries
during startup of application. Normally, those plugin preload
lists are generating manually by user, which can be tedious.
Add a bash script which demonstrates how to call python
programs to generate preload lists.
Pick-to: 6.9
Change-Id: I0a9869ad0d26606f8b33af2c38248cec3088dd0d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Swift 5.9 includes built in crash reporting, printing stack traces,
libraries, and registers to stdout/err.
https://www.swift.org/blog/swift-5.9-backtraces/
As (Core)Foundation is written in Swift nowadays, we get this feature
for free even in our "C++" apps, as we always link to CoreFoundation.
To enable the feature the binary needs the com.apple.security.get-task-allow
entitlement, so we add it for all our tests automatically.
The final piece is to run the tests with SWIFT_BACKTRACE=enable=yes,
but we'll do this in our CI provisioning, as setting it from within
testlib doesn't seem to work.
Pick-to: 6.9 6.8
Change-Id: I31090efee06460f45522093e17f900e76590b282
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit f0f89d3c1946fa819c01b28d757ba0a5074dd163.
Reason for revert: Breaks qttools. Installs without consent in user projects.
Fixes: QTBUG-130717
Change-Id: I2a856cc89cc144f9d69c75a396ba9b8fa4fba482
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Dynamic linking on WebAssembly involves preloading .so libraries
during startup of application. Normally, those plugin preload
lists are generating manually by user.
Automate this process as part of installation step.
Change-Id: I364ebdb170f9fac53da241c96f601613352972d8
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Introduce some command wrappers for adding the Platform,
PlatformXInternal and GlobalConfig targets, to apply some common
options.
This will allow for less churn in the future when we need to apply
options to all these targets.
The Qt6CoreMacros, Qt6AndroidMacros and Qt6WasmMacros inclusion are
moved before QtBaseGlobalTargets to make the
_qt_internal_add_library command and other platform specific
commands available before we create the Platform targets.
Pick-to: 6.8
Change-Id: I260fdbeb95a39f06951dfefc714d3da604abb0bb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
QtInstallPaths needs to be loaded at early stages
Change-Id: Ie275ad2a8855b7555b110c35814ebadafe1817c6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Versionless targets in Qt6 are interface libraries that link the
versioned libraries using the INTERFACE link type. This makes the
linking chain more complicated than it can be. Also we miss some
significant interface properties in the versionless targets comparing
to the versioned targets.
The new approach manually generates the versionless targets, instead
of using CMake exports.
For CMake versions < 3.18 we now create a copy of the versioned
targets. The copy includes all the relevant INTERFACE properties from
the versioned targets and imported locations for all configs.
For CMake versions >= 3.18 we now create the versionless target ALIASes
which should behave give the transparent access to the versioned
targets.
Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the
behavor of the CMake versions <= 3.18
The change is partial workaround for QTBUG-86533.
Task-number: QTBUG-114706
Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The default manifest is a minimal file that claims NSPrivacyTracking
false, along with an empty list of NSPrivacyTrackingDomains and
NSPrivacyCollectedDataTypes, as Qt does not generally do user tracking.
Modules can override the default manifest by setting the
PRIVACY_MANIFEST target property, specifying a custom privacy
manifest.
The NSPrivacyAccessedAPITypes key is only required for iOS for now.
Even though we don't build Qt for iOS as frameworks yet, which is
required to embed a privacy manifest, we include the keys for the
APIs we known we use.
Task-number: QTBUG-114319
Change-Id: I654bb52b98ee963adeeb744b35f3a1c2a1270969
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The build tree versioned alias is missing for the GlobalConfigPrivate
target.
Change-Id: I42e9f63363be472e661b656f665e29ea894b7e33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The warnings are shown when configuring any Qt submodule or top-level.
The warnings are NOT shown when configuring a user project with CMake.
Opt out CMake cache variables can be set to silence any of the
warnings:
- QT_NO_APPLE_SDK_AND_XCODE_CHECK
- QT_NO_APPLE_SDK_MIN_VERSION_CHECK
- QT_NO_XCODE_MIN_VERSION_CHECK
- QT_NO_APPLE_SDK_MAX_VERSION_CHECK
The warnings can be upgraded into errors by configuring with
-DQT_FORCE_FATAL_APPLE_SDK_AND_XCODE_CHECK=ON
The platform version requirements that qtbase specifies in .cmake.conf
are saved in Qt6ConfigExtras.cmake so that they can be used when
configuring other non-qtbase submodules.
The code is added to the public CMake files, so that in the future we
don't need to move code around if we enable the checks for public
CMake projects as well.
The version extraction helpers were moved out of QtAutoDetectHelpers
into QtPublicAppleHelpers.
Task-number: QTBUG-119490
Change-Id: Ic840e1013aeb607bf23247a9cb43471dde802e9d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Otherwise we don't have access to the 'debug' and 'debug_and_release'
features to decide whether the install script needs to strip binaries
or not.
Amends 09fdddeb326d0c79d080bdb50a92a839038baea7
Pick-to: 6.6
Fixes: QTBUG-118070
Change-Id: I4f1b8463fa369edd38c1110d1d69e7fa7a45de63
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Instead of duplicating file names that need to be include()'ed
in two different places if the files are meant to be used
in both Qt builds and public user projects and then also mention the
name when installing, extract the file names into lists returned by
functions.
Call these functions where needed to iteratively include() the files
as well as install them, without having to remember updating multiple
code locations.
The new functions return the following list of file names:
- upstream cmake modules that need to be included during a Qt build
- public (Qt build and user project) cmake helpers that need to be
included and installed
- private (Qt build only) cmake helpers that need to be included and
installed
- public files that need to be installed, but not included
- private files that need to be installed, but not included
We also generate the list of public files to include in
Qt6Config.cmake.
Task-number: QTBUG-86035
Change-Id: I1e7287f4e1d041c723f144ba9626b34f873c4891
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Make the QtBuildRepoHelpers and QtBuildRepoExamplesHelpers files
that were previously loaded as part of BuildInternals package instead
be loaded when qt_internal_include_all_helpers is called.
Load all the helpers as soon as find_package(QtBuildInternals) is
called rather than when qt_build_repo() is called.
This is a behavior change, but because including the Qt's Helpers
should have no side-effects aside from defining functions,
it should be fine.
This lets us have a unified location where to include Helpers files,
instead of thinking whether it needs to be done in QtBuildInternals or
in QtBuildHelpers or some other place.
Move also some additional inclusions into the same function.
Note that including some upstream CMake files like CMakeFindBinUtils
does have side-effects, but we've been doing it already anyway,
so moving it to the top should not make a difference because any
modifications we would do to the globally assigned variables would
have come later when we actually called our own functions.
Task-number: QTBUG-86035
Change-Id: I33f36f7e8db69d504c34a4d4a094b98f6fa50ee4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Move most of the code into two new files:
- QtBuildRepoHelpers.cmake
- QtBuildRepoExamplesHelpers.cmake
Task-number: QTBUG-86035
Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Split all code in QtSetup into separate functions and macros, put them
in more appropriate files, and call them in
qt_internal_setup_build_and_global_variables.
A new QtBuildOptionsHelpers.cmake is created which takes care of
computing the default values of user-customizable options that are not
pure configure features, like the cmake build type, whether to build
tests / examples, whether to enable ccache, etc.
The new function calls added in
qt_internal_setup_build_and_global_variables
try to preserve the previous code flow when QtBuild was included
in-between the code that was run in QtSetup.
Macros that have dependencies on various global variables were marked
as such with inline comments for easier navigation and comprehension.
After this change, QtSetup.cmake just includes QtBuild.cmake. We leave
it to exist for easier git blaming, but new code should not be added
to it unless really necessary.
The intent is to merge a variant of this change to 6.6 and 6.5 as
well.
Task-number: QTBUG-86035
Change-Id: I3409c2d3ea8ee19a69104b12ab2692966ba5f9cf
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
My motivation to do this:
- it got big and tangled again
- sometimes functions need to be added to QtBuild.cmake rather than
to a separate file because they need to be called before some of the
global variables are set, to determine the value of those global
variables (in my case install paths needed to be modified when
building with xcframework support)
- some of the global variable assignments have dependencies on other
variables already being set and it's hard to keep track where that
happens
Split the contents of the file into smaller functions and macros
and place them into pre-existing files when appropriate, or
into new files. The new files are:
- QtBuildHelpers.cmake
- QtBuildPathsHelpers.cmake
- QtMkspecHelpers.cmake
The idea is to have Helpers file only define functions and never call
them, so it's easy to include the file where needed without being
scared of side effects.
QtBuild.cmake will just include the helpers and call one entry point
function to set up everything that was done by the file before.
QtBuild.cmake is not merged into QtSetup, to make it easier to git
blame (it's hard to blame a removed file).
No new features were added as part of the refactoring.
Some function names were renamed (but not all of them) to include
the qt_internal prefix.
Some lines were reformatted so they don't pass 100 chars limit after
the code was placed into a function / macro.
The Helpers includes were re-sorted.
Some function calls were re-ordered where the order call didn't
matter.
Some of the code in QtAndroidHelpers.cmake was wrapped into a macro
so that including the file does not cause side-effects by default.
I'd like to follow up with similar changes for QtSetup.cmake and
QtBuildInternalsConfig.cmake where possible, because having a few
"entry points" into building a Qt submodule is also confusing,
especially for those that aren't familiar with the build system and
why certain things go into certain places.
The intent is to cherry-pick this also to 6.5 and 6.6.
Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0
Task-number: QTBUG-86035
Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
It makes sense (in my opinion) to have the top-level CMakeLists.txt
to include and call certain commands that should be controlled by
qtbase, to avoid submodule update difficulties when we want to do
changes in qtbase that shouldn't concern the top-level file.
Create cmake/QtBaseTopLevelHelpers.cmake and move some pre-existing
code from the top-level CMakeLists.txt into separate functions that
are defined in qtbase.
This file will be included in the top-level one and said commands will
be called there.
This also prepares for qt_print_build_instructions not call
qt_internal_qt_configure_end anymore, because it will be called
by the top-level project.
Pick-to: 6.6
Change-Id: I1fe3490001cf441d742c64b2ef1f267cd4362f6a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Consider the following situation: There are CMake tests in
qttools/tests/auto/cmake that configure and build CMake test projects,
essentially as external projects. One of those test projects does
find_package(Qt6 COMPONENTS LinguistTools). This call fails in a prefix
build, because Qt6LinguistToolsConfig.cmake is not installed yet. It
merely exists in qttools-build/lib/cmake/Qt6LinguistTools.
We must adjust CMAKE_PREFIX_PATH to be able to find Qt6LinguistTools. We
also must adjust QT_ADDITIONAL_PACKAGES_PREFIX_PATH to be able to find
the LinguistTools component of the Qt6 package.
Use the prefixes setup from the support for building examples as
external projects and use it for CMake test projects as well.
Task-number: QTBUG-84884
Change-Id: I1bd5d5084cf931196bdb014cd75ca7578cd9decb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Surprisingly, CMake copy/install empty directories when `file` or
`install` are used with `FILES_MATCHING PATTERN` argument.
In order to avoid this, we can exclude the empty directories using a
PATTERN EXCLUDE argument.
Pick-to: 6.5 6.6
Change-Id: I17a22f9b9e317bc4a66cee3df39815659ddb4c04
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We were not accounting for `x86_64h` arch, and as a result
cross-compiling with `-DCMAKE_OSX_ARCHITECTURES="x86_64h;arm64`
was failing.
Pick-to: 6.5
Fixes: QTBUG-113694
Change-Id: Ieb50a7a62aabcca76b09f9c853b3faf915eab1a3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Unifies the approach between iOS and macOS. By copying the Info.plist
to the build directory, we also open up the possibility to modify it,
which we can't do when CMake does the copy during its generator step.
Change-Id: I59f9f69ac368166bb26d8a5c57bf4ea3f503d51b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
- The following commands accepts NO_UNITY_BUILD, and
NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and
to exclude some source files from unity build, respectively.
- qt_internal_add_executable
- qt_internal_add_module
- qt_internal_add_plugin
- qt_internal_add_tool
- qt_internal_extend_target
- qt_internal_add_common_qt_library_helper
- qt_internal_add_cmake_library
- qt_internal_add_simd_part
- Unity build is disabled by default in these:
- qt_internal_add_test
- qt_internal_add_test_helper
- qt_internal_add_benchmark
- qt_internal_add_3rdparty_library
- qt_update_ignore_pch_source also excludes the files from unity_build
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce the qt-cmake-create script. The script generates the simple
CMakeLists.txt based on the source files located in the current or
specified directory. The initial version can generate a CMake code for
the following file types:
- .c .cc .cpp .cxx .h .hh .hxx .hpp - generates the qt_add_executable
call with prerequisites.
- .qml .js .mjs - generates the qt_add_qml_module call with
prerequisites.
- .ui - adds the found ui files to the existing executable. Requires
C++ files be present in the directory too.
- .qrc - generates the qt_add_resources call and adds the resources
to the existing executable. Requires C++ files be present in the
directory too.
- .proto - generates qt_add_protobuf call with prerequisites.
The QtInitProject.cmake script contains the 'handle_type' function that
allows extending the script capabilities and establish simple relation
chains between the file types.
Note: The initial implementation doesn't deal with sub-directories, so
all files from sub-directories will be added to and handled in the
top-level CMakeLists.txt file. This can be extended by user request.
Task-number: QTBUG-104388
Change-Id: I5abd9e07da109e867ff95986572ed2bf02ef9d3d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
__GlobalConfig_install_dir translates to lib/cmake/Qt6/ and 3rdparty
modules will be in lib/cmake/Qt6/3rdparty which seems to be a logical
place for them.
Pick-to: 6.5
Change-Id: I90c715b9502b0dfc666bb3202a838f20ba6110cf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_internal_add_configure_time_executable compiles the executable
at configure time and exposes it to the CMake source tree. This is
useful when need to run a small C++ program at configure time.
Task-number: QTBUG-87480
Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
An approach of test batching (joining multiple tests into a single
binary) has been taken, due to long linking times/binary size on certain
platforms, including WASM. This change adds a new feature
'batch_test_support' in Qt testlib. Based on the value of the feature,
test batching may become enabled with the -batch-tests switch.
Batching works for every target added via qt_internal_add_test. When
first such target is being processed, a new combined target for all of
the future test sources is created under the name of 'test_batch'.
CMake attempts to merge the parameters of each of the tests, and some
basic checks are run for parameter differences that are impossible to
reconcile.
On the C++ level, convenience macros instantiating the tests are
redefined when batch_tests is on. The new, changed behavior triggered
by the changes in the macros registers the tests in a central test
registry, where they are available for execution based solely on their
test name. The test name is interoperable with the names CMake is aware
of, so CTest is able to run the tests one by one in the combined binary.
Task-number: QTBUG-105273
Change-Id: I2b6071d58be16979bd967eab2d405249f5a4e658
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
It's needed for creating qmake build tests.
CMake / CTest has a limitation of not allowing to create single-config
tests when using a multi-config generator using the add_test(NAME)
signature.
Using add_test(NAME) forcefully creates per-config tests, which means
that it's not possible to just run ctest to execute tests, without
specifying a -C parameter, which we do in the CI.
qmake tests need to use the add_test(NAME) signature
to specify the WORKING_DIRECTORY option.
Because of the above limitation, a work around is to not use the
add_test(NAME) signature, but instead delegate the working directory
assignment to a generated cmake script, which
_qt_internal_create_command_script can already do.
Pick-to: 6.4
Task-number: QTBUG-96058
Change-Id: I6f439165994671724157f0edb7a71e351271e329
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add the support of pre-cooked content for the LD version script. The
content can be generated without using the perl script at configure
or build time.
Change-Id: I1316e114a1d5550b2fdcf3482a51f336fb311a29
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
To support per-target iOS launch screens we need a way to specify
custom Info.plist entries without using cache variables, which we were
forced to use due to the implicit configure_file done for
MACOSX_BUNDLE_INFO_PLIST.
We now introduce an extra configure_file call done in a finalizer,
before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST.
This extra configure_file call allows us to insert / substitute
additional Info.plist entries that CMake does not allow setting.
If a custom Info.plist file is provided, the finalizer will simply
skip the logic for creating a new one.
Amends e5b3436255ce095af58608b03b913fc9bcb8e61f
Pick-to: 6.4
Fixes: QTBUG-101064
Change-Id: I65496da146c9430a949a8163817021d54da28386
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Merge all the existing checks into a single one, which is a simple pass
or fail, since all our supported compilers support all the intrinsics up
to Cannon Lake. The two I've recently added (AVX512VBMI2 and VAES)
aren't yet supported everywhere, so they stay.
For some reason, all intrinsics seem to be disabled on Android. It looks
like some support was missing during the CMake port and this was never
again looked at. I'm leaving it be.
As for WASM, discussion with maintainers is that the WASM emulation of
x86 intrinsics is too hit-and-miss. No one is testing the performance,
particularly the person writing such code (me). They also have some
non-obvious selection of what is supported natively and what is
merely emulated. Using the actual WASM intrinsics is preferred, but
someone else's job.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c10d66208e8384
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This will stop working with the next commit, which merges all basic x86
SIMD intrinsics into one configure test. As a result, linking almost
anything graphical on iOS (which is almost everything) causes the linker
to fail with undefined references to SIMD-optimized versions that didn't
get compiled.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c288f4104a6ccc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The test run is wrapped with a special TESTRUNNER script that ignores
failing tests (there are several tests failing when built with ASAN) and
also ignores LSAN errors (memory leaks - but still visible in the
output).
The test run only fails if a test reports ASAN errors or if it
crashes (or times out, which is like a crash caused by qtestlib's
watchdog timer).
Fixes: QTQAINFRA-5025
Change-Id: I861756ab49388ac4a52409d3a780684244e469b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Added a small helper function that also installs the script to
prefix builds. Additionally, leveraging the cmake option
CROSSCOMPILING_EMULATOR for the testrunner fits neatly in the rest
of our cmake code.
Change-Id: I75288e97c81b250ac3997f2e7a22bc7bd82b7b69
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
So we can see the command line invocations of the built cmake
auto tests.
To achieve that, we create a ninja shell script wrapper, because
ctest --build-and-test does not currently allow specifying custom
build tool options.
Details at
https://gitlab.kitware.com/cmake/cmake/-/issues/22443
Pick-to: 6.2 6.3
Change-Id: I7fb3b7f7f802943a7013c859b2cf39842a34e2e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Add a python script that allows us to run wasm tests in CI, along with
the necessary cmake logic to install the script and execute tests
accordingly.
Change-Id: I93b95c115538c4e27b2b833405acab8162be2a8a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink"
section in binaries, a section that is needed for the separate debug
information feature.
binutils version 2.34 mentions the feature for the first time:
https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip
To ensure the debuglink section is preserved, generate a shell wrapper
that calls the original strip binary with an extra option to keep the
required section.
To determine if the option is supported, we build a real shared library
on which strip will be called with the --keep-section option.
If the option is not supported, a wrapper is not generated and the
stock strip binary is used.
This logic only applies when targeting Linux and MinGW + a shared
library Qt. For other targets, the stock strip binary is used.
Developers can opt out of this logic by passing
-DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo.
Pick-to: 6.2 6.3
Fixes: QTBUG-101653
Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
QtCopyFileIfDifferent needs to be both installed and copied to a build
folder as a public CMake helper. Otherwise it's not found when building
tests inside the Qt build tree.
Pick-to: 6.2 6.3
Fixes: QTBUG-101916
Change-Id: I8d081e594fe694f528ebac4c13bbdf6d3b8402b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After the update to the CMake based build system the ability to
generate pkgconfig files, like it was with QMake, was lost.
This patch adds pkgconfig generation again via a new internal command
named qt_internal_export_pkg_config_file.
The functionality of this command consists in checking if the target
is internal. Then gets the compile definitions. It performs a search
for dependencies that is somewhat similar to
qt_get_direct_module_dependencies, although it won't recurse down for
more deps. Each dependency is then again, checked if it's internal or
has a public interface. Later these deps get deduplicated and lastly
a pkgconfig file is filled.
The resulting pkgconfig files of many of the Qt6 packages were
validated via invocations of `pkg-config --validate` and
`pkg-config --simulate` commands and later used to build local
projects plus tests that use the pkg-config provided details at
compilation time.
Although it has some limitations, with qt_internal_add_qml_module if
it specifies non-public deps these won't be listed and with non-Qt
requirements, notably in static builds, not being appended to the
PkgConfig file.
Task-number: QTBUG-86080
Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Bundle a default LaunchScreen.storyboard file for an iOS app and make
sure it's referenced in the generated Info.plist file.
When launching Qt examples, it ensures the app uses the whole screen
space on the device rather than just a square-ish part of it.
The storyboard file is a copy of the qmake one, which qmake adds
to the Xcode projects it generates.
A custom launch screen can be provided either by setting the
QT_IOS_LAUNCH_SCREEN variable or by setting the
QT_IOS_LAUNCH_SCREEN target property.
The value must be an absolute path to the launch screen file.
The automatic addition of the launch screen entry in the Info.plist
file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN
variable to TRUE.
The automatic bundling of the launch screen file in the application
bundle can be prevented by setting the
QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE.
The current implementation has a limitation that only one launch
screen storyboard and one iOS executable can exist within a project.
If there are multiple executables in the project, all of them will
use the launch screen that is specified last (the last
qt_add_executable call).
Because of this limitation, the API is marked as Technical Preview,
to be improved upon in the future. For now it simply serves as an
improvement to the out-of-the-box experience of iOS apps built
with CMake.
Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e
Pick-to: 6.2 6.3
Fixes: QTBUG-95837
Change-Id: I6b067d703d635122959a1ef17fcca713da694a86
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use custom script to copy big Android artifacts on Windows platforms.
The script uses 'copy' but not 'copy_if_different' when source file
size is bigger than 2GB. 'cmake -E copy_if_different' only compares
first 2GB of files because of cmake issue, so this step only
workaround the problem.
Pick-to: 6.2 6.3
Task-number: QTBUG-99491
Change-Id: Id076734700e334dfc3330da412462c2b53829b33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
