qt5base-lts/cmake/QtBuild.cmake

491 lines
20 KiB
CMake
Raw Normal View History

include(CMakePackageConfigHelpers)
include(QtSeparateDebugInfo)
function(qt_configure_process_path name default docstring)
# Values are computed once for qtbase, and then exported and reused for other projects.
if(NOT PROJECT_NAME STREQUAL "QtBase")
return()
endif()
# No value provided, set the default.
if(NOT DEFINED "${name}")
set("${name}" "${default}" CACHE STRING "${docstring}")
else()
get_filename_component(given_path_as_abs "${${name}}" ABSOLUTE BASE_DIR
"${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
file(RELATIVE_PATH rel_path "${CMAKE_INSTALL_PREFIX}"
"${given_path_as_abs}")
# If absolute path given, check that it's inside the prefix (error out if not).
# TODO: Figure out if we need to support paths that are outside the prefix.
#
# If relative path given, it's relative to the install prefix (rather than the binary dir,
# which is what qmake does for some reason).
# In both cases, store the value as a relative path.
if("${rel_path}" STREQUAL "")
# file(RELATIVE_PATH) returns an empty string if the given absolute paths are equal
set(rel_path ".")
elseif(rel_path MATCHES "^\.\./")
# INSTALL_SYSCONFDIR is allowed to be outside the prefix.
if(NOT name STREQUAL "INSTALL_SYSCONFDIR")
message(FATAL_ERROR
"Path component '${name}' is outside computed install prefix: ${rel_path} ")
return()
endif()
set("${name}" "${${name}}" CACHE STRING "${docstring}" FORCE)
else()
set("${name}" "${rel_path}" CACHE STRING "${docstring}" FORCE)
endif()
endif()
endfunction()
# Install locations:
qt_configure_process_path(INSTALL_BINDIR "bin" "Executables [PREFIX/bin]")
qt_configure_process_path(INSTALL_INCLUDEDIR "include" "Header files [PREFIX/include]")
qt_configure_process_path(INSTALL_LIBDIR "lib" "Libraries [PREFIX/lib]")
qt_configure_process_path(INSTALL_MKSPECSDIR "mkspecs" "Mkspecs files [PREFIX/mkspecs]")
qt_configure_process_path(INSTALL_ARCHDATADIR "." "Arch-dependent data [PREFIX]")
qt_configure_process_path(INSTALL_PLUGINSDIR
"${INSTALL_ARCHDATADIR}/plugins"
"Plugins [ARCHDATADIR/plugins]")
if(NOT INSTALL_MKSPECSDIR MATCHES "(^|/)mkspecs")
message(FATAL_ERROR "INSTALL_MKSPECSDIR must end with '/mkspecs'")
endif()
# Given CMAKE_CONFIG and ALL_CMAKE_CONFIGS, determines if a directory suffix needs to be appended
# to each destination, and sets the computed install target destination arguments in OUT_VAR.
# Defaults used for each of the destination types, and can be configured per destination type.
function(qt_get_install_target_default_args)
qt_parse_all_arguments(arg "qt_get_install_target_default_args"
"" "OUT_VAR;CMAKE_CONFIG;RUNTIME;LIBRARY;ARCHIVE;INCLUDES;BUNDLE"
"ALL_CMAKE_CONFIGS" ${ARGN})
if(NOT arg_CMAKE_CONFIG)
message(FATAL_ERROR "No value given for CMAKE_CONFIG.")
endif()
if(NOT arg_ALL_CMAKE_CONFIGS)
message(FATAL_ERROR "No value given for ALL_CMAKE_CONFIGS.")
endif()
list(LENGTH arg_ALL_CMAKE_CONFIGS all_configs_count)
list(GET arg_ALL_CMAKE_CONFIGS 0 first_config)
set(suffix "")
if(all_configs_count GREATER 1 AND NOT arg_CMAKE_CONFIG STREQUAL first_config)
set(suffix "/${arg_CMAKE_CONFIG}")
endif()
set(runtime "${INSTALL_BINDIR}")
if(arg_RUNTIME)
set(runtime "${arg_RUNTIME}")
endif()
set(library "${INSTALL_LIBDIR}")
if(arg_LIBRARY)
set(library "${arg_LIBRARY}")
endif()
set(archive "${INSTALL_LIBDIR}")
if(arg_ARCHIVE)
set(archive "${arg_ARCHIVE}")
endif()
set(includes "${INSTALL_INCLUDEDIR}")
if(arg_INCLUDES)
set(includes "${arg_INCLUDES}")
endif()
set(bundle "${INSTALL_BINDIR}")
if(arg_BUNDLE)
set(bundle "${arg_BUNDLE}")
endif()
set(args
RUNTIME DESTINATION "${runtime}${suffix}"
LIBRARY DESTINATION "${library}${suffix}"
ARCHIVE DESTINATION "${archive}${suffix}" COMPONENT Devel
BUNDLE DESTINATION "${bundle}${suffix}"
INCLUDES DESTINATION "${includes}${suffix}")
set(${arg_OUT_VAR} "${args}" PARENT_SCOPE)
endfunction()
if (WIN32)
set(_default_libexec "${INSTALL_ARCHDATADIR}/bin")
else()
set(_default_libexec "${INSTALL_ARCHDATADIR}/libexec")
endif()
qt_configure_process_path(
INSTALL_LIBEXECDIR
"${_default_libexec}"
"Helper programs [ARCHDATADIR/bin on Windows, ARCHDATADIR/libexec otherwise]")
qt_configure_process_path(INSTALL_QMLDIR
"${INSTALL_ARCHDATADIR}/qml"
"QML2 imports [ARCHDATADIR/qml]")
qt_configure_process_path(INSTALL_DATADIR "." "Arch-independent data [PREFIX]")
qt_configure_process_path(INSTALL_DOCDIR "${INSTALL_DATADIR}/doc" "Documentation [DATADIR/doc]")
qt_configure_process_path(INSTALL_TRANSLATIONSDIR "${INSTALL_DATADIR}/translations"
"Translations [DATADIR/translations]")
if(APPLE)
set(QT_DEFAULT_SYS_CONF_DIR "/Library/Preferences/Qt")
else()
set(QT_DEFAULT_SYS_CONF_DIR "etc/xdg")
endif()
qt_configure_process_path(INSTALL_SYSCONFDIR
"${QT_DEFAULT_SYS_CONF_DIR}"
"Settings used by Qt programs [PREFIX/etc/xdg]/[/Library/Preferences/Qt]")
qt_configure_process_path(INSTALL_EXAMPLESDIR "examples" "Examples [PREFIX/examples]")
qt_configure_process_path(INSTALL_TESTSDIR "tests" "Tests [PREFIX/tests]")
qt_configure_process_path(INSTALL_DESCRIPTIONSDIR
"${INSTALL_DATADIR}/modules"
"Module description files directory")
if(CMAKE_CROSSCOMPILING AND NOT "${CMAKE_STAGING_PREFIX}" STREQUAL "")
set(QT_STAGING_PREFIX "${CMAKE_STAGING_PREFIX}")
else()
set(QT_STAGING_PREFIX "${CMAKE_INSTALL_PREFIX}")
endif()
if(PROJECT_NAME STREQUAL "QtBase")
set(QT_COORD_TYPE double CACHE STRING "Type of qreal")
endif()
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
function(qt_internal_set_up_global_paths)
# Compute the values of QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR
# taking into account whether the current build is a prefix build or a non-prefix build,
# and whether it is a superbuild or non-superbuild.
# A third case is when another module or standalone tests are built against a super-built Qt.
# The layout for the third case is the same as for non-superbuilds.
#
# These values should be prepended to file paths in commands or properties,
# in order to correctly place generated Config files, generated Targets files,
# excutables / libraries, when copying / installing files, etc.
#
# The build dir variables will always be absolute paths.
# The QT_INSTALL_DIR variable will have a relative path in a prefix build,
# which means that it can be empty, so use qt_join_path to prevent accidental absolute paths.
if(QT_SUPERBUILD)
# In this case, we always copy all the build products in qtbase/{bin,lib,...}
if(QT_WILL_INSTALL)
set(QT_BUILD_DIR "${QtBase_BINARY_DIR}")
set(QT_INSTALL_DIR "")
else()
if("${CMAKE_STAGING_PREFIX}" STREQUAL "")
set(QT_BUILD_DIR "${QtBase_BINARY_DIR}")
set(QT_INSTALL_DIR "${QtBase_BINARY_DIR}")
else()
set(QT_BUILD_DIR "${CMAKE_STAGING_PREFIX}")
set(QT_INSTALL_DIR "${CMAKE_STAGING_PREFIX}")
endif()
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()
else()
if(QT_WILL_INSTALL)
# In the usual prefix build case, the build dir is the current module build dir,
# and the install dir is the prefix, so we don't set it.
set(QT_BUILD_DIR "${CMAKE_BINARY_DIR}")
set(QT_INSTALL_DIR "")
else()
# When doing a non-prefix build, both the build dir and install dir are the same,
# pointing to the qtbase build dir.
set(QT_BUILD_DIR "${QT_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
set(QT_INSTALL_DIR "${QT_BUILD_DIR}")
endif()
endif()
set(__config_path_part "${INSTALL_LIBDIR}/cmake")
set(QT_CONFIG_BUILD_DIR "${QT_BUILD_DIR}/${__config_path_part}")
set(QT_CONFIG_INSTALL_DIR "${QT_INSTALL_DIR}")
if(QT_CONFIG_INSTALL_DIR)
string(APPEND QT_CONFIG_INSTALL_DIR "/")
endif()
string(APPEND QT_CONFIG_INSTALL_DIR ${__config_path_part})
set(QT_BUILD_DIR "${QT_BUILD_DIR}" PARENT_SCOPE)
set(QT_INSTALL_DIR "${QT_INSTALL_DIR}" PARENT_SCOPE)
set(QT_CONFIG_BUILD_DIR "${QT_CONFIG_BUILD_DIR}" PARENT_SCOPE)
set(QT_CONFIG_INSTALL_DIR "${QT_CONFIG_INSTALL_DIR}" PARENT_SCOPE)
endfunction()
qt_internal_set_up_global_paths()
qt_get_relocatable_install_prefix(QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX)
set(QT_CMAKE_DIR "${CMAKE_CURRENT_LIST_DIR}")
# Find the path to mkspecs/, depending on whether we are building as part of a standard qtbuild,
# or a module against an already installed version of qt.
if(NOT QT_MKSPECS_DIR)
if("${QT_BUILD_INTERNALS_PATH}" STREQUAL "")
get_filename_component(QT_MKSPECS_DIR "${CMAKE_CURRENT_LIST_DIR}/../mkspecs" ABSOLUTE)
else()
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
# We can rely on QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX being set by
# QtBuildInternalsExtra.cmake.
get_filename_component(
QT_MKSPECS_DIR
"${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_MKSPECSDIR}" ABSOLUTE)
endif()
set(QT_MKSPECS_DIR "${QT_MKSPECS_DIR}" CACHE INTERNAL "")
endif()
# the default RPATH to be used when installing, but only if it's not a system directory
list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/${INSTALL_LIBDIR}" isSystemDir)
if("${isSystemDir}" STREQUAL "-1")
set(_default_install_rpath "${CMAKE_INSTALL_PREFIX}/${INSTALL_LIBDIR}")
endif("${isSystemDir}" STREQUAL "-1")
CMake: Handle automatic rpath embedding correctly Instead of using CMAKE_INSTALL_RPATH to embed an absolute path to prefix/libdir into all targets, use the more sophisticated aproach that qmake does. For certain targets (modules, plugins, tools) use relative rpaths. Otherwise embed absolute paths (examples, regular binaries). Installed tests currently have no rpaths. On certain platforms rpaths are not used (Windows, Android, iOS / uikit). Frameworks, app bundles and shallow bundles should also be handled correctly. Additional rpaths can be provided via QT_EXTRA_RPATHS variable (similar to the -R option that configure takes). Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF or QT_DISABLE_RPATH=ON. Note that installed examples are not relocatable at the moment (due to always having an absolute path rpath), so this is a missing feature compared to qmake. This is due to missing information on where examples will be installed, so a relative rpath can not be computed. By default a Qt installation is relocatable, so there is no need to pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R . Relative rpaths will have the appropriate 'relative base' prefixed to them (e.g $ORIGIN on linux and @loader_path on darwin platforms). There is currently no support for other platforms that might have a different 'relative base' than the ones mentioned above. Any extra rpaths are saved to BuildInternalsExtra which are re-used when building other repositories. configurejson2cmake modified to include correct conditions for the rpath feature. It's very likely that we will need a new qt_add_internal_app() function for gui apps that are to be installed to prefix/bin. For example for Assistant from qttools. Currently such apps use qt_add_executable(). The distinction is necessary to make sure that relative rpaths are embedded into apps, but not executables (which tests are part of). Amends e835a6853b9c0fb7af32798ed8965de3adf0e15b Task-number: QTBUG-83497 Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-04-15 16:48:26 +00:00
# The default rpath settings for installed targets is empty.
# The rpaths will instead be computed for each target separately using qt_apply_rpaths().
# Additional rpaths can be passed via QT_EXTRA_RPATHS.
# By default this will include $ORIGIN / @loader_path, so the installation is relocatable.
# Bottom line: No need to pass anything to CMAKE_INSTALL_RPATH.
set(CMAKE_INSTALL_RPATH "" CACHE STRING "RPATH for installed binaries")
# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
#
# TODO: Do we really want to use this option for official packages? Perhaps make it configurable
# or remove it? This causes final installed binaries to contain an absolute path RPATH pointing
# to ${CMAKE_INSTALL_PREFIX}/lib, which on the CI would be something like
# /Users/qt/work/install/lib.
# It doesn't seem necessary to me, given that qt_apply_rpaths already applies $ORIGIN-style
# relocatable paths, but maybe i'm missing something, because the original commit that added the
# option mentions it's needed in some cross-compilation scenario for program binaries that
# link against QtCore.
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
function(qt_setup_tool_path_command)
if(NOT WIN32)
return()
endif()
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
set(bindir "${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_BINDIR}")
file(TO_NATIVE_PATH "${bindir}" bindir)
list(APPEND command COMMAND)
list(APPEND command set \"PATH=${bindir}$<SEMICOLON>%PATH%\")
set(QT_TOOL_PATH_SETUP_COMMAND "${command}" CACHE INTERNAL "internal command prefix for tool invocations" FORCE)
endfunction()
qt_setup_tool_path_command()
# Platform define path, etc.
if(WIN32)
set(QT_DEFAULT_PLATFORM_DEFINITIONS WIN32 _ENABLE_EXTENDED_ALIGNED_STORAGE)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
list(APPEND QT_DEFAULT_PLATFORM_DEFINITIONS WIN64 _WIN64)
endif()
if(MSVC)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "arm64")
set(QT_DEFAULT_MKSPEC win32-arm64-msvc)
else()
set(QT_DEFAULT_MKSPEC win32-msvc)
endif()
elseif(CLANG AND MINGW)
set(QT_DEFAULT_MKSPEC win32-clang-g++)
elseif(MINGW)
set(QT_DEFAULT_MKSPEC win32-g++)
endif()
if (MINGW)
list(APPEND QT_DEFAULT_PLATFORM_DEFINITIONS _WIN32_WINNT=0x0601 MINGW_HAS_SECURE_API=1)
endif()
elseif(LINUX)
if(GCC)
set(QT_DEFAULT_MKSPEC linux-g++)
elseif(CLANG)
set(QT_DEFAULT_MKSPEC linux-clang)
elseif(ICC)
set(QT_DEFAULT_MKSPEC linux-icc-64)
endif()
elseif(ANDROID)
if(GCC)
set(QT_DEFAULT_MKSPEC android-g++)
elseif(CLANG)
set(QT_DEFAULT_MKSPEC android-clang)
endif()
elseif(IOS)
set(QT_DEFAULT_MKSPEC macx-ios-clang)
elseif(APPLE)
set(QT_DEFAULT_MKSPEC macx-clang)
elseif(EMSCRIPTEN)
set(QT_DEFAULT_MKSPEC wasm-emscripten)
elseif(QNX)
# Certain POSIX defines are not set if we don't compile with -std=gnuXX
set(QT_ENABLE_CXX_EXTENSIONS ON)
list(APPEND QT_DEFAULT_PLATFORM_DEFINITIONS _FORTIFY_SOURCE=2 _REENTRANT)
set(compiler_aarch64le aarch64le)
set(compiler_armle-v7 armv7le)
set(compiler_x86-64 x86_64)
set(compiler_x86 x86)
foreach(arch aarch64le armle-v7 x86-64 x86)
if (CMAKE_CXX_COMPILER_TARGET MATCHES "${compiler_${arch}}$")
set(QT_DEFAULT_MKSPEC qnx-${arch}-qcc)
endif()
endforeach()
endif()
if(NOT QT_QMAKE_TARGET_MKSPEC)
set(QT_QMAKE_TARGET_MKSPEC "${QT_DEFAULT_MKSPEC}" CACHE STRING "QMake target mkspec")
endif()
if(CMAKE_CROSSCOMPILING)
set(QT_QMAKE_HOST_MKSPEC "${QT${PROJECT_VERSION_MAJOR}_HOST_INFO_QMAKE_MKSPEC}")
else()
set(QT_QMAKE_HOST_MKSPEC "${QT_QMAKE_TARGET_MKSPEC}")
endif()
# Platform definition dir provided by user on command line.
# Derive the absolute one relative to the current source dir.
if(QT_PLATFORM_DEFINITION_DIR)
set(QT_DEFAULT_PLATFORM_DEFINITION_DIR "${QT_PLATFORM_DEFINITION_DIR}")
get_filename_component(
QT_DEFAULT_PLATFORM_DEFINITION_DIR_ABSOLUTE
"${QT_PLATFORM_DEFINITION_DIR}"
ABSOLUTE)
elseif(QT_QMAKE_TARGET_MKSPEC)
# Used by consumers of prefix builds via INSTALL_INTERFACE (relative path).
set(QT_DEFAULT_PLATFORM_DEFINITION_DIR "${INSTALL_MKSPECSDIR}/${QT_QMAKE_TARGET_MKSPEC}")
# Used by qtbase itself and consumers of non-prefix builds via BUILD_INTERFACE (absolute path).
set(QT_DEFAULT_PLATFORM_DEFINITION_DIR_ABSOLUTE "${QT_MKSPECS_DIR}/${QT_QMAKE_TARGET_MKSPEC}")
endif()
if(NOT DEFINED QT_DEFAULT_PLATFORM_DEFINITIONS)
set(QT_DEFAULT_PLATFORM_DEFINITIONS "")
endif()
set(QT_PLATFORM_DEFINITIONS ${QT_DEFAULT_PLATFORM_DEFINITIONS}
CACHE STRING "Qt platform specific pre-processor defines")
set(QT_PLATFORM_DEFINITION_DIR "${QT_DEFAULT_PLATFORM_DEFINITION_DIR}"
CACHE PATH "Path to directory that contains qplatformdefs.h")
set(QT_PLATFORM_DEFINITION_DIR_ABSOLUTE "${QT_DEFAULT_PLATFORM_DEFINITION_DIR_ABSOLUTE}"
CACHE INTERNAL "Path to directory that contains qplatformdefs.h")
set(QT_NAMESPACE "" CACHE STRING "Qt Namespace")
if(QT_NAMESPACE STREQUAL "")
set(QT_HAS_NAMESPACE OFF)
else()
set(QT_HAS_NAMESPACE ON)
endif()
include(QtGlobalStateHelpers)
# Reset global state:
qt_internal_clear_qt_repo_known_modules()
qt_internal_clear_qt_repo_known_plugin_types()
qt_internal_set_qt_known_plugins("")
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_KNOWN_MODULES_WITH_TOOLS "" CACHE INTERNAL "Known Qt modules with tools" FORCE)
# Reset syncqt cache variable, to make sure it gets recomputed on reconfiguration, otherwise
# it might not get installed.
unset(QT_SYNCQT CACHE)
# For adjusting variables when running tests, we need to know what
# the correct variable is for separating entries in PATH-alike
# variables.
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
set(QT_PATH_SEPARATOR "\\;")
else()
set(QT_PATH_SEPARATOR ":")
endif()
# This is used to hold extra cmake code that should be put into QtBuildInternalsExtra.cmake file
# at the QtPostProcess stage.
set(QT_BUILD_INTERNALS_EXTRA_CMAKE_CODE "")
# Save the value of the current first project source dir.
# This will be /path/to/qtbase for qtbase both in a super-build and a non super-build.
# This will be /path/to/qtbase/tests when building standalone tests.
set(QT_TOP_LEVEL_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
# Prevent warnings about object files without any symbols. This is a common
# thing in Qt as we tend to build files unconditionally, and then use ifdefs
# to compile out parts that are not relevant.
if(CMAKE_HOST_APPLE AND APPLE)
foreach(lang ASM C CXX)
# We have to tell 'ar' to not run ranlib by itself, by passing the 'S' option
set(CMAKE_${lang}_ARCHIVE_CREATE "<CMAKE_AR> qcS <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_${lang}_ARCHIVE_APPEND "<CMAKE_AR> qS <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_${lang}_ARCHIVE_FINISH "<CMAKE_RANLIB> -no_warning_for_no_symbols <TARGET>")
endforeach()
endif()
# Functions and macros:
# Needed for qt_internal_add_link_flags_no_undefined.
include(CheckCXXSourceCompiles)
set(__default_private_args "SOURCES;LIBRARIES;INCLUDE_DIRECTORIES;DEFINES;DBUS_ADAPTOR_BASENAME;DBUS_ADAPTOR_FLAGS;DBUS_ADAPTOR_SOURCES;DBUS_INTERFACE_BASENAME;DBUS_INTERFACE_FLAGS;DBUS_INTERFACE_SOURCES;FEATURE_DEPENDENCIES;COMPILE_OPTIONS;LINK_OPTIONS;MOC_OPTIONS;DISABLE_AUTOGEN_TOOLS;ENABLE_AUTOGEN_TOOLS;PLUGIN_TYPES")
set(__default_public_args "PUBLIC_LIBRARIES;PUBLIC_INCLUDE_DIRECTORIES;PUBLIC_DEFINES;PUBLIC_COMPILE_OPTIONS;PUBLIC_LINK_OPTIONS")
set(__default_private_module_args "PRIVATE_MODULE_INTERFACE")
set(__default_target_info_args TARGET_VERSION TARGET_PRODUCT TARGET_DESCRIPTION TARGET_COMPANY
TARGET_COPYRIGHT)
# Collection of qt_add_plugin arguments so they can be shared across different
# plugin type wrappers
set(__qt_add_plugin_optional_args
"STATIC;EXCEPTIONS;ALLOW_UNDEFINED_SYMBOLS"
)
set(__qt_add_plugin_single_args
"TYPE;CLASS_NAME;OUTPUT_DIRECTORY;INSTALL_DIRECTORY;ARCHIVE_INSTALL_DIRECTORY;QML_TARGET_PATH;OUTPUT_NAME"
${__default_target_info_args}
)
set(__qt_add_plugin_multi_args
"${__default_private_args};${__default_public_args};DEFAULT_IF"
)
# Collection of arguments so they can be shared across qt_internal_add_executable
# and qt_internal_add_test_helper.
set(__qt_internal_add_executable_optional_args
"GUI;BOOTSTRAP;NO_QT;NO_INSTALL;EXCEPTIONS;DELAY_RC;DELAY_TARGET_INFO;QT_APP"
)
set(__qt_internal_add_executable_single_args
"OUTPUT_DIRECTORY;INSTALL_DIRECTORY;VERSION"
${__default_target_info_args}
)
set(__qt_internal_add_executable_multi_args
"EXE_FLAGS;${__default_private_args};${__default_public_args}"
)
option(QT_CMAKE_DEBUG_EXTEND_TARGET "Debug extend_target calls in Qt's build system" OFF)
include(Qt3rdPartyLibraryHelpers)
include(QtAppHelpers)
include(QtAutogenHelpers)
include(QtCMakeHelpers)
include(QtCompatibilityHelpers)
include(QtDeferredDependenciesHelpers)
include(QtDbusHelpers)
include(QtDocsHelpers)
include(QtExecutableHelpers)
include(QtFindPackageHelpers)
include(QtFlagHandlingHelpers)
include(QtFrameworkHelpers)
include(QtInstallHelpers)
include(QtLalrHelpers)
include(QtModuleHelpers)
include(QtNoLinkTargetHelpers)
include(QtPluginHelpers)
include(QtPrecompiledHeadersHelpers)
include(QtPriHelpers)
include(QtPrlHelpers)
include(QtQmakeHelpers)
include(QtResourceHelpers)
include(QtRpathHelpers)
include(QtSanitizerHelpers)
include(QtScopeFinalizerHelpers)
include(QtSimdHelpers)
include(QtSyncQtHelpers)
include(QtTargetHelpers)
include(QtTestHelpers)
include(QtToolHelpers)
include(QtHeadersClean)
include(QtJavaHelpers)
if(ANDROID)
include(QtAndroidHelpers)
endif()
# This sets up the poor man's scope finalizer mechanism.
# For newer CMake versions, we use cmake_language(DEFER CALL) instead.
if(CMAKE_VERSION VERSION_LESS "3.19.0")
variable_watch(CMAKE_CURRENT_LIST_DIR qt_watch_current_list_dir)
endif()