2019-02-19 15:38:11 +00:00
|
|
|
## Set a default build type if none was specified
|
2019-06-06 12:29:31 +00:00
|
|
|
|
|
|
|
|
# Set the QT_IS_BUILDING_QT variable so we can verify whether we are building
|
|
|
|
|
# Qt from source
|
|
|
|
|
set(QT_BUILDING_QT TRUE CACHE
|
|
|
|
|
TYPE STRING "When this is present and set to true, it signals that we are building Qt from source.")
|
|
|
|
|
|
2019-02-19 15:38:11 +00:00
|
|
|
set(_default_build_type "Release")
|
|
|
|
|
if(EXISTS "${CMAKE_SOURCE_DIR}/.git")
|
|
|
|
|
set(_default_build_type "Debug")
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-12-06 14:12:17 +00:00
|
|
|
# Reset content of extra build internal vars for each inclusion of QtSetup.
|
|
|
|
|
unset(QT_EXTRA_BUILD_INTERNALS_VARS)
|
|
|
|
|
|
2020-02-26 12:23:05 +00:00
|
|
|
# Save the global property in a variable to make it available to feature conditions.
|
|
|
|
|
get_property(QT_GENERATOR_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
|
|
|
|
|
|
2019-02-19 15:38:11 +00:00
|
|
|
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
|
|
|
|
|
message(STATUS "Setting build type to '${_default_build_type}' as none was specified.")
|
|
|
|
|
set(CMAKE_BUILD_TYPE "${_default_build_type}" CACHE STRING "Choose the type of build." FORCE)
|
2019-12-06 14:12:17 +00:00
|
|
|
set_property(CACHE CMAKE_BUILD_TYPE
|
|
|
|
|
PROPERTY STRINGS
|
|
|
|
|
"Debug" "Release" "MinSizeRel" "RelWithDebInfo") # Set the possible values for cmake-gui.
|
|
|
|
|
elseif(CMAKE_CONFIGURATION_TYPES)
|
|
|
|
|
message(STATUS "Building for multiple configurations: ${CMAKE_CONFIGURATION_TYPES}.")
|
|
|
|
|
message(STATUS "Main configuration is: ${QT_MULTI_CONFIG_FIRST_CONFIG}.")
|
|
|
|
|
if(CMAKE_NINJA_MULTI_DEFAULT_BUILD_TYPE)
|
|
|
|
|
message(STATUS
|
|
|
|
|
"Default build configuration set to '${CMAKE_NINJA_MULTI_DEFAULT_BUILD_TYPE}'.")
|
|
|
|
|
endif()
|
2019-02-19 15:38:11 +00:00
|
|
|
endif()
|
|
|
|
|
|
2019-03-26 18:37:01 +00:00
|
|
|
# Appends a 'debug postfix' to library targets (not executables)
|
2019-06-14 10:59:07 +00:00
|
|
|
# e.g. lib/libQt6DBus_debug.5.12.0.dylib
|
2019-03-26 18:37:01 +00:00
|
|
|
if(WIN32)
|
|
|
|
|
set(CMAKE_DEBUG_POSTFIX "d")
|
|
|
|
|
elseif(APPLE)
|
|
|
|
|
set(CMAKE_DEBUG_POSTFIX "_debug")
|
2020-03-02 13:17:24 +00:00
|
|
|
set(CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG "_debug")
|
2019-03-26 18:37:01 +00:00
|
|
|
endif()
|
|
|
|
|
|
2018-10-24 13:20:27 +00:00
|
|
|
## Position independent code:
|
|
|
|
|
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
|
|
|
|
|
|
|
|
|
|
# Do not relink dependent libraries when no header has changed:
|
|
|
|
|
set(CMAKE_LINK_DEPENDS_NO_SHARED ON)
|
|
|
|
|
|
|
|
|
|
# Default to hidden visibility for symbols:
|
|
|
|
|
set(CMAKE_C_VISIBILITY_PRESET hidden)
|
|
|
|
|
set(CMAKE_CXX_VISIBILITY_PRESET hidden)
|
|
|
|
|
set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
|
|
|
|
|
|
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
|
|
|
# Detect non-prefix builds: either when the qtbase install prefix is set to the binary dir
|
|
|
|
|
# or when a developer build is explicitly enabled and no install prefix is specified.
|
2019-07-22 15:30:24 +00:00
|
|
|
# This detection only happens when building qtbase, and later is propagated via the generated
|
|
|
|
|
# QtBuildInternalsExtra.cmake file.
|
2019-11-01 10:48:23 +00:00
|
|
|
if (PROJECT_NAME STREQUAL "QtBase" AND NOT QT_BUILD_STANDALONE_TESTS)
|
2020-04-16 18:06:53 +00:00
|
|
|
if((CMAKE_INSTALL_PREFIX STREQUAL QtBase_BINARY_DIR) OR
|
2019-07-22 15:30:24 +00:00
|
|
|
(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND FEATURE_developer_build))
|
|
|
|
|
|
|
|
|
|
set(__qt_will_install_value OFF)
|
|
|
|
|
# Handle non-prefix builds by setting the CMake install prefix to point to qtbase's build
|
|
|
|
|
# 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
|
|
|
# While building another repo (like qtsvg) the CMAKE_PREFIX_PATH
|
|
|
|
|
# should be set on the command line to point to the qtbase build dir.
|
2020-04-16 18:06:53 +00:00
|
|
|
set(CMAKE_INSTALL_PREFIX ${QtBase_BINARY_DIR} CACHE PATH
|
Implement developer / non-prefix builds
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
|
|
|
"Install path prefix, prepended onto install directories." FORCE)
|
|
|
|
|
else()
|
2019-07-22 15:30:24 +00:00
|
|
|
set(__qt_will_install_value ON)
|
Implement developer / non-prefix builds
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
|
|
|
endif()
|
2019-07-22 15:30:24 +00:00
|
|
|
set(QT_WILL_INSTALL ${__qt_will_install_value} CACHE BOOL
|
|
|
|
|
"Boolean indicating if doing a Qt prefix build (vs non-prefix build)." FORCE)
|
|
|
|
|
unset(__qt_will_install_value)
|
Implement developer / non-prefix builds
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
|
|
|
endif()
|
|
|
|
|
|
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
|
|
|
# Specify the QT_SOURCE_TREE only when building qtbase. Needed by some tests when the tests are
|
|
|
|
|
# built as part of the project, and not standalone. For standalone tests, the value is set in
|
|
|
|
|
# QtBuildInternalsExtra.cmake.
|
|
|
|
|
if(PROJECT_NAME STREQUAL "QtBase")
|
|
|
|
|
set(QT_SOURCE_TREE "${QtBase_SOURCE_DIR}" CACHE PATH
|
|
|
|
|
"A path to the source tree of the previously configured QtBase project." FORCE)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-06-25 10:09:10 +00:00
|
|
|
if(FEATURE_developer_build)
|
|
|
|
|
if(DEFINED QT_CMAKE_EXPORT_COMPILE_COMMANDS)
|
|
|
|
|
set(CMAKE_EXPORT_COMPILE_COMMANDS ${QT_CMAKE_EXPORT_COMPILE_COMMANDS})
|
|
|
|
|
else()
|
|
|
|
|
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
|
|
|
|
|
endif()
|
|
|
|
|
set(QT_BUILD_TESTING ON)
|
2019-10-28 14:35:47 +00:00
|
|
|
set(__build_benchmarks ON)
|
|
|
|
|
|
2019-04-08 15:23:57 +00:00
|
|
|
# Tests are not built by default with qmake for iOS and friends, and thus the overall build
|
|
|
|
|
# tends to fail. Disable them by default when targeting uikit.
|
2020-03-16 12:36:47 +00:00
|
|
|
if(UIKIT OR ANDROID)
|
2019-04-08 15:23:57 +00:00
|
|
|
set(QT_BUILD_TESTING OFF)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-10-28 14:35:47 +00:00
|
|
|
# Disable benchmarks for single configuration generators which do not build
|
|
|
|
|
# with release configuration.
|
|
|
|
|
if (CMAKE_BUILD_TYPE AND NOT CMAKE_BUILD_TYPE STREQUAL Release)
|
|
|
|
|
set(__build_benchmarks OFF)
|
|
|
|
|
endif()
|
2019-07-22 15:30:24 +00:00
|
|
|
else()
|
|
|
|
|
set(QT_BUILD_TESTING OFF)
|
2019-10-28 14:35:47 +00:00
|
|
|
set(__build_benchmarks OFF)
|
2019-06-25 10:09:10 +00:00
|
|
|
endif()
|
|
|
|
|
|
2019-06-05 12:49:09 +00:00
|
|
|
## Set up testing
|
|
|
|
|
option(BUILD_TESTING "Build the testing tree." ${QT_BUILD_TESTING})
|
2019-11-01 10:48:23 +00:00
|
|
|
if(QT_BUILD_STANDALONE_TESTS)
|
|
|
|
|
set(QT_BUILD_TESTING ON)
|
|
|
|
|
|
|
|
|
|
# BuildInternals might have set it to OFF on initial configuration. So force it to ON when
|
|
|
|
|
# building standalone tests.
|
|
|
|
|
set(BUILD_TESTING ON CACHE BOOL "Build the testing tree." FORCE)
|
2019-11-13 09:20:09 +00:00
|
|
|
|
|
|
|
|
# Also force the tests to be built as part of the default build target.
|
|
|
|
|
set(QT_NO_MAKE_TESTS OFF CACHE BOOL
|
|
|
|
|
"Should examples be built as part of the default 'all' target." FORCE)
|
2019-11-01 10:48:23 +00:00
|
|
|
endif()
|
2019-11-04 13:43:39 +00:00
|
|
|
option(QT_NO_MAKE_TESTS "Should tests be built as part of the default 'all' target." OFF)
|
2019-11-01 10:48:23 +00:00
|
|
|
|
2020-03-26 16:42:48 +00:00
|
|
|
# When cross-building, we don't build tools by default. Sometimes this also covers Qt apps as well.
|
|
|
|
|
# Like in qttools/assistant/assistant.pro, load(qt_app), which is guarded by a qtNomakeTools() call.
|
|
|
|
|
|
|
|
|
|
option(QT_NO_MAKE_TOOLS "Should tools be built as part of the default 'all' target."
|
|
|
|
|
"${CMAKE_CROSSCOMPILING}")
|
|
|
|
|
|
2018-10-24 13:20:27 +00:00
|
|
|
include(CTest)
|
|
|
|
|
enable_testing()
|
|
|
|
|
|
2019-09-06 09:52:47 +00:00
|
|
|
# Set up building of examples.
|
2019-04-08 15:23:57 +00:00
|
|
|
set(QT_BUILD_EXAMPLES ON)
|
|
|
|
|
# Examples are not built by default with qmake for iOS and friends, and thus the overall build
|
|
|
|
|
# tends to fail. Disable them by default when targeting uikit.
|
2020-03-16 12:36:47 +00:00
|
|
|
if(UIKIT OR ANDROID)
|
2019-04-08 15:23:57 +00:00
|
|
|
set(QT_BUILD_EXAMPLES OFF)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(BUILD_EXAMPLES "Build Qt examples" ${QT_BUILD_EXAMPLES})
|
2019-11-04 13:43:39 +00:00
|
|
|
option(QT_NO_MAKE_EXAMPLES "Should examples be built as part of the default 'all' target." OFF)
|
2019-09-06 09:52:47 +00:00
|
|
|
|
2019-10-28 14:35:47 +00:00
|
|
|
# Build Benchmarks
|
|
|
|
|
option(QT_BUILD_BENCHMARKS "Build Qt Benchmarks" ${__build_benchmarks})
|
|
|
|
|
|
2019-06-06 08:31:55 +00:00
|
|
|
## Android platform settings
|
|
|
|
|
if(ANDROID)
|
|
|
|
|
include(QtPlatformAndroid)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-11-13 13:03:20 +00:00
|
|
|
## qt_add_module and co.:
|
2018-10-24 13:20:27 +00:00
|
|
|
include(QtBuild)
|
|
|
|
|
|
|
|
|
|
## Qt Feature support:
|
2020-03-02 17:06:46 +00:00
|
|
|
include(QtBuildInformation)
|
2018-10-24 13:20:27 +00:00
|
|
|
include(QtFeature)
|
|
|
|
|
|
|
|
|
|
## Compiler optimization flags:
|
|
|
|
|
include(QtCompilerOptimization)
|
|
|
|
|
|
2019-02-19 16:37:30 +00:00
|
|
|
## Compiler flags:
|
|
|
|
|
include(QtCompilerFlags)
|
|
|
|
|
|
2019-06-25 10:09:10 +00:00
|
|
|
## Set up non-prefix build:
|
|
|
|
|
qt_set_up_nonprefix_build()
|
Implement developer / non-prefix builds
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
|
|
|
|
2019-10-17 08:14:09 +00:00
|
|
|
qt_set_language_standards()
|
|
|
|
|
|
2018-10-24 13:20:27 +00:00
|
|
|
## Find host tools (if non native):
|
Export tool config and target files for each relevant module
CMake will now generate config and target files for each module that
provides tools. As a result, namespaced global targets such as
Qt5::moc or Qt5::rcc can be made available.
Third party projects that require just these tools, and not the Qt
modules themselves, should specify CMAKE_PREFIX_PATH pointing to the
installed Qt location, and call find_package(Qt5CoreTools),
find_package(Qt5GuiTools), etc.
It is also possible to call
find_package(Qt5Tools REQUIRED Core Widgets) where the last option
is a list of modules whose tools should be imported.
Note that all the tools are in the Qt5::
namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools::
namespace.
This commit also changes the behavior regarding when to build tools
while building Qt itself.
When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when
-DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will
always be searched for and not built.
In this case the user has to specify the CMake variable QT_HOST_PATH
pointing to an installed host Qt location.
When not cross compiling, tools added by add_qt_tool are built from
source.
When building leaf modules (like qtsvg) that require some tool that was
built in qtbase (like moc), the module project should contain a
find_package(Qt5ToolsCore) call and specify an appropriate
CMAKE_PREFIX_PATH so that the tool package is found.
Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH,
the ensure syncqt code was changed to make it work properly with
both qtbase and qtsvg.
Here's a list of tools and their module associations:
qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools
qvkgen -> GuiTools
uic -> WidgetTools
dbus related tools -> DBusTools
Task-number: QTBUG-74134
Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-10 17:21:22 +00:00
|
|
|
set(QT_HOST_PATH "" CACHE PATH "Installed Qt host directory path, used for cross compiling.")
|
2018-10-24 13:20:27 +00:00
|
|
|
|
Export tool config and target files for each relevant module
CMake will now generate config and target files for each module that
provides tools. As a result, namespaced global targets such as
Qt5::moc or Qt5::rcc can be made available.
Third party projects that require just these tools, and not the Qt
modules themselves, should specify CMAKE_PREFIX_PATH pointing to the
installed Qt location, and call find_package(Qt5CoreTools),
find_package(Qt5GuiTools), etc.
It is also possible to call
find_package(Qt5Tools REQUIRED Core Widgets) where the last option
is a list of modules whose tools should be imported.
Note that all the tools are in the Qt5::
namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools::
namespace.
This commit also changes the behavior regarding when to build tools
while building Qt itself.
When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when
-DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will
always be searched for and not built.
In this case the user has to specify the CMake variable QT_HOST_PATH
pointing to an installed host Qt location.
When not cross compiling, tools added by add_qt_tool are built from
source.
When building leaf modules (like qtsvg) that require some tool that was
built in qtbase (like moc), the module project should contain a
find_package(Qt5ToolsCore) call and specify an appropriate
CMAKE_PREFIX_PATH so that the tool package is found.
Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH,
the ensure syncqt code was changed to make it work properly with
both qtbase and qtsvg.
Here's a list of tools and their module associations:
qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools
qvkgen -> GuiTools
uic -> WidgetTools
dbus related tools -> DBusTools
Task-number: QTBUG-74134
Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-10 17:21:22 +00:00
|
|
|
if (CMAKE_CROSSCOMPILING AND NOT IS_DIRECTORY ${QT_HOST_PATH})
|
|
|
|
|
message(FATAL_ERROR "You need to set QT_HOST_PATH to cross compile Qt.")
|
2018-10-24 13:20:27 +00:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
## Enable support for sanitizers:
|
|
|
|
|
include(${CMAKE_CURRENT_LIST_DIR}/3rdparty/extra-cmake-modules/modules/ECMEnableSanitizers.cmake)
|
2019-02-12 11:21:30 +00:00
|
|
|
|
|
|
|
|
option(QT_USE_CCACHE "Enable the use of ccache")
|
|
|
|
|
if(QT_USE_CCACHE)
|
|
|
|
|
find_program(CCACHE_PROGRAM ccache)
|
|
|
|
|
set(CMAKE_C_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
|
|
|
|
|
set(CMAKE_CXX_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
|
|
|
|
|
set(CMAKE_OBJC_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
|
|
|
|
|
endif()
|
