Avoid duplication and move finalizer code to a new
function "_qt_internal_finalize_wasm_app", which can
be called from the add_executable functions.
Change-Id: I4859a3999725ebf61a496d78665b6a259dfeb0f5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
(cherry picked from commit 2116c62256bbf1bc3d516430509a93177572d86f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously, only a very short subset of options related to attribution
files could be specified to qt_internal_add_module /
qt_internal_extend_target.
It is more convenient to allow specifying most (safe) options, instead
of calling another function.
Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE
which is too generic, and some other ones like LIBRARIES which would
be duplicated, and causes warnings in cmake_parse_arguments if
duplicated.
Change the code to allow specifying most SBOM options and forwarding
them to _qt_internal_extend_sbom.
Task-number: QTBUG-122899
Change-Id: I6eb723e165edf59973d83c66eace43acdce237de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 81162cc8b6931c8659dc722be97eb788e344812a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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.
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 37a5e001277db9e1392a242171ab2b88cb6c3049)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Because the configs passed to the ALL_CMAKE_CONFIGS option were quoted
cmake_parse_arguments(PARSE_ARGV) would escape the semicolon in
the set value, effectively doing
set(arg_ALL_CMAKE_CONFIGS "Release\;Debug")
Then the
list(GET arg_ALL_CMAKE_CONFIGS 0 first_config)
call would essentially do
set(first_config "Release;Debug")
and the
if(all_configs_count GREATER 1
AND NOT arg_CMAKE_CONFIG STREQUAL first_config)
condition would never trigger because a single config string can never
equal a double config string.
Remove the quotes to ensure correct behavior.
This won't really trigger any behavior change, because we exclude
installation of Debug executables in -debug-and-release builds,
but it will make --trace-expand logs less confusing.
Amends f240d94f140ba1614828804efafd2fc5e6d00099
Pick-to: 6.7
Change-Id: I53179511c7698c90b33cb3ff2762cef680a99815
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Applications not necessarly link QtGui module in
qt_internal_add_executable. They still may add link it in followoup
qt_internal_extend_target calls. We should consider this when adding
dependencies on qpa_default_plugins to the internal executables.
Pick-to: 6.7
Change-Id: Icc413bd35b631b3a356e4033faab4e6c01b29a60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QtGui module can be linked using both versioned and non versioned
targets. Consider this when adding the dependencies to the
qpa_default_plugins targets.
Pick-to: 6.7
Change-Id: Iccbf3009ab8a4f9df4de1677f1b41445814c8c9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt tools and executables may required the static plugins from modules
that are build as part of the Qt build tree. In this case we need to
force plugin importing. This adds the qt_internal_import_plugins call
when we extend the executable target.
Replace the previos solution that considered libraries that were
provided in the arguments of the qt_internal_add_executable call only.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-111988
Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building examples as ExternalProjects as part of a multi-config
qtbase build, syncqt can not be located with the following error:
CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message):
Unable to add configure time executable Qt6::syncqt
qtbase/libexec/syncqt doesn't exist
Call Stack (most recent call first):
qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include)
qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package)
qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34
(_qt_internal_find_tool_dependencies)
qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include)
qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package)
CMakeLists.txt:13 (find_package)
The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for
install(EXPORT) Config files as well as export(EXPORT) Config files,
and in the latter case, the path that syncqt is looked up in is not
correct because syncqt is not yet installed.
In addition to checking whether syncqt exists in the install path,
also check if it exists in the build dir.
Ideally the additional path would be stored in a separate file that
is not installed, but the current code infrastructure does not provide
such a feature. Because we store a relative path instead of an
absolute path, the build path does not leak, so the situation is
bearable.
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Qt no longer sets DISABLE_EXCEPTION_CATCHING and can
use the common logic here.
Task-number: QTBUG-121822
Change-Id: If02feafe9eeac49fa2861d2357b358a19e756438
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Configure time executables don't adopt new cmake flags if they were
changed. Cache all flags that were used when building configure time
executables and consider changes when decide rebuilding them.
Pick-to: 6.6 6.5
Change-Id: Ifba77833f362c790120f0ab1f808a855327bc49f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Wiping of CMakeCache should lead to removing of CMakeCache that is
generated for configure-time executable. Otherwise configure-time
executables might still use wrong compiler or compiler flags.
Pick-to: 6.6 6.5
Task-number: QTBUG-116789
Change-Id: I702d5d29e0c5f35a8a36311cf9a84ea7a0f4d781
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The former implies the latter, so it makes little sense to treat them
differently. Even if some types of targets are (currently) never
compiled with PCH, users of qt_internal_all_x() shouldn't need to know
such details.
Pick-to: 6.6 6.5
Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We want syncqt to be built optimized by default. The current approach
set the default build type for the external projects and optimized
flags for the non-configure-time syncqt build. The problem is that
syncqt still have compiler flags littered by either the Qt configuration
type or the system defaults that are applicable for RelWithDebugInfo
configuration(the default one we chose for syncqt).
This patch makes sure that we cleanup all compiler flags from any
optimizations and apply optimized flags for all configurations. Also
we discard '/RTC1' flag if it's set. Configure time executables now
respect the language related flags that are set in the project and
adjust the flags passed to try_compile.
For linker flags we should use those that are applicable for the
preferred build type. Since syncqt is built in RelWithDebugInfo
by default we should replace linker flags in all configs with
those are used for RelWithDebugInfo configuration.
Fixes: QTBUG-114925
Pick-to: 6.5 6.6
Change-Id: I782f81a36f5ef7ee4d342ce8ac6c217cb2552f3b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The syncqt tool was originally designed to run at build time, as a
part of dependency chain of Qt modules. This works well unless we need
the code model of the Qt project in IDE, since Qt source code actively
uses header aliases, and creating them at build time breaks the code
model until the initial build is done. So we made syncqt the configure
time tool to not break the developer experience.
It's more likely that developers build Qt using command line or don't
need the code model before the first build. So running the tool at
configure time should be optional.
QT_SYNC_HEADERS_AT_CONFIGURE_TIME switches the "mode" of the syncqt
tool from build time tool to the configure time tool. Without the
option enabled build procedure runs all the syncing targets at build
time only. The exception are the developer builds, if the
'-developer-build' option is enabled, QT_SYNC_HEADERS_AT_CONFIGURE_TIME
is set to TRUE by default. This gives better development experience for
the developers that don't use the code model in their IDE or don't
require it before the first build is finished. Also this build time
mode is preferred for the CI or similar build procedures where code
model is not required at all.
By default, the option initialized from the
QT_INTERNAL_CONFIGURE_FROM_IDE CMake variable.
TODO: The option is forced to TRUE for the static Ninja Multi-Config
builds. See QTBUG-113974 for details.
[ChangeLog][Build System] When building Qt from sources, syncqt and Qt
header files are now created at build time, not configure time. This
should speed up the configuration step. You can set the CMake variable
QT_CONFIGURE_TIME_SYNC_HEADERS to ON to use the previous behavior,
though. The old behavior is also preserved if cmake/configure is run
from inside an IDE - Qt Creator, Visual Studio Code, and CLion are
currently detected.
Task-number: QTBUG-111163
Task-number: QTBUG-109792
Pick-to: 6.6
Change-Id: Ib61bda9546e58492be874a8591c37e100313d02c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMP0099 changes the way of LINK_ONLY genex works. With CMP0099 set to
OLD LINK_ONLY genex only links the exact library binary/archive without
propagating other interface options from the target. This feature was
exploited by PlatformXInternal targets to avoid propagating of their
linker options. Nowadays when CMP0099 is forced to NEW by Qt scripts,
including user-facing, we cannot rely on LINK_ONLY genex.
Introduce _qt_is_internal_target property that is set for all Qt
executables and explicitly limits the propagation of the linker
options from PlatformXInternal targets.
Pick-to: 6.5 6.6
Fixes: QTBUG-113641
Change-Id: I3a0ecddb65886e435073feb24c1b47035130ba70
Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The function needs TRUE/FALSE, not NO_EXCEPTIONS.
Change-Id: I3e173e26fafc02996577466afd09e85351a0380f
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Problem: "ninja clean" does not fully clean the build directories of
configure-time executables (e.g. syncqt). This can lead to problems when
building with compiler and linker launchers: on configure time, the
launchers are not used (compare CMake issue #20762). After a "ninja
clean", the executable might be removed but the object files are still
there. This leads to a situation where the object files have been
created without the compiler launcher but are linked with the linker
launcher. We encountered a situation however, where the linker launcher
requires the usage of the compiler launcher.
The configure-time executable has a ${target}_build custom command that
runs "cmake --build" and creates a timestamp file to track when to build
the target. To circumvent the problem of stale object files we add the
"--clean-first" argument to that target to fully rebuild configure-time
executables if the timestamp file is out of date.
The performance this imposes is negligible, because
1. Those configure-time executables are seldom out of date.
2. They are supposed to be "tiny executables with system dependencies
only" anyway.
Pick-to: 6.5
Change-Id: I701f9089f5ad941ffdf235aeccc3119b68c4e3e3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add the timestamp file creation for configure-time executables.
GNU make treats the custom command artifacts as 'dirty' when one of
the expected outputs is missing. It displays the following disclaimer
Deleting primary custom command output ... because another output
... does not exist.
which leads to the configure-time executable rebuild. The removal
and rebuild is not in sync with the dependency lookup for other
targets(thanks to GNU make) so targets that depend on the
configure-time executables simply miss the dependency at build time.
This happens to syncqt and '_sync_headers' targets. So creating
the timestamp file at configure time indicates to GNU make that
there is no need of removing the syncqt executable and the build
process doesn't fail because of missing dependency.
Fixes: QTBUG-112018
Fixes: QTBUG-111163
Pick-to: 6.5
Change-Id: I6c1e8cae522104cf50d0376fa2b5653a6770f9ca
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that
we don't need to pass these quoted, especially now that we have moved
to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence
just by checking the `arg_*`, and that should be sufficient.
I also left a warning that we are aware of this.
Pick-to: 6.5
Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The source of the problem was in `qt_set_target_info_properties` which
was not able to process the NO_UNITY_BUILD_SOURCES, and therefore
leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I
decided to pass Unity Build arguments before them, and closer to
SOURCES, which is nicer to read, and avoid similar situation. And
I reverted the work around in the amend commit, and passing the
arguments normally.
This happens because we pass an unfiltered ${ARGN} from
qt_internal_add_executable to qt_set_target_info_properties and that the
current change is merely a workaround that ensures they get
circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option
appears before any of the first TARGET_ props.
Amend cd12c1f33281452d478bb94744d76bead5c7363a
Task-number: QTBUG-99238
Task-number: QTBUG-109394
Pick-to: 6.5
Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29
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>
The extra quote enforces the arguments to be string, and stops the
COMMAND_EXPAND_LISTS within
QtDbusHelpers.cmake::qt_create_qdbusxml2cpp_command from expanding it
as a list.
Fixes: QTBUG-110459
Fixes: QTBUG-110450
Task-number: QTBUG-99238
Change-Id: Ifddd6570c7bf8f2d1757f275d9445ce2924a93f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This replaces the qt_parse_all_arguments macro with the built-in
`cmake_parse_arguments(PARSE_ARGV`. In addition, a new function,
_qt_internal_validate_all_args_are_parsed, can be used to check whether
any _UNPARSED_ARGUMENTS have been passed to the function.
Fixes: QTBUG-99238
Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Set the RUNTIME_OUTPUT_DIRECTORY for configure-time executables so
executable will be located inside the QT_BUILD_DIR. This allows to
re-build syncqt and make sure ithat ts binary is replaced and located
in the libexec directory.
Comment on how to rebuild syncqt. Configure-time tools reserve the
original tool name for the imported executable. To re-build syncqt use
'syncqt_build' target.
Task-number: QTBUG-109792
Change-Id: Id7d912b1d75d18d82cb2a69fbd62b89440120d78
Reviewed-by: Jörg Bornemann <joerg.bornemann@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>
Use PARSE_ARGV signature of the cmake_parse_arguments function to avoid
escaping of semicolons when passing arguments to the
qt_internal_add_configure_time_tool and
qt_internal_add_configure_time_executable function.
Amends ac74b60c9c1101288eb2c558420ba69f675a2ee2
Task-number: QTBUG-87480
Change-Id: I343abbd75107e56aaccab6e388db8dbda0525af3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reflects the true state of exceptions on WASM, which are always
disabled (DISABLE_EXCEPTION_CATCHING is always set with 1).
Change-Id: I7b681846159caf61f291f78a7b4ddf5260dc341f
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>
This way it is able to pick up all of the properties assigned to it
before finalization.
Change-Id: I9da635f8620859a669c4e4d589fff56a3ce42ab9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The new batched test runner is now used for running the tests instead
of the wasm shell, which runs for single test cases.
Change-Id: I7b7e6dd7993ba7937124c5843356b6891301b893
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Developers can add to Emscripten's EXPORT_RUNTIME_METHODS
by defining their own using:
QT_WASM_EXTRA_EXPORTED_METHODS
Which will add on to Qt's default exported runtime methods
of UTF16ToString,stringToUTF16
for cmake:
set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
or
set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
for qmake:
QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap
Done-with: Mikolaj Boc
Fixes: QTBUG-104882
Pick-to: 6.4
Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60
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>
Warn projects not to use it because PUBLIC_LIBRARIES don't make
sense for executable targets and it also led to some issues in the
internal functions where some of them did not expect to receive
PUBLIC_LIBRARIES.
To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values
as regular LIBRARIES. In the future we might add an error instead.
Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally
worked because the option name and the values following it were
parsed as values of the "previous" option, like SOURCES or
INCLUDE_DIRECTORIES or LIBRARIES, and when those got
passed through to qt_internal_extend_target, things magically worked.
We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the
way qmake pro files were written and how pro2cmake converted them.
We'll have to clean up each repo.
Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
This works for in-source tools and tests as well, which don't go through
the same CMake machinery for plugins as user projects do. The only case
that does not currently work is in-source examples, as they don't share
any of the plugin machinery with neither Qt internal tools/tests or user
project, but that's a bigger architectural issue that goes beyond this
change.
Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Replace BOOTSTRAP option with the single value CORE_LIBRARY argument
in qt_internal_add_tool and qt_internal_add_executable functions.
The introduced argument now may accept 'Bootstap' and 'None' values.
Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None'
to avoid any core library linking. This is useful for tools that need
to use the CMake deployment routines, but not require the Qt::Core
functionality.
Task-number: QTBUG-87480
Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This introduces a new helper function,
qt_internal_add_repo_local_defines and makes use of it in
qt_internal_add_{module,test,executable,benchmark,plugin}. That function
checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the
defines listed in there will be aded to all targets passed to the
functions mentioned above.
The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set
in the repository local .cmake.conf. This allows e.g. opting in to
source incompatible changes in leaf modules (as long as those are
guarded by some define).
Pick-to: 6.2 6.3
Fixes: QTBUG-101640
Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
_qt_internal_android_executable_finalizer wraps Android-related
function that are needed to created an Android package.
The function is added to the INTERFACE_QT_EXECUTABLE_FINALIZERS
property in Qt Core so it's called implicitly for user projects.
Pick-to: 6.3
Change-Id: I140f53341691dcfdc6ae2ddea520818cf2834eb6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This change tries to make the API more user friendly and prevent wrong
use of multi-abi API. ANDROID_ABI argument of qt6_add_executable was
position-depend and needed to be placed after the executable 'sources'.
Using the target property we solve this problem and provide more
consistent and common way to enable multi-abi build for the single
target.
This meanwhile also requires to execute multi-abi build configuration
in the finalizer, since the property might be set at any point.
Also the priority of the QT_ANDROID_ABI target property now is higher
than the priority of the QT_ANDROID_BUILD_ALL_ABIS variable. So target
will only build packages with the ABIs specified in QT_ANDROID_ABI
property if both are set.
Pick-to: 6.3
Task-number: QTBUG-88841
Change-Id: I3515297ed267974498913c59619433dc234ec217
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A recent change refactored the call to qt_internal_add_executable(),
but that had the unintended side-effect of changing the symbol
visibility from public to hidden. That meant that main() became hidden,
so while apps still built successfully, they could not be run. Restore
the original symbol visibility to fix this regression.
Amends d47278fd09f73ddc34011ab980dafc23aa453e71
Pick-to: 6.2
Change-Id: I27d84ab2b0dd013d5c38dcfe55e88f307c4bc5dd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The EXE_FLAGS option wasn't being used anywhere in any Qt repo
and it had no documentation as to its intended use. Remove it.
Pick-to: 6.2
Change-Id: I2f67ec57c1da7dc6eab81d5351361e770d19d7d5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The _qt_is_android_executable property is normally set by the
_qt_internal_create_executable() command. But various other internal
commands don't route through that and go through
qt_internal_add_executable() instead. The former is used only by the
public API, the latter only by the internal API. Refactor both so that
the internal one calls the public one. This ensures all targets receive
the same base settings, including the _qt_is_android_executable
property.
Fixes: QTBUG-96085
Pick-to: 6.2
Change-Id: I157356872c9d942d7be5f1abbbcbac97961b1f40
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Debug tools are excluded from the ALL target for debug_and_release
builds. However, when using the -separate-debug-info option, the same
exclusion wasn't being applied for their dSYM INSTALL commands,
resulting in a CMake install error.
Pass any additional install args like
EXCLUDE_FROM_ALL COMPONENT "ExcludedExecutables"
to the installation rules of qt_enable_separate_debug_info and
install dSYMs for executables per-config in a multi-config build.
All the non-main config executable install rules are optional because
the non-main config executables are excluded from ALL.
Amends 5b136abd21803988f96b9b66c992822efbef97ec
Pick-to: 6.2
Fixes: QTBUG-93999
Change-Id: I95c3ce28215c3ee535551e4b7a5fa9731f8f1c28
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This function is called by qt_add_executable. There is no need to
expose it as public function.
Fixes: QTBUG-95172
Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
