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()
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo") # Set the possible values of build type for cmake-gui
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-03-26 18:37:01 +00:00
|
|
|
# Appends a 'debug postfix' to library targets (not executables)
|
|
|
|
|
# e.g. lib/libQt5DBus_debug.5.12.0.dylib
|
|
|
|
|
if(WIN32)
|
|
|
|
|
set(CMAKE_DEBUG_POSTFIX "d")
|
|
|
|
|
elseif(APPLE)
|
|
|
|
|
set(CMAKE_DEBUG_POSTFIX "_debug")
|
|
|
|
|
endif()
|
|
|
|
|
|
2018-10-24 13:20:27 +00:00
|
|
|
## Force C++ standard, do not fall back, do not use compiler extensions
|
|
|
|
|
set(CMAKE_CXX_STANDARD 14)
|
|
|
|
|
set(CMAKE_CXX_STANDARD_REQUIRED ON)
|
|
|
|
|
set(CMAKE_CXX_EXTENSIONS OFF)
|
|
|
|
|
|
|
|
|
|
## 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)
|
|
|
|
|
|
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
|
|
|
if(FEATURE_developer_build)
|
2019-05-26 14:55:15 +00:00
|
|
|
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()
|
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
|
|
|
set(QT_WILL_INSTALL OFF)
|
2019-06-05 12:49:09 +00:00
|
|
|
set(QT_BUILD_TESTING 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
|
|
|
# Handle non-prefix builds by setting the cmake install prefix to the project binary dir.
|
|
|
|
|
if(PROJECT_NAME STREQUAL "QtBase")
|
|
|
|
|
set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR} CACHE PATH
|
|
|
|
|
"Install path prefix, prepended onto install directories." FORCE)
|
|
|
|
|
else()
|
2019-05-15 12:22:20 +00:00
|
|
|
# No-op. While building another module, the CMAKE_INSTALL_PREFIX or CMAKE_PREFIX_PATH
|
|
|
|
|
# (either work) should be set on the command line to point to the qtbase build dir.
|
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()
|
|
|
|
|
else()
|
|
|
|
|
set(QT_WILL_INSTALL ON)
|
2019-06-05 12:49:09 +00:00
|
|
|
set(QT_BUILD_TESTING OFF)
|
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-06-05 12:49:09 +00:00
|
|
|
## Set up testing
|
|
|
|
|
option(BUILD_TESTING "Build the testing tree." ${QT_BUILD_TESTING})
|
2018-10-24 13:20:27 +00:00
|
|
|
include(CTest)
|
|
|
|
|
enable_testing()
|
|
|
|
|
|
|
|
|
|
## Define some constants to check for certain platforms, etc:
|
|
|
|
|
include(QtPlatformSupport)
|
|
|
|
|
|
2019-06-06 08:31:55 +00:00
|
|
|
## Android platform settings
|
|
|
|
|
if(ANDROID)
|
|
|
|
|
include(QtPlatformAndroid)
|
|
|
|
|
endif()
|
|
|
|
|
|
2018-10-24 13:20:27 +00:00
|
|
|
## add_qt_module and co.:
|
|
|
|
|
include(QtBuild)
|
|
|
|
|
|
|
|
|
|
## Qt Feature support:
|
|
|
|
|
include(QtFeature)
|
|
|
|
|
|
|
|
|
|
## Compiler optimization flags:
|
|
|
|
|
include(QtCompilerOptimization)
|
|
|
|
|
|
2019-02-19 16:37:30 +00:00
|
|
|
## Compiler flags:
|
|
|
|
|
include(QtCompilerFlags)
|
|
|
|
|
|
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
|
|
|
## Set up developer build:
|
|
|
|
|
qt_set_up_developer_build()
|
|
|
|
|
|
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()
|
