2019-06-05 15:15:20 +00:00
|
|
|
# Propagate common variables via BuildInternals package.
|
|
|
|
set(QT_BUILD_SHARED_LIBS @BUILD_SHARED_LIBS@)
|
|
|
|
option(BUILD_SHARED_LIBS "Build Qt statically or dynamically" @BUILD_SHARED_LIBS@)
|
|
|
|
set(QT_CMAKE_EXPORT_NAMESPACE @QT_CMAKE_EXPORT_NAMESPACE@)
|
|
|
|
set(INSTALL_CMAKE_NAMESPACE @INSTALL_CMAKE_NAMESPACE@)
|
|
|
|
set(QT_BUILD_INTERNALS_PATH "${CMAKE_CURRENT_LIST_DIR}")
|
|
|
|
|
CMake: Make build system of installed Qt more relocatable
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
|
|
|
# The relocatable install prefix is meant to be used to find things like host binaries (syncqt),
|
|
|
|
# when the CMAKE_INSTALL_PREFIX is overridden to point to a different path (like when building a
|
|
|
|
# a Qt repo using Conan, which will set a random install prefix instead of installing into the
|
|
|
|
# original Qt install prefix).
|
|
|
|
get_filename_component(QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX
|
|
|
|
${CMAKE_CURRENT_LIST_DIR}/../@qt_path_from_cmake_config_dir_to_prefix@
|
|
|
|
ABSOLUTE)
|
2019-06-05 15:15:20 +00:00
|
|
|
|
2022-07-11 09:05:55 +00:00
|
|
|
# Stores in out_var the new install/staging prefix for this build.
|
|
|
|
#
|
|
|
|
# new_prefix: the new prefix for this repository
|
|
|
|
# orig_prefix: the prefix that was used when qtbase was configured
|
|
|
|
#
|
2022-07-11 13:11:35 +00:00
|
|
|
# On Windows hosts: if the original prefix does not start with a drive letter, this function removes
|
|
|
|
# the drive letter from the new prefix. This is needed for installation with DESTDIR set.
|
2022-07-11 09:05:55 +00:00
|
|
|
function(qt_internal_new_prefix out_var new_prefix orig_prefix)
|
|
|
|
if(CMAKE_HOST_WIN32)
|
2022-07-11 13:11:35 +00:00
|
|
|
set(drive_letter_regexp "^[a-zA-Z]:")
|
|
|
|
if(new_prefix MATCHES "${drive_letter_regexp}"
|
|
|
|
AND NOT orig_prefix MATCHES "${drive_letter_regexp}")
|
|
|
|
string(SUBSTRING "${new_prefix}" 2 -1 new_prefix)
|
2022-07-11 09:05:55 +00:00
|
|
|
endif()
|
|
|
|
endif()
|
|
|
|
set(${out_var} "${new_prefix}" PARENT_SCOPE)
|
|
|
|
endfunction()
|
|
|
|
|
CMake: Make build system of installed Qt more relocatable
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
|
|
|
# If no explicit CMAKE_INSTALL_PREFIX is provided, force set the original Qt installation prefix,
|
|
|
|
# so that further modules / repositories are installed into same original location.
|
|
|
|
# This means by default when configuring qtsvg / qtdeclarative, they will be installed the regular
|
|
|
|
# Qt installation prefix.
|
|
|
|
# If an explicit installation prefix is specified, honor it.
|
|
|
|
# This is an attempt to support Conan, aka handle installation of modules into a
|
|
|
|
# different installation prefix than the original one. Also allow to opt out via a special variable.
|
2021-11-08 16:07:35 +00:00
|
|
|
# In a top-level build, QtSetup.cmake takes care of setting CMAKE_INSTALL_PREFIX.
|
CMake: Make build system of installed Qt more relocatable
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
|
|
|
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND
|
2021-11-08 16:07:35 +00:00
|
|
|
NOT QT_BUILD_INTERNALS_NO_FORCE_SET_INSTALL_PREFIX
|
|
|
|
AND NOT QT_SUPERBUILD)
|
2021-04-19 14:13:14 +00:00
|
|
|
set(qtbi_orig_prefix "@CMAKE_INSTALL_PREFIX@")
|
2022-01-11 12:26:54 +00:00
|
|
|
set(qtbi_orig_staging_prefix "@CMAKE_STAGING_PREFIX@")
|
2022-07-11 09:05:55 +00:00
|
|
|
qt_internal_new_prefix(qtbi_new_prefix
|
|
|
|
"${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}"
|
|
|
|
"${qtbi_orig_prefix}")
|
2022-01-11 12:26:54 +00:00
|
|
|
if(NOT qtbi_orig_staging_prefix STREQUAL ""
|
|
|
|
AND "${CMAKE_STAGING_PREFIX}" STREQUAL ""
|
|
|
|
AND NOT QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX)
|
2022-07-11 09:05:55 +00:00
|
|
|
qt_internal_new_prefix(qtbi_new_staging_prefix
|
|
|
|
"${qtbi_new_prefix}"
|
|
|
|
"${qtbi_orig_staging_prefix}")
|
|
|
|
set(CMAKE_STAGING_PREFIX "${qtbi_new_staging_prefix}" CACHE PATH
|
2022-01-11 12:26:54 +00:00
|
|
|
"Staging path prefix, prepended onto install directories on the host machine." FORCE)
|
|
|
|
set(qtbi_new_prefix "${qtbi_orig_prefix}")
|
|
|
|
endif()
|
2021-04-19 14:13:14 +00:00
|
|
|
set(CMAKE_INSTALL_PREFIX "${qtbi_new_prefix}" CACHE PATH
|
CMake: Make build system of installed Qt more relocatable
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
|
|
|
"Install path prefix, prepended onto install directories." FORCE)
|
2021-04-19 14:13:14 +00:00
|
|
|
unset(qtbi_orig_prefix)
|
|
|
|
unset(qtbi_new_prefix)
|
2022-01-11 12:26:54 +00:00
|
|
|
unset(qtbi_orig_staging_prefix)
|
2022-07-11 09:05:55 +00:00
|
|
|
unset(qtbi_new_staging_prefix)
|
CMake: Make build system of installed Qt more relocatable
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
|
|
|
endif()
|
2020-04-30 15:00:13 +00:00
|
|
|
|
2019-06-05 15:15:20 +00:00
|
|
|
# Propagate developer builds to other modules via BuildInternals package.
|
|
|
|
if(@FEATURE_developer_build@)
|
|
|
|
set(FEATURE_developer_build ON CACHE BOOL "Developer build." FORCE)
|
|
|
|
endif()
|
2019-07-22 15:30:24 +00:00
|
|
|
|
|
|
|
# Propagate non-prefix builds.
|
|
|
|
set(QT_WILL_INSTALL @QT_WILL_INSTALL@ CACHE BOOL
|
|
|
|
"Boolean indicating if doing a Qt prefix build (vs non-prefix build)." FORCE)
|
Ugly fix for handling QT_SOURCE_TREE
QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf.
In qtbase, it's used throughout various
projects to find cpp sources when building standalone tests (among
other things).
Everything works fine with qmake, because even if qmake is invoked
on the tests subfolder, qmake searches up the source directory tree
until it finds a .qmake.conf file, and uses that.
When building qttools with qmake, the qdoc project expects
to have a QT_SOURCE_TREE value, but it's not actually set in the
qttools/.qmake.conf file, so the generated include paths that use
that value are incorrect. Curiously the build still succeeds.
Now in CMake land we replaced QT_SOURCE_TREE with
CMAKE_SOURCE_DIR, but that does not work properly when doing a
standalone tests build, because the project in that case is the
tests one, and not the qtbase one, so configuration fails in a
developer build when trying to configure some private tests.
So far I've found that only qtbase actively uses this value.
A temporary fix is to save the qtbase source directory into a
QT_SOURCE_TREE variable inside the generated
BuildInternalsExtra.cmake file.
The pro2cmake script is changed to handle presence of QT_SOURCE_TREE
in a qrc file path. This is handled by finding the location of a
.qmake.conf file starting from the project file absolute path.
This is needed to stop the script from crashing when handling
the mimedatabase test projects for example.
The change also regenerates the relevant failing test projects, and
thus standalone tests (when doing developer builds aka private_tests
enabled) now configure and build successfully.
Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-26 16:59:53 +00:00
|
|
|
|
|
|
|
set(QT_SOURCE_TREE "@QT_SOURCE_TREE@" CACHE PATH
|
|
|
|
"A path to the source tree of the previously configured QtBase project." FORCE)
|
2019-08-13 13:51:56 +00:00
|
|
|
|
2019-09-06 09:52:47 +00:00
|
|
|
# Propagate decision of building tests and examples to other repositories.
|
2020-10-19 11:35:15 +00:00
|
|
|
set(QT_BUILD_TESTS @QT_BUILD_TESTS@ CACHE BOOL "Build the testing tree.")
|
|
|
|
set(QT_BUILD_EXAMPLES @QT_BUILD_EXAMPLES@ CACHE BOOL "Build Qt examples")
|
2021-08-12 09:17:58 +00:00
|
|
|
set(QT_BUILD_BENCHMARKS @QT_BUILD_BENCHMARKS@ CACHE BOOL "Build Qt Benchmarks")
|
|
|
|
set(QT_BUILD_MANUAL_TESTS @QT_BUILD_MANUAL_TESTS@ CACHE BOOL "Build Qt manual tests")
|
|
|
|
set(QT_BUILD_MINIMAL_STATIC_TESTS @QT_BUILD_MINIMAL_STATIC_TESTS@ CACHE BOOL
|
|
|
|
"Build minimal subset of tests for static Qt builds")
|
2022-06-21 13:32:00 +00:00
|
|
|
set(QT_BUILD_MINIMAL_ANDROID_MULTI_ABI_TESTS @QT_BUILD_MINIMAL_ANDROID_MULTI_ABI_TESTS@ CACHE BOOL
|
|
|
|
"Build minimal subset of tests for Android multi-ABI Qt builds")
|
2021-08-12 09:17:58 +00:00
|
|
|
|
2022-07-12 16:15:24 +00:00
|
|
|
set(QT_BUILD_TESTS_BATCHED @QT_BUILD_TESTS_BATCHED@ CACHE BOOL
|
|
|
|
"Should all tests be batched into a single binary.")
|
|
|
|
|
2020-10-19 11:35:15 +00:00
|
|
|
set(QT_BUILD_TESTS_BY_DEFAULT @QT_BUILD_TESTS_BY_DEFAULT@ CACHE BOOL
|
2019-11-04 13:43:39 +00:00
|
|
|
"Should tests be built as part of the default 'all' target.")
|
2020-10-19 11:35:15 +00:00
|
|
|
set(QT_BUILD_EXAMPLES_BY_DEFAULT @QT_BUILD_EXAMPLES_BY_DEFAULT@ CACHE BOOL
|
2019-11-04 13:43:39 +00:00
|
|
|
"Should examples be built as part of the default 'all' target.")
|
2021-08-12 09:17:58 +00:00
|
|
|
set(QT_BUILD_TOOLS_BY_DEFAULT @QT_BUILD_TOOLS_BY_DEFAULT@ CACHE BOOL
|
|
|
|
"Should tools be built as part of the default 'all' target.")
|
2019-09-06 09:52:47 +00:00
|
|
|
|
2021-09-03 15:08:50 +00:00
|
|
|
set(QT_BUILD_EXAMPLES_AS_EXTERNAL "@QT_BUILD_EXAMPLES_AS_EXTERNAL@" CACHE BOOL
|
|
|
|
"Should examples be built as ExternalProjects.")
|
|
|
|
|
2019-12-06 14:12:17 +00:00
|
|
|
# Propagate usage of ccache.
|
|
|
|
set(QT_USE_CCACHE @QT_USE_CCACHE@ CACHE BOOL "Enable the use of ccache")
|
|
|
|
|
2023-06-22 15:38:39 +00:00
|
|
|
# Propagate usage of vcpkg, ON by default.
|
|
|
|
set(QT_USE_VCPKG @QT_USE_VCPKG@ CACHE BOOL "Enable the use of vcpkg")
|
|
|
|
|
2023-02-08 11:08:37 +00:00
|
|
|
# Propagate usage of unity build.
|
|
|
|
set(QT_UNITY_BUILD @QT_UNITY_BUILD@ CACHE BOOL "Enable unity (jumbo) build")
|
|
|
|
set(QT_UNITY_BUILD_BATCH_SIZE "@QT_UNITY_BUILD_BATCH_SIZE@" CACHE STRING "Unity build batch size")
|
|
|
|
|
2022-11-02 15:22:04 +00:00
|
|
|
# Propragate the value of WARNINGS_ARE_ERRORS.
|
|
|
|
set(WARNINGS_ARE_ERRORS "@WARNINGS_ARE_ERRORS@" CACHE BOOL "Build Qt with warnings as errors")
|
|
|
|
|
2021-05-12 12:03:57 +00:00
|
|
|
# Propagate usage of versioned hard link.
|
|
|
|
set(QT_CREATE_VERSIONED_HARD_LINK "@QT_CREATE_VERSIONED_HARD_LINK@" CACHE BOOL
|
|
|
|
"Enable the use of versioned hard link")
|
|
|
|
|
2021-07-22 14:23:51 +00:00
|
|
|
# The minimum version required to build Qt.
|
|
|
|
set(QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT "@supported_min_version_for_building_qt@")
|
|
|
|
set(QT_COMPUTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT "@computed_min_version_for_building_qt@")
|
|
|
|
|
|
|
|
# The lower and upper CMake version policy range as computed by qtbase.
|
|
|
|
# These values are inherited when building other Qt repositories, unless overridden
|
|
|
|
# in the respective repository .cmake.conf file.
|
|
|
|
# These are not cache variables, so that they can be overridden in each repo directory scope.
|
|
|
|
if(NOT DEFINED QT_MIN_NEW_POLICY_CMAKE_VERSION)
|
|
|
|
set(QT_MIN_NEW_POLICY_CMAKE_VERSION "@min_new_policy_version@")
|
|
|
|
endif()
|
|
|
|
if(NOT DEFINED QT_MAX_NEW_POLICY_CMAKE_VERSION)
|
|
|
|
set(QT_MAX_NEW_POLICY_CMAKE_VERSION "@max_new_policy_version@")
|
|
|
|
endif()
|
|
|
|
|
2022-01-19 12:13:12 +00:00
|
|
|
get_property(__qt_internal_extras_is_multi_config GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
|
|
|
|
|
|
|
|
# We want the same build type to be used when configuring all Qt repos or standalone
|
|
|
|
# tests or single tests.
|
|
|
|
# To do that, we need to force-set the CMAKE_BUILD_TYPE cache var because CMake itself
|
|
|
|
# initializes it with the value of CMAKE_BUILD_TYPE_INIT at the start of project
|
|
|
|
# configuration, so we need to override it.
|
|
|
|
# Note the value of CMAKE_BUILD_TYPE_INIT is different based on the platform, most
|
|
|
|
# Linux and macOS platforms will have it empty, but Windows platforms will have a value.
|
|
|
|
#
|
|
|
|
# We can't reliably differentiate between a value set on the command line by the user
|
|
|
|
# and one set by CMake, so we use a few heuristics:
|
|
|
|
# 1) When using a qt.toolchain.cmake file, we rely on the toolchain file to tell us
|
|
|
|
# if a value was set by the user at initial configure time. On a 2nd run there will
|
|
|
|
# always be a value in the cache, but at that point we've already set it to whatever it needs
|
|
|
|
# to be.
|
|
|
|
# 2) If a toolchain file is not used, we rely on the value of the CMake internal
|
|
|
|
# CMAKE_BUILD_TYPE_INIT variable.
|
|
|
|
# This won't work reliably on Windows where CMAKE_BUILD_TYPE_INIT is non-empty.
|
|
|
|
#
|
|
|
|
# Both cases won't handle an empty "" config set by the user, but we claim that's an
|
|
|
|
# unsupported config when building Qt.
|
|
|
|
#
|
|
|
|
# Allow an opt out when QT_NO_FORCE_SET_CMAKE_BUILD_TYPE is set.
|
|
|
|
# Finally, don't set the variable if a multi-config generator is used. This can happen
|
|
|
|
# when qtbase is built with a single config, but a test is built with a multi-config generator.
|
|
|
|
function(qt_internal_force_set_cmake_build_type_conditionally value)
|
|
|
|
# STREQUAL check needs to be expanded variables because an undefined var is not equal to an
|
|
|
|
# empty defined var.
|
|
|
|
if("${CMAKE_BUILD_TYPE}" STREQUAL "${CMAKE_BUILD_TYPE_INIT}"
|
|
|
|
AND NOT __qt_toolchain_cmake_build_type_before_project_call
|
|
|
|
AND NOT QT_NO_FORCE_SET_CMAKE_BUILD_TYPE
|
|
|
|
AND NOT __qt_internal_extras_is_multi_config)
|
|
|
|
set(CMAKE_BUILD_TYPE "${value}" CACHE STRING "Choose the type of build." FORCE)
|
|
|
|
endif()
|
|
|
|
endfunction()
|
|
|
|
|
2019-08-13 13:51:56 +00:00
|
|
|
# Extra set of exported variables
|
|
|
|
@QT_EXTRA_BUILD_INTERNALS_VARS@
|