2022-07-05 11:26:52 +00:00
|
|
|
# Copyright (C) 2022 The Qt Company Ltd.
|
2022-08-19 13:21:34 +00:00
|
|
|
# SPDX-License-Identifier: BSD-3-Clause
|
2022-07-05 11:26:52 +00:00
|
|
|
|
2020-08-13 15:37:47 +00:00
|
|
|
# This function is used to define a "Qt tool", such as moc, uic or rcc.
|
|
|
|
|
#
|
2021-02-11 13:01:58 +00:00
|
|
|
# USER_FACING can be passed to mark the tool as a program that is supposed to be
|
|
|
|
|
# started directly by users.
|
|
|
|
|
#
|
2020-08-13 15:37:47 +00:00
|
|
|
# We must pass this function a target name obtained from
|
|
|
|
|
# qt_get_tool_target_name like this:
|
|
|
|
|
# qt_get_tool_target_name(target_name my_tool)
|
2021-02-26 09:18:29 +00:00
|
|
|
# qt_internal_add_tool(${target_name})
|
2020-08-13 15:37:47 +00:00
|
|
|
#
|
2021-02-26 10:04:00 +00:00
|
|
|
# Option Arguments:
|
|
|
|
|
# INSTALL_VERSIONED_LINK
|
|
|
|
|
# Prefix build only. On installation, create a versioned hard-link of the installed file.
|
|
|
|
|
# E.g. create a link of "bin/qmake6" to "bin/qmake".
|
2023-05-03 14:01:27 +00:00
|
|
|
# TRY_RUN
|
|
|
|
|
# On Windows, it creates a helper batch script that tests whether the tool can be executed
|
|
|
|
|
# successfully or not. If not, build halts and an error will be show, with tips on what
|
2023-06-16 06:51:52 +00:00
|
|
|
# might be cause, and how to fix it. TRY_RUN is disabled when cross-compiling.
|
2023-06-13 14:37:49 +00:00
|
|
|
# TRY_RUN_FLAGS
|
|
|
|
|
# Command line flags that are going to be passed to the tool for testing its correctness.
|
|
|
|
|
# If no flags were given, we default to `-v`.
|
2024-09-08 15:01:48 +00:00
|
|
|
# REQUIRED_FOR_DOCS
|
|
|
|
|
# Specifies that the built tool is required to generate documentation. Examples are qdoc,
|
|
|
|
|
# and qvkgen (because they participate in header file generation, which are needed for
|
|
|
|
|
# documentation generation).
|
2021-02-26 10:04:00 +00:00
|
|
|
#
|
|
|
|
|
# One-value Arguments:
|
2021-01-25 10:11:27 +00:00
|
|
|
# EXTRA_CMAKE_FILES
|
|
|
|
|
# List of additional CMake files that will be installed alongside the tool's exported CMake
|
|
|
|
|
# files.
|
2021-05-27 08:33:05 +00:00
|
|
|
# EXTRA_CMAKE_INCLUDES
|
|
|
|
|
# List of files that will be included in the Qt6${module}Tools.cmake file.
|
|
|
|
|
# Also see TOOLS_TARGET.
|
2021-01-25 09:46:11 +00:00
|
|
|
# INSTALL_DIR
|
|
|
|
|
# Takes a path, relative to the install prefix, like INSTALL_LIBEXECDIR.
|
|
|
|
|
# If this argument is omitted, the default is INSTALL_BINDIR.
|
2021-01-25 10:11:27 +00:00
|
|
|
# TOOLS_TARGET
|
|
|
|
|
# Specifies the module this tool belongs to. The module's Qt6${module}Tools.cmake file
|
|
|
|
|
# will then contain targets for this tool.
|
2022-05-02 10:48:37 +00:00
|
|
|
# CORE_LIBRARY
|
|
|
|
|
# The argument accepts 'Bootstrap' or 'None' values. If the argument value is set to
|
|
|
|
|
# 'Bootstrap' the Qt::Bootstrap library is linked to the executable instead of Qt::Core.
|
|
|
|
|
# The 'None' value points that core library is not necessary and avoids linking neither
|
2022-06-10 14:41:59 +00:00
|
|
|
# Qt::Core or Qt::Bootstrap libraries. Otherwise the Qt::Core library will be publicly
|
2022-05-02 10:48:37 +00:00
|
|
|
# linked to the executable target by default.
|
2020-09-22 08:02:27 +00:00
|
|
|
function(qt_internal_add_tool target_name)
|
2020-08-13 15:37:47 +00:00
|
|
|
qt_tool_target_to_name(name ${target_name})
|
2023-01-31 13:05:16 +00:00
|
|
|
set(option_keywords
|
|
|
|
|
NO_INSTALL
|
|
|
|
|
USER_FACING
|
|
|
|
|
INSTALL_VERSIONED_LINK
|
|
|
|
|
EXCEPTIONS
|
2023-05-03 14:01:27 +00:00
|
|
|
NO_UNITY_BUILD
|
2024-06-14 17:07:16 +00:00
|
|
|
TRY_RUN
|
2024-09-08 15:01:48 +00:00
|
|
|
REQUIRED_FOR_DOCS
|
2024-06-14 17:07:16 +00:00
|
|
|
${__qt_internal_sbom_optional_args}
|
|
|
|
|
)
|
2021-05-27 08:33:05 +00:00
|
|
|
set(one_value_keywords
|
|
|
|
|
TOOLS_TARGET
|
|
|
|
|
INSTALL_DIR
|
2022-05-02 10:48:37 +00:00
|
|
|
CORE_LIBRARY
|
2023-06-13 14:37:49 +00:00
|
|
|
TRY_RUN_FLAGS
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
${__default_target_info_args}
|
|
|
|
|
${__qt_internal_sbom_single_args}
|
|
|
|
|
)
|
2021-05-27 08:33:05 +00:00
|
|
|
set(multi_value_keywords
|
|
|
|
|
EXTRA_CMAKE_FILES
|
|
|
|
|
EXTRA_CMAKE_INCLUDES
|
2022-07-19 17:56:22 +00:00
|
|
|
PUBLIC_LIBRARIES
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
${__default_private_args}
|
|
|
|
|
${__qt_internal_sbom_multi_args}
|
|
|
|
|
)
|
2023-01-11 14:36:18 +00:00
|
|
|
|
|
|
|
|
cmake_parse_arguments(PARSE_ARGV 1 arg
|
|
|
|
|
"${option_keywords}"
|
|
|
|
|
"${one_value_keywords}"
|
|
|
|
|
"${multi_value_keywords}")
|
|
|
|
|
_qt_internal_validate_all_args_are_parsed(arg)
|
2020-08-13 15:37:47 +00:00
|
|
|
|
2022-09-12 10:51:04 +00:00
|
|
|
qt_internal_find_tool(will_build_tools ${target_name} "${arg_TOOLS_TARGET}")
|
2020-08-13 15:37:47 +00:00
|
|
|
|
2022-09-12 10:51:04 +00:00
|
|
|
if(NOT will_build_tools)
|
|
|
|
|
return()
|
2020-08-13 15:37:47 +00:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
set(disable_autogen_tools "${arg_DISABLE_AUTOGEN_TOOLS}")
|
2022-05-02 10:48:37 +00:00
|
|
|
set(corelib "")
|
|
|
|
|
if(arg_CORE_LIBRARY STREQUAL "Bootstrap" OR arg_CORE_LIBRARY STREQUAL "None")
|
|
|
|
|
set(corelib CORE_LIBRARY ${arg_CORE_LIBRARY})
|
2021-01-28 15:06:26 +00:00
|
|
|
list(APPEND disable_autogen_tools "uic" "moc" "rcc")
|
2020-08-13 15:37:47 +00:00
|
|
|
endif()
|
|
|
|
|
|
2021-06-14 14:54:40 +00:00
|
|
|
set(exceptions "")
|
|
|
|
|
if(arg_EXCEPTIONS)
|
|
|
|
|
set(exceptions EXCEPTIONS)
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-01-25 09:46:11 +00:00
|
|
|
set(install_dir "${INSTALL_BINDIR}")
|
|
|
|
|
if(arg_INSTALL_DIR)
|
|
|
|
|
set(install_dir "${arg_INSTALL_DIR}")
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-07-07 14:04:17 +00:00
|
|
|
set(output_dir "${QT_BUILD_DIR}/${install_dir}")
|
|
|
|
|
|
2022-07-19 17:56:22 +00:00
|
|
|
if(arg_PUBLIC_LIBRARIES)
|
|
|
|
|
message(WARNING
|
|
|
|
|
"qt_internal_add_tool's PUBLIC_LIBRARIES option is deprecated, and will be "
|
|
|
|
|
"removed in a future Qt version. Use the LIBRARIES option instead.")
|
|
|
|
|
endif()
|
|
|
|
|
|
2023-01-31 13:05:16 +00:00
|
|
|
if(arg_NO_UNITY_BUILD)
|
2023-03-15 09:46:22 +00:00
|
|
|
set(arg_NO_UNITY_BUILD "NO_UNITY_BUILD")
|
2023-01-31 13:05:16 +00:00
|
|
|
else()
|
|
|
|
|
set(arg_NO_UNITY_BUILD "")
|
|
|
|
|
endif()
|
|
|
|
|
|
2024-11-08 13:26:32 +00:00
|
|
|
_qt_internal_forward_function_args(
|
|
|
|
|
FORWARD_PREFIX arg
|
|
|
|
|
FORWARD_OUT_VAR add_executable_args
|
|
|
|
|
FORWARD_SINGLE
|
|
|
|
|
TARGET_COMPANY
|
|
|
|
|
TARGET_COPYRIGHT
|
|
|
|
|
TARGET_DESCRIPTION
|
|
|
|
|
TARGET_PRODUCT
|
|
|
|
|
TARGET_VERSION
|
|
|
|
|
)
|
|
|
|
|
|
2021-07-07 14:04:17 +00:00
|
|
|
qt_internal_add_executable("${target_name}"
|
|
|
|
|
OUTPUT_DIRECTORY "${output_dir}"
|
2021-06-14 14:54:40 +00:00
|
|
|
${exceptions}
|
2020-08-13 15:37:47 +00:00
|
|
|
NO_INSTALL
|
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs
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>
2023-03-29 09:38:30 +00:00
|
|
|
${arg_NO_UNITY_BUILD}
|
2020-08-13 15:37:47 +00:00
|
|
|
SOURCES ${arg_SOURCES}
|
2023-08-06 10:58:45 +00:00
|
|
|
NO_PCH_SOURCES ${arg_NO_PCH_SOURCES}
|
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs
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>
2023-03-29 09:38:30 +00:00
|
|
|
NO_UNITY_BUILD_SOURCES ${arg_NO_UNITY_BUILD_SOURCES}
|
2020-08-13 15:37:47 +00:00
|
|
|
INCLUDE_DIRECTORIES
|
|
|
|
|
${arg_INCLUDE_DIRECTORIES}
|
|
|
|
|
DEFINES
|
|
|
|
|
${arg_DEFINES}
|
2022-05-02 10:48:37 +00:00
|
|
|
${corelib}
|
2022-07-19 17:56:22 +00:00
|
|
|
LIBRARIES
|
|
|
|
|
${arg_LIBRARIES}
|
|
|
|
|
${arg_PUBLIC_LIBRARIES}
|
|
|
|
|
Qt::PlatformToolInternal
|
2020-08-13 15:37:47 +00:00
|
|
|
COMPILE_OPTIONS ${arg_COMPILE_OPTIONS}
|
|
|
|
|
LINK_OPTIONS ${arg_LINK_OPTIONS}
|
|
|
|
|
MOC_OPTIONS ${arg_MOC_OPTIONS}
|
|
|
|
|
DISABLE_AUTOGEN_TOOLS ${disable_autogen_tools}
|
2024-11-08 13:26:32 +00:00
|
|
|
${add_executable_args}
|
2023-03-29 09:40:49 +00:00
|
|
|
# If you are putting anything after these, make sure that
|
|
|
|
|
# qt_set_target_info_properties knows how to process them
|
2020-08-13 15:37:47 +00:00
|
|
|
)
|
|
|
|
|
qt_internal_add_target_aliases("${target_name}")
|
2021-07-07 14:04:17 +00:00
|
|
|
qt_internal_adjust_main_config_runtime_output_dir("${target_name}" "${output_dir}")
|
2020-08-13 15:37:47 +00:00
|
|
|
|
2022-12-06 16:07:39 +00:00
|
|
|
if (WIN32)
|
|
|
|
|
_qt_internal_generate_longpath_win32_rc_file_and_manifest("${target_name}")
|
|
|
|
|
endif()
|
|
|
|
|
|
CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
|
|
|
set_target_properties(${target_name} PROPERTIES
|
|
|
|
|
_qt_package_version "${PROJECT_VERSION}"
|
|
|
|
|
)
|
|
|
|
|
set_property(TARGET ${target_name}
|
|
|
|
|
APPEND PROPERTY
|
|
|
|
|
EXPORT_PROPERTIES "_qt_package_version")
|
|
|
|
|
|
2025-01-07 17:16:29 +00:00
|
|
|
get_cmake_property(is_multi_config GENERATOR_IS_MULTI_CONFIG)
|
|
|
|
|
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.19.0"
|
|
|
|
|
AND QT_FEATURE_debug_and_release
|
|
|
|
|
AND is_multi_config)
|
2020-08-13 15:37:47 +00:00
|
|
|
set_property(TARGET "${target_name}"
|
|
|
|
|
PROPERTY EXCLUDE_FROM_ALL "$<NOT:$<CONFIG:${QT_MULTI_CONFIG_FIRST_CONFIG}>>")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (NOT target_name STREQUAL name)
|
|
|
|
|
set_target_properties(${target_name} PROPERTIES
|
|
|
|
|
OUTPUT_NAME ${name}
|
|
|
|
|
EXPORT_NAME ${name}
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(TARGET host_tools)
|
|
|
|
|
add_dependencies(host_tools "${target_name}")
|
2024-09-08 15:01:48 +00:00
|
|
|
if(arg_REQUIRED_FOR_DOCS)
|
|
|
|
|
add_dependencies(doc_tools "${target_name}")
|
|
|
|
|
endif()
|
2022-05-02 10:48:37 +00:00
|
|
|
if(arg_CORE_LIBRARY STREQUAL "Bootstrap")
|
2020-08-13 15:37:47 +00:00
|
|
|
add_dependencies(bootstrap_tools "${target_name}")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-10-27 16:35:58 +00:00
|
|
|
if(arg_EXTRA_CMAKE_FILES)
|
|
|
|
|
set_target_properties(${target_name} PROPERTIES
|
|
|
|
|
EXTRA_CMAKE_FILES "${arg_EXTRA_CMAKE_FILES}"
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-05-27 08:33:05 +00:00
|
|
|
if(arg_EXTRA_CMAKE_INCLUDES)
|
|
|
|
|
set_target_properties(${target_name} PROPERTIES
|
|
|
|
|
EXTRA_CMAKE_INCLUDES "${arg_EXTRA_CMAKE_INCLUDES}"
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-02-11 13:01:58 +00:00
|
|
|
if(arg_USER_FACING)
|
|
|
|
|
set_property(GLOBAL APPEND PROPERTY QT_USER_FACING_TOOL_TARGETS ${target_name})
|
|
|
|
|
endif()
|
|
|
|
|
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
if(QT_GENERATE_SBOM)
|
|
|
|
|
set(sbom_args "")
|
2025-09-04 12:03:16 +00:00
|
|
|
list(APPEND sbom_args DEFAULT_SBOM_ENTITY_TYPE QT_TOOL)
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
endif()
|
2020-08-13 15:37:47 +00:00
|
|
|
|
|
|
|
|
if(NOT arg_NO_INSTALL AND arg_TOOLS_TARGET)
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
set(will_install TRUE)
|
|
|
|
|
else()
|
|
|
|
|
set(will_install FALSE)
|
|
|
|
|
if(QT_GENERATE_SBOM)
|
|
|
|
|
list(APPEND sbom_args NO_INSTALL)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(will_install)
|
2020-08-13 15:37:47 +00:00
|
|
|
# Assign a tool to an export set, and mark the module to which the tool belongs.
|
|
|
|
|
qt_internal_append_known_modules_with_tools("${arg_TOOLS_TARGET}")
|
|
|
|
|
|
|
|
|
|
# Also append the tool to the module list.
|
|
|
|
|
qt_internal_append_known_module_tool("${arg_TOOLS_TARGET}" "${target_name}")
|
|
|
|
|
|
|
|
|
|
qt_get_cmake_configurations(cmake_configs)
|
|
|
|
|
|
|
|
|
|
set(install_initial_call_args
|
2024-09-08 14:47:30 +00:00
|
|
|
EXPORT "${INSTALL_CMAKE_NAMESPACE}${arg_TOOLS_TARGET}ToolsTargets"
|
|
|
|
|
COMPONENT host_tools
|
|
|
|
|
)
|
2020-08-13 15:37:47 +00:00
|
|
|
|
|
|
|
|
foreach(cmake_config ${cmake_configs})
|
|
|
|
|
qt_get_install_target_default_args(
|
|
|
|
|
OUT_VAR install_targets_default_args
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
OUT_VAR_RUNTIME runtime_install_destination
|
2021-01-25 09:46:11 +00:00
|
|
|
RUNTIME "${install_dir}"
|
2020-08-13 15:37:47 +00:00
|
|
|
CMAKE_CONFIG "${cmake_config}"
|
2024-05-27 12:59:02 +00:00
|
|
|
ALL_CMAKE_CONFIGS ${cmake_configs})
|
2020-11-06 20:48:08 +00:00
|
|
|
|
|
|
|
|
# Make installation optional for targets that are not built by default in this config
|
|
|
|
|
if(QT_FEATURE_debug_and_release
|
|
|
|
|
AND NOT (cmake_config STREQUAL QT_MULTI_CONFIG_FIRST_CONFIG))
|
|
|
|
|
set(install_optional_arg OPTIONAL)
|
|
|
|
|
else()
|
|
|
|
|
unset(install_optional_arg)
|
|
|
|
|
endif()
|
|
|
|
|
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
if(QT_GENERATE_SBOM)
|
|
|
|
|
_qt_internal_sbom_append_multi_config_aware_single_arg_option(
|
|
|
|
|
RUNTIME_PATH
|
|
|
|
|
"${runtime_install_destination}"
|
|
|
|
|
"${cmake_config}"
|
|
|
|
|
sbom_args
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-08-13 15:37:47 +00:00
|
|
|
qt_install(TARGETS "${target_name}"
|
|
|
|
|
${install_initial_call_args}
|
2020-11-06 20:48:08 +00:00
|
|
|
${install_optional_arg}
|
2020-08-13 15:37:47 +00:00
|
|
|
CONFIGURATIONS ${cmake_config}
|
|
|
|
|
${install_targets_default_args})
|
|
|
|
|
unset(install_initial_call_args)
|
|
|
|
|
endforeach()
|
|
|
|
|
|
2021-02-26 10:04:00 +00:00
|
|
|
if(arg_INSTALL_VERSIONED_LINK)
|
2022-12-05 13:50:31 +00:00
|
|
|
qt_internal_install_versioned_link(WORKING_DIRECTORY "${install_dir}"
|
|
|
|
|
TARGETS "${target_name}")
|
2021-02-26 10:04:00 +00:00
|
|
|
endif()
|
|
|
|
|
|
2021-01-25 09:46:11 +00:00
|
|
|
qt_apply_rpaths(TARGET "${target_name}" INSTALL_PATH "${install_dir}" RELATIVE_RPATH)
|
2022-04-14 16:04:41 +00:00
|
|
|
qt_internal_apply_staging_prefix_build_rpath_workaround()
|
2020-08-13 15:37:47 +00:00
|
|
|
endif()
|
|
|
|
|
|
2023-06-16 06:51:52 +00:00
|
|
|
if(arg_TRY_RUN AND WIN32 AND NOT CMAKE_CROSSCOMPILING)
|
2023-06-13 14:37:49 +00:00
|
|
|
if(NOT arg_TRY_RUN_FLAGS)
|
|
|
|
|
set(arg_TRY_RUN_FLAGS "-v")
|
|
|
|
|
endif()
|
|
|
|
|
_qt_internal_add_try_run_post_build("${target_name}" "${arg_TRY_RUN_FLAGS}")
|
2023-05-03 14:01:27 +00:00
|
|
|
endif()
|
|
|
|
|
|
2024-11-14 14:12:58 +00:00
|
|
|
qt_internal_defer_separate_debug_info("${target_name}"
|
|
|
|
|
SEPARATE_DEBUG_INFO_ARGS
|
|
|
|
|
"${install_dir}"
|
|
|
|
|
QT_EXECUTABLE
|
|
|
|
|
)
|
2021-01-25 09:46:11 +00:00
|
|
|
qt_internal_install_pdb_files(${target_name} "${install_dir}")
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
|
|
|
|
|
if(QT_GENERATE_SBOM)
|
2024-06-14 17:07:16 +00:00
|
|
|
_qt_internal_forward_function_args(
|
|
|
|
|
FORWARD_APPEND
|
|
|
|
|
FORWARD_PREFIX arg
|
|
|
|
|
FORWARD_OUT_VAR sbom_args
|
|
|
|
|
FORWARD_OPTIONS
|
|
|
|
|
${__qt_internal_sbom_optional_args}
|
|
|
|
|
FORWARD_SINGLE
|
|
|
|
|
${__qt_internal_sbom_single_args}
|
|
|
|
|
FORWARD_MULTI
|
|
|
|
|
${__qt_internal_sbom_multi_args}
|
|
|
|
|
)
|
|
|
|
|
|
2025-01-13 14:30:15 +00:00
|
|
|
qt_internal_extend_qt_entity_sbom(${target_name} ${sbom_args})
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
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>
2024-03-07 17:02:56 +00:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
qt_add_list_file_finalizer(qt_internal_finalize_tool ${target_name})
|
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
|
|
function(qt_internal_finalize_tool target)
|
|
|
|
|
_qt_internal_finalize_sbom(${target})
|
2020-08-13 15:37:47 +00:00
|
|
|
endfunction()
|
|
|
|
|
|
2023-06-13 14:37:49 +00:00
|
|
|
function(_qt_internal_add_try_run_post_build target try_run_flags)
|
2023-05-03 14:01:27 +00:00
|
|
|
qt_internal_get_upper_case_main_cmake_configuration(main_cmake_configuration)
|
|
|
|
|
get_target_property(target_out_dir ${target}
|
|
|
|
|
RUNTIME_OUTPUT_DIRECTORY_${main_cmake_configuration})
|
|
|
|
|
get_target_property(target_bin_dir ${target}
|
|
|
|
|
BINARY_DIR)
|
|
|
|
|
|
|
|
|
|
set(try_run_scripts_path "${target_bin_dir}/${target}_try_run.bat")
|
|
|
|
|
# The only reason -h is passed is because some of the tools, e.g., moc
|
|
|
|
|
# wait for an input without any arguments.
|
|
|
|
|
|
|
|
|
|
qt_configure_file(OUTPUT "${try_run_scripts_path}"
|
|
|
|
|
CONTENT "@echo off
|
|
|
|
|
|
2023-06-13 14:37:49 +00:00
|
|
|
${target_out_dir}/${target}.exe ${try_run_flags} > nul 2>&1
|
2023-05-03 14:01:27 +00:00
|
|
|
|
|
|
|
|
if \"%errorlevel%\" == \"-1073741515\" (
|
|
|
|
|
echo
|
|
|
|
|
echo '${target}' is built successfully, but some of the libraries
|
|
|
|
|
echo necessary for running it are missing. If you are building Qt with
|
|
|
|
|
echo 3rdparty libraries, make sure that you add their directory to the
|
|
|
|
|
echo PATH environment variable.
|
|
|
|
|
echo
|
|
|
|
|
exit /b %errorlevel%
|
|
|
|
|
)
|
|
|
|
|
echo. > ${target_bin_dir}/${target}_try_run_passed"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
add_custom_command(
|
|
|
|
|
OUTPUT
|
|
|
|
|
${target_bin_dir}/${target}_try_run_passed
|
|
|
|
|
DEPENDS
|
|
|
|
|
${target}
|
|
|
|
|
COMMAND
|
2023-06-19 08:54:37 +00:00
|
|
|
${CMAKE_COMMAND} -E env QT_COMMAND_LINE_PARSER_NO_GUI_MESSAGE_BOXES=1
|
|
|
|
|
${try_run_scripts_path}
|
2023-05-03 14:01:27 +00:00
|
|
|
COMMENT
|
|
|
|
|
"Testing ${target} by trying to run it."
|
|
|
|
|
VERBATIM
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
add_custom_target(${target}_try_run ALL
|
|
|
|
|
DEPENDS ${target_bin_dir}/${target}_try_run_passed)
|
|
|
|
|
endfunction()
|
|
|
|
|
|
2020-08-13 15:37:47 +00:00
|
|
|
function(qt_export_tools module_name)
|
2021-10-20 14:37:33 +00:00
|
|
|
# Bail out when not building tools.
|
|
|
|
|
if(NOT QT_WILL_BUILD_TOOLS)
|
2020-08-13 15:37:47 +00:00
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# If no tools were defined belonging to this module, don't create a config and targets file.
|
|
|
|
|
if(NOT "${module_name}" IN_LIST QT_KNOWN_MODULES_WITH_TOOLS)
|
|
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# The tools target name. For example: CoreTools
|
|
|
|
|
set(target "${module_name}Tools")
|
|
|
|
|
|
|
|
|
|
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
|
|
|
|
|
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
|
|
|
|
|
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
|
|
|
|
|
|
|
|
|
|
# Add the extra cmake statements to make the tool targets global, so it doesn't matter where
|
|
|
|
|
# find_package is called.
|
|
|
|
|
# Also assemble a list of tool targets to expose in the config file for informational purposes.
|
|
|
|
|
set(extra_cmake_statements "")
|
|
|
|
|
set(tool_targets "")
|
|
|
|
|
set(tool_targets_non_prefixed "")
|
|
|
|
|
|
|
|
|
|
# List of package dependencies that need be find_package'd when using the Tools package.
|
|
|
|
|
set(package_deps "")
|
2025-01-06 16:10:54 +00:00
|
|
|
set(third_party_deps "")
|
2020-08-13 15:37:47 +00:00
|
|
|
|
2020-10-27 16:35:58 +00:00
|
|
|
# Additional cmake files to install
|
|
|
|
|
set(extra_cmake_files "")
|
2021-05-27 08:33:05 +00:00
|
|
|
set(extra_cmake_includes "")
|
2020-10-27 16:35:58 +00:00
|
|
|
|
CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
|
|
|
set(first_tool_package_version "")
|
|
|
|
|
|
2025-03-05 10:27:25 +00:00
|
|
|
set(known_tools ${QT_KNOWN_MODULE_${module_name}_TOOLS})
|
|
|
|
|
|
|
|
|
|
foreach(tool_name IN LISTS known_tools)
|
2020-08-13 15:37:47 +00:00
|
|
|
# Specific tools can have package dependencies.
|
|
|
|
|
# e.g. qtwaylandscanner depends on WaylandScanner (non-qt package).
|
|
|
|
|
get_target_property(extra_packages "${tool_name}" QT_EXTRA_PACKAGE_DEPENDENCIES)
|
|
|
|
|
if(extra_packages)
|
2025-01-06 16:10:54 +00:00
|
|
|
foreach(third_party_dep IN LISTS extra_packages)
|
|
|
|
|
list(GET third_party_dep 0 third_party_dep_name)
|
|
|
|
|
list(GET third_party_dep 1 third_party_dep_version)
|
|
|
|
|
|
|
|
|
|
# Assume that all tool thirdparty deps are mandatory.
|
|
|
|
|
# TODO: Components are not supported
|
|
|
|
|
list(APPEND third_party_deps
|
|
|
|
|
"${third_party_dep_name}\\\;FALSE\\\;${third_party_dep_version}\\\;\\\;")
|
|
|
|
|
endforeach()
|
2020-08-13 15:37:47 +00:00
|
|
|
endif()
|
|
|
|
|
|
2020-10-27 16:35:58 +00:00
|
|
|
get_target_property(_extra_cmake_files "${tool_name}" EXTRA_CMAKE_FILES)
|
|
|
|
|
if (_extra_cmake_files)
|
|
|
|
|
foreach(cmake_file ${_extra_cmake_files})
|
|
|
|
|
file(COPY "${cmake_file}" DESTINATION "${config_build_dir}")
|
|
|
|
|
list(APPEND extra_cmake_files "${cmake_file}")
|
|
|
|
|
endforeach()
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-05-27 08:33:05 +00:00
|
|
|
get_target_property(_extra_cmake_includes "${tool_name}" EXTRA_CMAKE_INCLUDES)
|
|
|
|
|
if(_extra_cmake_includes)
|
|
|
|
|
list(APPEND extra_cmake_includes "${_extra_cmake_includes}")
|
|
|
|
|
endif()
|
|
|
|
|
|
2022-01-10 18:12:32 +00:00
|
|
|
if (QT_WILL_RENAME_TOOL_TARGETS)
|
2020-08-13 15:37:47 +00:00
|
|
|
string(REGEX REPLACE "_native$" "" tool_name ${tool_name})
|
|
|
|
|
endif()
|
2025-03-05 10:27:25 +00:00
|
|
|
# `__qt_${target}_targets_file_included` is defined in the QtModuleToolsConfig.cmake.in
|
2020-08-13 15:37:47 +00:00
|
|
|
set(extra_cmake_statements "${extra_cmake_statements}
|
2025-03-05 10:27:25 +00:00
|
|
|
if(__qt_${target}_targets_file_included AND ${INSTALL_CMAKE_NAMESPACE}${target}_FOUND)
|
2021-05-20 11:38:30 +00:00
|
|
|
__qt_internal_promote_target_to_global(${INSTALL_CMAKE_NAMESPACE}::${tool_name})
|
2020-08-13 15:37:47 +00:00
|
|
|
endif()
|
|
|
|
|
")
|
|
|
|
|
list(APPEND tool_targets "${QT_CMAKE_EXPORT_NAMESPACE}::${tool_name}")
|
|
|
|
|
list(APPEND tool_targets_non_prefixed "${tool_name}")
|
CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
|
|
|
|
|
|
|
|
if(NOT first_tool_package_version)
|
|
|
|
|
qt_internal_get_package_version_of_target("${tool_name}" tool_package_version)
|
|
|
|
|
if(tool_package_version)
|
|
|
|
|
set(first_tool_package_version "${tool_package_version}")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
2020-08-13 15:37:47 +00:00
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
string(APPEND extra_cmake_statements
|
|
|
|
|
"set(${QT_CMAKE_EXPORT_NAMESPACE}${module_name}Tools_TARGETS \"${tool_targets}\")")
|
|
|
|
|
|
|
|
|
|
# Extract package dependencies that were determined in QtPostProcess, but only if ${module_name}
|
|
|
|
|
# is an actual target.
|
|
|
|
|
# module_name can be a non-existent target, if the tool doesn't have an existing associated
|
|
|
|
|
# module, e.g. qtwaylandscanner.
|
|
|
|
|
if(TARGET "${module_name}")
|
|
|
|
|
get_target_property(module_package_deps "${module_name}" _qt_tools_package_deps)
|
|
|
|
|
if(module_package_deps)
|
|
|
|
|
list(APPEND package_deps "${module_package_deps}")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Configure and install dependencies file for the ${module_name}Tools package.
|
|
|
|
|
configure_file(
|
|
|
|
|
"${QT_CMAKE_DIR}/QtModuleToolsDependencies.cmake.in"
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
|
|
|
|
|
@ONLY
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
qt_install(FILES
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
|
|
|
|
|
DESTINATION "${config_install_dir}"
|
|
|
|
|
COMPONENT Devel
|
|
|
|
|
)
|
|
|
|
|
|
2020-10-27 16:35:58 +00:00
|
|
|
if(extra_cmake_files)
|
|
|
|
|
qt_install(FILES
|
|
|
|
|
${extra_cmake_files}
|
|
|
|
|
DESTINATION "${config_install_dir}"
|
|
|
|
|
COMPONENT Devel
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-08-13 15:37:47 +00:00
|
|
|
# Configure and install the ${module_name}Tools package Config file.
|
2020-11-30 07:46:49 +00:00
|
|
|
qt_internal_get_min_new_policy_cmake_version(min_new_policy_version)
|
|
|
|
|
qt_internal_get_max_new_policy_cmake_version(max_new_policy_version)
|
2020-08-13 15:37:47 +00:00
|
|
|
configure_package_config_file(
|
|
|
|
|
"${QT_CMAKE_DIR}/QtModuleToolsConfig.cmake.in"
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Config.cmake"
|
|
|
|
|
INSTALL_DESTINATION "${config_install_dir}"
|
|
|
|
|
)
|
CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
|
|
|
|
2025-03-05 10:27:25 +00:00
|
|
|
qt_configure_file(
|
|
|
|
|
OUTPUT "${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}TargetsPrecheck.cmake"
|
|
|
|
|
CONTENT
|
|
|
|
|
"_qt_internal_should_include_targets(
|
|
|
|
|
TARGETS ${known_tools}
|
|
|
|
|
NAMESPACE ${INSTALL_CMAKE_NAMESPACE}::
|
|
|
|
|
OUT_VAR_SHOULD_SKIP __qt_${target}_skip_include_targets_file
|
|
|
|
|
)
|
|
|
|
|
")
|
|
|
|
|
|
CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
|
|
|
# There might be Tools packages which don't have a corresponding real module_name target, like
|
|
|
|
|
# WaylandScannerTools.
|
|
|
|
|
# In that case we'll use the package version of the first tool that belongs to that package.
|
|
|
|
|
if(TARGET "${module_name}")
|
|
|
|
|
qt_internal_get_package_version_of_target("${module_name}" tools_package_version)
|
|
|
|
|
elseif(first_tool_package_version)
|
|
|
|
|
set(tools_package_version "${first_tool_package_version}")
|
|
|
|
|
else()
|
|
|
|
|
# This should never happen, because tools_package_version should always have at least some
|
|
|
|
|
# value. Issue an assertion message just in case the pre-condition ever changes.
|
|
|
|
|
set(tools_package_version "${PROJECT_VERSION}")
|
|
|
|
|
if(FEATURE_developer_build)
|
|
|
|
|
message(WARNING
|
|
|
|
|
"Could not determine package version of tools package ${module_name}. "
|
|
|
|
|
"Defaulting to project version ${PROJECT_VERSION}.")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
message(TRACE
|
|
|
|
|
"Exporting tools package ${module_name}Tools with package version ${tools_package_version}"
|
|
|
|
|
"\n included targets: ${tool_targets_non_prefixed}")
|
2020-08-13 15:37:47 +00:00
|
|
|
write_basic_package_version_file(
|
2021-10-22 11:38:00 +00:00
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersionImpl.cmake"
|
CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
|
|
|
VERSION "${tools_package_version}"
|
2020-08-13 15:37:47 +00:00
|
|
|
COMPATIBILITY AnyNewerVersion
|
|
|
|
|
ARCH_INDEPENDENT
|
|
|
|
|
)
|
2021-10-22 11:38:00 +00:00
|
|
|
qt_internal_write_qt_package_version_file(
|
|
|
|
|
"${INSTALL_CMAKE_NAMESPACE}${target}"
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersion.cmake"
|
|
|
|
|
)
|
2020-08-13 15:37:47 +00:00
|
|
|
|
|
|
|
|
qt_install(FILES
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Config.cmake"
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersion.cmake"
|
2021-10-22 11:38:00 +00:00
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersionImpl.cmake"
|
2025-03-05 10:27:25 +00:00
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}TargetsPrecheck.cmake"
|
2020-08-13 15:37:47 +00:00
|
|
|
DESTINATION "${config_install_dir}"
|
|
|
|
|
COMPONENT Devel
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set(export_name "${INSTALL_CMAKE_NAMESPACE}${target}Targets")
|
|
|
|
|
qt_install(EXPORT "${export_name}"
|
|
|
|
|
NAMESPACE "${QT_CMAKE_EXPORT_NAMESPACE}::"
|
|
|
|
|
DESTINATION "${config_install_dir}")
|
|
|
|
|
|
2020-09-25 10:18:58 +00:00
|
|
|
qt_internal_export_additional_targets_file(
|
2020-10-15 15:11:16 +00:00
|
|
|
TARGETS ${QT_KNOWN_MODULE_${module_name}_TOOLS}
|
|
|
|
|
TARGET_EXPORT_NAMES ${tool_targets}
|
2020-09-25 10:18:58 +00:00
|
|
|
EXPORT_NAME_PREFIX ${INSTALL_CMAKE_NAMESPACE}${target}
|
|
|
|
|
CONFIG_INSTALL_DIR "${config_install_dir}")
|
2020-08-13 15:37:47 +00:00
|
|
|
|
|
|
|
|
# Create versionless targets file.
|
|
|
|
|
configure_file(
|
|
|
|
|
"${QT_CMAKE_DIR}/QtModuleToolsVersionlessTargets.cmake.in"
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}VersionlessTargets.cmake"
|
|
|
|
|
@ONLY
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
qt_install(FILES
|
|
|
|
|
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}VersionlessTargets.cmake"
|
|
|
|
|
DESTINATION "${config_install_dir}"
|
|
|
|
|
COMPONENT Devel
|
|
|
|
|
)
|
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
|
|
# Returns the target name for the tool with the given name.
|
|
|
|
|
#
|
|
|
|
|
# In most cases, the target name is the same as the tool name.
|
|
|
|
|
# If the user specifies to build tools when cross-compiling, then the
|
|
|
|
|
# suffix "_native" is appended.
|
|
|
|
|
function(qt_get_tool_target_name out_var name)
|
2022-01-10 18:12:32 +00:00
|
|
|
if (QT_WILL_RENAME_TOOL_TARGETS)
|
2020-08-13 15:37:47 +00:00
|
|
|
set(${out_var} ${name}_native PARENT_SCOPE)
|
|
|
|
|
else()
|
|
|
|
|
set(${out_var} ${name} PARENT_SCOPE)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
|
|
# Returns the tool name for a given tool target.
|
|
|
|
|
# This is the inverse of qt_get_tool_target_name.
|
|
|
|
|
function(qt_tool_target_to_name out_var target)
|
|
|
|
|
set(name ${target})
|
2022-01-10 18:12:32 +00:00
|
|
|
if (QT_WILL_RENAME_TOOL_TARGETS)
|
2020-08-13 15:37:47 +00:00
|
|
|
string(REGEX REPLACE "_native$" "" name ${target})
|
|
|
|
|
endif()
|
|
|
|
|
set(${out_var} ${name} PARENT_SCOPE)
|
|
|
|
|
endfunction()
|
|
|
|
|
|
2022-01-10 18:12:32 +00:00
|
|
|
# Sets QT_WILL_BUILD_TOOLS if tools will be built and QT_WILL_RENAME_TOOL_TARGETS
|
|
|
|
|
# if those tools have replaced naming.
|
2020-08-13 15:37:47 +00:00
|
|
|
function(qt_check_if_tools_will_be_built)
|
2024-02-08 12:57:04 +00:00
|
|
|
# By default, we build our own tools unless we're cross-building or QT_HOST_PATH is set.
|
2022-01-10 18:12:32 +00:00
|
|
|
set(need_target_rename FALSE)
|
2024-02-08 12:57:04 +00:00
|
|
|
set(require_find_tools FALSE)
|
2022-01-10 18:12:32 +00:00
|
|
|
if(CMAKE_CROSSCOMPILING)
|
2020-08-13 15:37:47 +00:00
|
|
|
set(will_build_tools FALSE)
|
2022-01-10 18:12:32 +00:00
|
|
|
if(QT_FORCE_BUILD_TOOLS)
|
|
|
|
|
set(will_build_tools TRUE)
|
|
|
|
|
set(need_target_rename TRUE)
|
|
|
|
|
endif()
|
2024-02-08 12:57:04 +00:00
|
|
|
set(require_find_tools TRUE)
|
2020-08-13 15:37:47 +00:00
|
|
|
else()
|
2024-02-08 12:57:04 +00:00
|
|
|
if(QT_HOST_PATH)
|
|
|
|
|
set(will_build_tools FALSE)
|
|
|
|
|
else()
|
|
|
|
|
set(will_build_tools TRUE)
|
|
|
|
|
endif()
|
2022-01-10 18:12:32 +00:00
|
|
|
if(QT_FORCE_FIND_TOOLS)
|
|
|
|
|
set(will_build_tools FALSE)
|
2024-02-08 12:57:04 +00:00
|
|
|
set(require_find_tools TRUE)
|
|
|
|
|
endif()
|
|
|
|
|
if(QT_FORCE_BUILD_TOOLS)
|
|
|
|
|
set(will_build_tools TRUE)
|
|
|
|
|
set(need_target_rename TRUE)
|
2022-01-10 18:12:32 +00:00
|
|
|
endif()
|
2020-08-13 15:37:47 +00:00
|
|
|
endif()
|
2022-01-10 18:12:32 +00:00
|
|
|
|
2024-02-08 12:57:04 +00:00
|
|
|
set_property(GLOBAL PROPERTY qt_require_find_tools "${require_find_tools}")
|
|
|
|
|
|
2020-08-13 15:37:47 +00:00
|
|
|
set(QT_WILL_BUILD_TOOLS ${will_build_tools} CACHE INTERNAL "Are tools going to be built" FORCE)
|
2022-01-10 18:12:32 +00:00
|
|
|
set(QT_WILL_RENAME_TOOL_TARGETS ${need_target_rename} CACHE INTERNAL
|
|
|
|
|
"Do tool targets need to be renamed" FORCE)
|
2020-08-13 15:37:47 +00:00
|
|
|
endfunction()
|
|
|
|
|
|
2021-09-14 19:02:14 +00:00
|
|
|
# Use this macro to exit a file or function scope unless we're building tools. This is supposed to
|
|
|
|
|
# be called after qt_internal_add_tools() to avoid special-casing operations on imported targets.
|
|
|
|
|
macro(qt_internal_return_unless_building_tools)
|
|
|
|
|
if(NOT QT_WILL_BUILD_TOOLS)
|
|
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
endmacro()
|
|
|
|
|
|
2020-08-13 15:37:47 +00:00
|
|
|
# Equivalent of qmake's qtNomakeTools(directory1 directory2).
|
2020-10-19 11:35:15 +00:00
|
|
|
# If QT_BUILD_TOOLS_BY_DEFAULT is true, then targets within the given directories will be excluded
|
|
|
|
|
# from the default 'all' target, as well as from install phase. The private variable is checked by
|
|
|
|
|
# qt_internal_add_executable.
|
2020-08-13 15:37:47 +00:00
|
|
|
function(qt_exclude_tool_directories_from_default_target)
|
2020-10-19 11:35:15 +00:00
|
|
|
if(NOT QT_BUILD_TOOLS_BY_DEFAULT)
|
2020-08-13 15:37:47 +00:00
|
|
|
set(absolute_path_directories "")
|
|
|
|
|
foreach(directory ${ARGV})
|
|
|
|
|
list(APPEND absolute_path_directories "${CMAKE_CURRENT_SOURCE_DIR}/${directory}")
|
|
|
|
|
endforeach()
|
|
|
|
|
set(__qt_exclude_tool_directories "${absolute_path_directories}" PARENT_SCOPE)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
2022-09-12 10:51:04 +00:00
|
|
|
|
|
|
|
|
function(qt_internal_find_tool out_var target_name tools_target)
|
|
|
|
|
qt_tool_target_to_name(name ${target_name})
|
|
|
|
|
|
|
|
|
|
# Handle case when a tool does not belong to a module and it can't be built either (like
|
|
|
|
|
# during a cross-compile).
|
|
|
|
|
if(NOT tools_target AND NOT QT_WILL_BUILD_TOOLS)
|
|
|
|
|
message(FATAL_ERROR "The tool \"${name}\" has not been assigned to a module via"
|
|
|
|
|
" TOOLS_TARGET (so it can't be found) and it can't be built"
|
|
|
|
|
" (QT_WILL_BUILD_TOOLS is ${QT_WILL_BUILD_TOOLS}).")
|
|
|
|
|
endif()
|
|
|
|
|
|
2024-01-25 10:12:14 +00:00
|
|
|
if(NOT CMAKE_CROSSCOMPILING)
|
|
|
|
|
if(QT_INTERNAL_FORCE_FIND_HOST_TOOLS_MODULE_LIST AND
|
|
|
|
|
NOT "${tools_target}" IN_LIST QT_INTERNAL_FORCE_FIND_HOST_TOOLS_MODULE_LIST)
|
|
|
|
|
message(STATUS "Tool '${full_name}' will be built from source.")
|
|
|
|
|
set(${out_var} "TRUE" PARENT_SCOPE)
|
|
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2022-09-12 10:51:04 +00:00
|
|
|
if(QT_WILL_RENAME_TOOL_TARGETS AND (name STREQUAL target_name))
|
|
|
|
|
message(FATAL_ERROR
|
|
|
|
|
"qt_internal_add_tool must be passed a target obtained from qt_get_tool_target_name.")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
set(full_name "${QT_CMAKE_EXPORT_NAMESPACE}::${name}")
|
|
|
|
|
set(imported_tool_target_already_found FALSE)
|
|
|
|
|
|
|
|
|
|
# This condition can only be TRUE if a previous find_package(Qt6${tools_target}Tools)
|
|
|
|
|
# was already done. That can happen if QT_FORCE_FIND_TOOLS was ON or we're cross-compiling.
|
|
|
|
|
# In such a case, we need to exit early if we're not going to also build the tools.
|
|
|
|
|
if(TARGET ${full_name})
|
|
|
|
|
get_property(path TARGET ${full_name} PROPERTY LOCATION)
|
|
|
|
|
message(STATUS "Tool '${full_name}' was found at ${path}.")
|
|
|
|
|
set(imported_tool_target_already_found TRUE)
|
|
|
|
|
if(NOT QT_WILL_BUILD_TOOLS)
|
|
|
|
|
set(${out_var} "FALSE" PARENT_SCOPE)
|
|
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# We need to search for the host Tools package when doing a cross-build
|
|
|
|
|
# or when QT_FORCE_FIND_TOOLS is ON.
|
|
|
|
|
# As an optimiziation, we don't search for the package one more time if the target
|
|
|
|
|
# was already brought into scope from a previous find_package.
|
|
|
|
|
set(search_for_host_package FALSE)
|
|
|
|
|
if(NOT QT_WILL_BUILD_TOOLS OR QT_WILL_RENAME_TOOL_TARGETS)
|
|
|
|
|
set(search_for_host_package TRUE)
|
|
|
|
|
endif()
|
|
|
|
|
if(search_for_host_package AND NOT imported_tool_target_already_found)
|
|
|
|
|
set(tools_package_name "${INSTALL_CMAKE_NAMESPACE}${tools_target}Tools")
|
|
|
|
|
message(STATUS "Searching for tool '${full_name}' in package ${tools_package_name}.")
|
|
|
|
|
|
2025-03-05 10:27:25 +00:00
|
|
|
# TODO: Remove these once developers have reconfigured their project.
|
2022-09-12 10:51:04 +00:00
|
|
|
# Create the tool targets, even if QT_NO_CREATE_TARGETS is set.
|
|
|
|
|
# Otherwise targets like Qt6::moc are not available in a top-level cross-build.
|
|
|
|
|
set(BACKUP_QT_NO_CREATE_TARGETS ${QT_NO_CREATE_TARGETS})
|
|
|
|
|
set(QT_NO_CREATE_TARGETS OFF)
|
|
|
|
|
|
|
|
|
|
# When cross-compiling, we want to search for Tools packages in QT_HOST_PATH.
|
|
|
|
|
# To do that, we override CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH.
|
|
|
|
|
#
|
|
|
|
|
# We don't use find_package + PATHS option because any recursive find_dependency call
|
|
|
|
|
# inside a Tools package would not inherit the initial PATHS value given.
|
|
|
|
|
# TODO: Potentially we could set a global __qt_cmake_host_dir var like we currently
|
|
|
|
|
# do with _qt_cmake_dir in Qt6Config and change all our host tool find_package calls
|
|
|
|
|
# everywhere to specify that var in PATHS.
|
|
|
|
|
#
|
|
|
|
|
# Note though that due to path rerooting issue in
|
|
|
|
|
# https://gitlab.kitware.com/cmake/cmake/-/issues/21937
|
|
|
|
|
# we have to append a lib/cmake suffix to CMAKE_PREFIX_PATH so the value does not get
|
|
|
|
|
# rerooted on top of CMAKE_FIND_ROOT_PATH.
|
|
|
|
|
# Use QT_HOST_PATH_CMAKE_DIR for the suffix when available (it would be set by
|
|
|
|
|
# the qt.toolchain.cmake file when building other repos or given by the user when
|
|
|
|
|
# configuring qtbase) or derive it from from the Qt6HostInfo package which is
|
|
|
|
|
# found in QtSetup.
|
|
|
|
|
set(${tools_package_name}_BACKUP_CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH})
|
|
|
|
|
set(${tools_package_name}_BACKUP_CMAKE_FIND_ROOT_PATH "${CMAKE_FIND_ROOT_PATH}")
|
|
|
|
|
if(QT_HOST_PATH_CMAKE_DIR)
|
|
|
|
|
set(qt_host_path_cmake_dir_absolute "${QT_HOST_PATH_CMAKE_DIR}")
|
2025-03-17 16:54:32 +00:00
|
|
|
elseif(${INSTALL_CMAKE_NAMESPACE}HostInfo_DIR)
|
2022-09-12 10:51:04 +00:00
|
|
|
get_filename_component(qt_host_path_cmake_dir_absolute
|
2025-03-17 16:54:32 +00:00
|
|
|
"${${INSTALL_CMAKE_NAMESPACE}HostInfo_DIR}/.." ABSOLUTE)
|
2022-09-12 10:51:04 +00:00
|
|
|
else()
|
|
|
|
|
# This should never happen, serves as an assert.
|
|
|
|
|
message(FATAL_ERROR
|
|
|
|
|
"Neither QT_HOST_PATH_CMAKE_DIR nor "
|
2025-03-17 16:54:32 +00:00
|
|
|
"${INSTALL_CMAKE_NAMESPACE}HostInfo_DIR available.")
|
2022-09-12 10:51:04 +00:00
|
|
|
endif()
|
|
|
|
|
set(CMAKE_PREFIX_PATH "${qt_host_path_cmake_dir_absolute}")
|
|
|
|
|
|
|
|
|
|
# Look for tools in additional host Qt installations. This is done for conan support where
|
|
|
|
|
# we have separate installation prefixes per package. For simplicity, we assume here that
|
|
|
|
|
# all host Qt installations use the same value of INSTALL_LIBDIR.
|
|
|
|
|
if(DEFINED QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH)
|
|
|
|
|
file(RELATIVE_PATH rel_host_cmake_dir "${QT_HOST_PATH}"
|
|
|
|
|
"${qt_host_path_cmake_dir_absolute}")
|
|
|
|
|
foreach(host_path IN LISTS QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH)
|
|
|
|
|
set(host_cmake_dir "${host_path}/${rel_host_cmake_dir}")
|
|
|
|
|
list(PREPEND CMAKE_PREFIX_PATH "${host_cmake_dir}")
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH}")
|
|
|
|
|
endif()
|
|
|
|
|
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_HOST_PATH}")
|
|
|
|
|
|
|
|
|
|
find_package(
|
|
|
|
|
${tools_package_name}
|
|
|
|
|
${PROJECT_VERSION}
|
|
|
|
|
NO_PACKAGE_ROOT_PATH
|
|
|
|
|
NO_CMAKE_ENVIRONMENT_PATH
|
|
|
|
|
NO_SYSTEM_ENVIRONMENT_PATH
|
|
|
|
|
NO_CMAKE_PACKAGE_REGISTRY
|
|
|
|
|
NO_CMAKE_SYSTEM_PATH
|
|
|
|
|
NO_CMAKE_SYSTEM_PACKAGE_REGISTRY)
|
|
|
|
|
|
|
|
|
|
# Restore backups.
|
|
|
|
|
set(CMAKE_FIND_ROOT_PATH "${${tools_package_name}_BACKUP_CMAKE_FIND_ROOT_PATH}")
|
|
|
|
|
set(CMAKE_PREFIX_PATH "${${tools_package_name}_BACKUP_CMAKE_PREFIX_PATH}")
|
2025-03-05 10:27:25 +00:00
|
|
|
# TODO: Remove these once developers have reconfigured their project.
|
2022-09-12 10:51:04 +00:00
|
|
|
set(QT_NO_CREATE_TARGETS ${BACKUP_QT_NO_CREATE_TARGETS})
|
|
|
|
|
|
|
|
|
|
if(${${tools_package_name}_FOUND} AND TARGET ${full_name})
|
|
|
|
|
# Even if the tool is already visible, make sure that our modules remain associated
|
|
|
|
|
# with the tools.
|
|
|
|
|
qt_internal_append_known_modules_with_tools("${tools_target}")
|
|
|
|
|
get_property(path TARGET ${full_name} PROPERTY LOCATION)
|
|
|
|
|
message(STATUS "${full_name} was found at ${path} using package ${tools_package_name}.")
|
|
|
|
|
if (NOT QT_FORCE_BUILD_TOOLS)
|
|
|
|
|
set(${out_var} "FALSE" PARENT_SCOPE)
|
|
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2024-02-08 12:57:04 +00:00
|
|
|
get_property(require_find_tools GLOBAL PROPERTY qt_require_find_tools)
|
|
|
|
|
if(require_find_tools AND NOT TARGET ${full_name})
|
2022-09-12 10:51:04 +00:00
|
|
|
if(${${tools_package_name}_FOUND})
|
|
|
|
|
set(pkg_found_msg "")
|
|
|
|
|
string(APPEND pkg_found_msg
|
|
|
|
|
"the ${tools_package_name} package, but the package did not contain the tool. "
|
|
|
|
|
"Make sure that the host module ${tools_target} was built with all features "
|
|
|
|
|
"enabled (no explicitly disabled tools).")
|
|
|
|
|
else()
|
|
|
|
|
set(pkg_found_msg "")
|
|
|
|
|
string(APPEND pkg_found_msg
|
|
|
|
|
"the ${tools_package_name} package, but the package could not be found. "
|
|
|
|
|
"Make sure you have built and installed the host ${tools_target} module, "
|
|
|
|
|
"which will ensure the creation of the ${tools_package_name} package.")
|
|
|
|
|
endif()
|
|
|
|
|
message(FATAL_ERROR
|
|
|
|
|
"Failed to find the host tool \"${full_name}\". It is part of "
|
|
|
|
|
${pkg_found_msg})
|
2024-02-08 12:57:04 +00:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(QT_WILL_BUILD_TOOLS)
|
2022-09-12 10:51:04 +00:00
|
|
|
message(STATUS "Tool '${full_name}' will be built from source.")
|
|
|
|
|
endif()
|
|
|
|
|
set(${out_var} "TRUE" PARENT_SCOPE)
|
|
|
|
|
endfunction()
|
2022-08-03 15:46:15 +00:00
|
|
|
|
|
|
|
|
# This function adds an internal tool that should be compiled at configure time.
|
|
|
|
|
# TOOLS_TARGET
|
|
|
|
|
# Specifies the module this tool belongs to. The Qt6${TOOLS_TARGET}Tools module
|
|
|
|
|
# will then expose targets for this tool. Ignored if NO_INSTALL is set.
|
|
|
|
|
function(qt_internal_add_configure_time_tool target_name)
|
2023-01-11 12:35:10 +00:00
|
|
|
set(one_value_args INSTALL_DIRECTORY TOOLS_TARGET CONFIG)
|
2022-08-03 15:46:15 +00:00
|
|
|
set(multi_value_args)
|
|
|
|
|
set(option_args NO_INSTALL)
|
2022-09-15 09:56:42 +00:00
|
|
|
cmake_parse_arguments(PARSE_ARGV 1 arg
|
|
|
|
|
"${option_args}" "${one_value_args}" "${multi_value_args}")
|
2022-08-03 15:46:15 +00:00
|
|
|
|
|
|
|
|
qt_internal_find_tool(will_build_tools ${target_name} "${arg_TOOLS_TARGET}")
|
|
|
|
|
if(NOT will_build_tools)
|
|
|
|
|
return()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
qt_tool_target_to_name(name ${target_name})
|
|
|
|
|
set(extra_args "")
|
|
|
|
|
if(arg_NO_INSTALL OR NOT arg_TOOLS_TARGET)
|
|
|
|
|
list(APPEND extra_args "NO_INSTALL")
|
|
|
|
|
else()
|
|
|
|
|
set(install_dir "${INSTALL_BINDIR}")
|
|
|
|
|
if(arg_INSTALL_DIRECTORY)
|
|
|
|
|
set(install_dir "${arg_INSTALL_DIRECTORY}")
|
|
|
|
|
endif()
|
|
|
|
|
set(extra_args "INSTALL_DIRECTORY" "${install_dir}")
|
|
|
|
|
endif()
|
|
|
|
|
|
2023-01-11 12:35:10 +00:00
|
|
|
if(arg_CONFIG)
|
|
|
|
|
set(tool_config "${arg_CONFIG}")
|
|
|
|
|
elseif(QT_MULTI_CONFIG_FIRST_CONFIG)
|
|
|
|
|
set(tool_config "${arg_QT_MULTI_CONFIG_FIRST_CONFIG}")
|
|
|
|
|
else()
|
|
|
|
|
set(tool_config "${CMAKE_BUILD_TYPE}")
|
|
|
|
|
endif()
|
|
|
|
|
|
2022-08-15 16:29:41 +00:00
|
|
|
string(REPLACE "\\\;" "\\\\\\\;" unparsed_arguments "${arg_UNPARSED_ARGUMENTS}")
|
2022-08-03 15:46:15 +00:00
|
|
|
qt_internal_add_configure_time_executable(${target_name}
|
|
|
|
|
OUTPUT_NAME ${name}
|
2023-01-11 12:35:10 +00:00
|
|
|
CONFIG ${tool_config}
|
2022-08-03 15:46:15 +00:00
|
|
|
${extra_args}
|
2022-08-15 16:29:41 +00:00
|
|
|
${unparsed_arguments}
|
2022-08-03 15:46:15 +00:00
|
|
|
)
|
|
|
|
|
|
2023-01-03 16:44:37 +00:00
|
|
|
if(TARGET host_tools)
|
|
|
|
|
add_dependencies(host_tools "${target_name}_build")
|
|
|
|
|
endif()
|
|
|
|
|
|
2022-08-03 15:46:15 +00:00
|
|
|
if(NOT arg_NO_INSTALL AND arg_TOOLS_TARGET)
|
|
|
|
|
qt_internal_add_targets_to_additional_targets_export_file(
|
|
|
|
|
TARGETS ${target_name}
|
|
|
|
|
TARGET_EXPORT_NAMES ${QT_CMAKE_EXPORT_NAMESPACE}::${name}
|
|
|
|
|
EXPORT_NAME_PREFIX ${INSTALL_CMAKE_NAMESPACE}${arg_TOOLS_TARGET}Tools
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
