qt5base-lts/cmake/QtAppHelpers.cmake

138 lines
5.0 KiB
CMake
Raw Normal View History

# Copyright (C) 2022 The Qt Company Ltd.
# SPDX-License-Identifier: BSD-3-Clause
# This function creates a CMake target for a Qt internal app.
# Such projects had a load(qt_app) command.
function(qt_internal_add_app target)
cmake_parse_arguments(PARSE_ARGV 1 arg
"NO_INSTALL;INSTALL_VERSIONED_LINK;EXCEPTIONS"
"${__default_target_info_args};INSTALL_DIR"
"${__default_private_args};PUBLIC_LIBRARIES"
)
_qt_internal_validate_all_args_are_parsed(arg)
set(exceptions "")
if(arg_EXCEPTIONS)
set(exceptions EXCEPTIONS)
endif()
if(DEFINED arg_INSTALL_DIR)
set(forward_install_dir INSTALL_DIRECTORY ${arg_INSTALL_DIR})
else()
set(forward_install_dir "")
set(arg_INSTALL_DIR ${INSTALL_BINDIR})
endif()
set(output_directory "${QT_BUILD_DIR}/${arg_INSTALL_DIR}")
set(no_install "")
if(arg_NO_INSTALL)
set(no_install NO_INSTALL)
endif()
if(arg_PUBLIC_LIBRARIES)
message(WARNING
"qt_internal_add_app's PUBLIC_LIBRARIES option is deprecated, and will be removed in "
"a future Qt version. Use the LIBRARIES option instead.")
endif()
qt_internal_library_deprecation_level(deprecation_define)
qt_internal_add_executable("${target}"
QT_APP
DELAY_RC
DELAY_TARGET_INFO
OUTPUT_DIRECTORY "${output_directory}"
${exceptions}
${no_install}
${forward_install_dir}
SOURCES ${arg_SOURCES}
INCLUDE_DIRECTORIES
${arg_INCLUDE_DIRECTORIES}
DEFINES
${arg_DEFINES}
${deprecation_define}
LIBRARIES
${arg_LIBRARIES}
${arg_PUBLIC_LIBRARIES}
Qt::PlatformAppInternal
COMPILE_OPTIONS ${arg_COMPILE_OPTIONS}
LINK_OPTIONS ${arg_LINK_OPTIONS}
MOC_OPTIONS ${arg_MOC_OPTIONS}
ENABLE_AUTOGEN_TOOLS ${arg_ENABLE_AUTOGEN_TOOLS}
DISABLE_AUTOGEN_TOOLS ${arg_DISABLE_AUTOGEN_TOOLS}
TARGET_VERSION "${arg_TARGET_VERSION}"
TARGET_PRODUCT "${arg_TARGET_PRODUCT}"
TARGET_DESCRIPTION "${arg_TARGET_DESCRIPTION}"
TARGET_COMPANY "${arg_TARGET_COMPANY}"
TARGET_COPYRIGHT "${arg_TARGET_COPYRIGHT}"
)
qt_internal_add_target_aliases("${target}")
CMake: Don't use std=gnu++11 when building Qt internal targets The logic is a bit involved in qmake. The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies to qt modules, qt plugins, qml plugins, qt helper libs, winmain and qt_apps, qt_tools, but NOT tests (which is important because the tests on Windows MinGW fail to build without the GNU extensions). Then default_post.prf checks for the strict_c++ value and either uses the strict or non-strict C++ standard flags. default_post.prf is loaded for all qmake projects, not just the Qt internal ones. Now CMake doesn't provide a transitive based option to disable C++ GNU extensions with a mechanism similar to target_compile_features. It only provides the CXX_EXTENSIONS property and it's associated CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a directory scope, because that is too coarse grained. So we rely on setting the property via a function in every relevant qt_add_<target> function. Now the naming of the function is weird. We name the function as qt_internal_<...>, because it's not meant to be used by Qt users. We prepend an underscore to the name because we need to place it in Qt6CoreMacros, so that the function can be called by qt_add_qml_module which IS a public function. That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 + CMake we decided to make qt_add_qml_module() as public API. Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-04 09:29:00 +00:00
_qt_internal_apply_strict_cpp("${target}")
qt_internal_adjust_main_config_runtime_output_dir("${target}" "${output_directory}")
# To mimic the default behaviors of qt_app.prf, we by default enable GUI Windows applications,
# but don't enable macOS bundles.
# Bundles are enabled in a separate set_target_properties call if an Info.plist file
# is provided.
# Similarly, the Windows GUI flag is disabled in a separate call
# if CONFIG += console was encountered during conversion.
set_target_properties("${target}" PROPERTIES WIN32_EXECUTABLE TRUE)
Generate information about user-facing applications in build dir When packaging different Qt versions for Linux distributions (or any distribution with a common bin dir), Qt tools cannot be installed to /usr/bin, because the executable names of the different Qt versions clash. To solve this conflict, our recommendation is to install Qt's tools to /usr/lib/qt6/bin and to create versioned symlinks to user-facing tools in /usr/bin. User-facing tools are tools that are supposed to be started manually by the user. They are marked in Qt's build system. Distro package maintainers can now configure with -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_PUBLICBINDIR=/usr/bin and will find a file called user_facing_tool_links.txt in the build directory after the cmake run. Nothing will be installed to INSTALL_PUBLICBINDIR. Each line of user_facing_tool_links.txt consists of the installation path of a user-facing application followed by a space and the versioned link name in INSTALL_PUBLICBINDIR. Example content: /usr/lib/qt6/bin/qmake /usr/bin/qmake6 To actually create the versioned symlinks, the content of this file can be fed to ln like this: xargs ln -s < build-dir/user_facing_tool_links.txt Or the package maintainer may decide to do something completely different as suits their needs. This patch adds the USER_FACING argument to qt_internal_add_tool to mark tools as user-facing. In addition, every Qt created by qt_internal_add_app is treated as user-facing. The only tool this patch marks as user-facing in qtbase is qmake. Pick-to: 6.1 Fixes: QTBUG-89170 Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2021-02-11 13:01:58 +00:00
# Consider every app as user facing tool.
set_property(GLOBAL APPEND PROPERTY QT_USER_FACING_TOOL_TARGETS ${target})
# Install versioned link if requested.
if(NOT arg_NO_INSTALL AND arg_INSTALL_VERSIONED_LINK)
qt_internal_install_versioned_link(WORKING_DIRECTORY "${arg_INSTALL_DIR}"
TARGETS ${target})
endif()
qt_add_list_file_finalizer(qt_internal_finalize_app ${target})
endfunction()
function(qt_internal_get_title_case value out_var)
if(NOT value)
set(${out_var} "" PARENT_SCOPE)
return()
endif()
string(SUBSTRING "${value}" 0 1 first_char)
string(TOUPPER "${first_char}" first_char_upper)
string(SUBSTRING "${value}" 1 -1 rest_of_value)
set(title_value "${first_char_upper}${rest_of_value}")
set(${out_var} "${title_value}" PARENT_SCOPE)
endfunction()
function(qt_internal_update_app_target_info_properties target)
# First update the delayed properties with any values that might have been set after the
# qt_internal_add_app() call.
qt_internal_update_delayed_target_info_properties(${target})
# Set defaults in case if no values were set.
get_target_property(target_version ${target} QT_DELAYED_TARGET_VERSION)
if(NOT target_version)
set_target_properties(${target} PROPERTIES QT_DELAYED_TARGET_VERSION "${PROJECT_VERSION}")
endif()
get_target_property(target_description ${target} QT_DELAYED_TARGET_DESCRIPTION)
if(NOT target_description)
qt_internal_get_title_case("${target}" upper_name)
set_target_properties(${target} PROPERTIES QT_DELAYED_TARGET_DESCRIPTION "Qt ${upper_name}")
endif()
# Finally set the final values.
qt_internal_set_target_info_properties_from_delayed_properties("${target}")
endfunction()
function(qt_internal_finalize_app target)
qt_internal_update_app_target_info_properties("${target}")
if(WIN32)
_qt_internal_generate_win32_rc_file("${target}")
endif()
# Rpaths need to be applied in the finalizer, because the MACOSX_BUNDLE property might be
# set after a qt_internal_add_app call.
qt_apply_rpaths(TARGET "${target}" INSTALL_PATH "${INSTALL_BINDIR}" RELATIVE_RPATH)
CMake: Work around build rpath issue when CMAKE_STAGING_PREFIX is set CMake has logic to rewrite build rpaths that contain CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX. This breaks running executables from the build directory, because their build rpath will point to a location where the libraries might not exist yet (we didn't install Qt yet). Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so that CMake does not do the rewriting anymore. CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not function scope, which is why qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro that is called from within each Qt internal function that creates a target. The workaround can be disabled by configuring with -DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON The downside of this workaround is that it breaks per-subdirectory install rules like 'ninja src/gui/install'. Regular global installation like 'ninja install' works fine. This is similar to what we do for tests in qt_set_up_fake_standalone_tests_install_prefix() introduced by 20292250d44e08437306096e9096fc655cc9fb8b The reason it's not as good for other target types is because in contrast to tests, we do want to install them. In case if someone does call `ninja src/gui/install' they will most likely get a permission error, telling them it's not possible to install into /qt_fake_staging_prefix/ check_qt_internal_apply_staging_prefix_build_rpath_workaround Fixes: QTBUG-102592 Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-14 16:04:41 +00:00
qt_internal_apply_staging_prefix_build_rpath_workaround()
endfunction()