AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a2e23bca0f
qt5base-lts/cmake/QtHeadersClean.cmake

233 lines
11 KiB
CMake
Raw Normal View History

Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
# Add a custom ${module_include_name}_header_check target that builds each header in
# ${module_headers} with a custom set of defines. This makes sure our public headers
# are self-contained, and also compile with more strict compiler options.
function(qt_internal_add_headers_clean_target
module_target
module_include_name
module_headers)
# module_headers is a list of strings of the form
# <headerfile>[:feature]
set(hclean_headers "")
foreach(entry ${module_headers})
string(REPLACE ":" ";" entry_list ${entry})
list(LENGTH entry_list entry_list_length)
list(GET entry_list 0 entry_path)
if (${entry_list_length} EQUAL 2)
list(GET entry_list 1 entry_feature)
if (NOT QT_FEATURE_${entry_feature})
message(STATUS "headersclean: Ignoring header ${entry_path} because of missing feature ${entry_feature}")
continue()
endif()
endif()
list(APPEND hclean_headers ${entry_path})
endforeach()
# Make sure that the header compiles with our strict options
set(hcleanDEFS -DQT_NO_CAST_TO_ASCII
-DQT_NO_CAST_FROM_ASCII
-DQT_NO_URL_CAST_FROM_STRING
-DQT_NO_CAST_FROM_BYTEARRAY
-DQT_NO_KEYWORDS
-DQT_USE_QSTRINGBUILDER
-DQT_USE_FAST_OPERATOR_PLUS)
CMake: Use compiler launcher for headerclean rules This ensures ccache or sccache is used to cache the compilation of the headerclean checks. Task-number: QTBUG-82615 Change-Id: Ie944eb1d643e7271551c9f8337609741e419e9d8 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:50:25 +00:00
set(compiler_to_run "${CMAKE_CXX_COMPILER}")
if(CMAKE_CXX_COMPILER_LAUNCHER)
list(PREPEND compiler_to_run "${CMAKE_CXX_COMPILER_LAUNCHER}")
endif()
CMake: Fix headersclean interaction with header only modules Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed property names from INTERFACE libraries. And it was the wrong thing to do as well. Prefix the properties with INTERFACE_ as appropriate. Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only modules to the headerclean compile commands. This causes configuration issues with UiPlugin in qttools. Fortunately it seems that qmake doesn't do that for 'header_module's either. Finally don't query for the FRAMEWORK property on the passed target (INTERFACE libs can't be frameworks). Instead just query if the whole Qt build itself is a framework build. An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking headersclean add_custom_commands for UiPlugin in qttools. To avoid this the property was renamed to all lower case in 6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate issue, but it's possible it might resurface in the future with a different property name that wasn't renamed. In particular I thought it might happen with QT_NO_UTF8_SOURCE but it didn't. In case something like that happens again, the two possible solutions are to bump minimum CMake version requirement to 3.19 (where upper case property names are allowed to be queried from INTERFACE libs) or to implement recursive include directory fetching similar to our qt_internal_walk_libs implementation. Pick-to: 6.0 Task-number: QTBUG-86053 Task-number: QTBUG-82615 Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-06 15:14:46 +00:00
set(prop_prefix "")
get_target_property(target_type "${target}" TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
set(prop_prefix "INTERFACE_")
endif()
set(target_includes_genex
"$<TARGET_PROPERTY:${module_target},${prop_prefix}INCLUDE_DIRECTORIES>")
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
set(includes_exist_genex "$<BOOL:${target_includes_genex}>")
set(target_includes_joined_genex
"$<${includes_exist_genex}:-I$<JOIN:${target_includes_genex},;-I>>")
CMake: Fix headersclean interaction with header only modules Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed property names from INTERFACE libraries. And it was the wrong thing to do as well. Prefix the properties with INTERFACE_ as appropriate. Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only modules to the headerclean compile commands. This causes configuration issues with UiPlugin in qttools. Fortunately it seems that qmake doesn't do that for 'header_module's either. Finally don't query for the FRAMEWORK property on the passed target (INTERFACE libs can't be frameworks). Instead just query if the whole Qt build itself is a framework build. An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking headersclean add_custom_commands for UiPlugin in qttools. To avoid this the property was renamed to all lower case in 6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate issue, but it's possible it might resurface in the future with a different property name that wasn't renamed. In particular I thought it might happen with QT_NO_UTF8_SOURCE but it didn't. In case something like that happens again, the two possible solutions are to bump minimum CMake version requirement to 3.19 (where upper case property names are allowed to be queried from INTERFACE libs) or to implement recursive include directory fetching similar to our qt_internal_walk_libs implementation. Pick-to: 6.0 Task-number: QTBUG-86053 Task-number: QTBUG-82615 Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-06 15:14:46 +00:00
# qmake doesn't seem to add the defines that are set by the header_only_module when checking the
# the cleanliness of the module's header files.
# This allows us to bypass an error with CMake 3.18 and lower when trying to evaluate
# genex-enhanced compile definitions. An example of that is in
# qttools/src/designer/src/uiplugin/CMakeLists.txt which ends up causing the following error
# message:
# CMake Error at qtbase/cmake/QtModuleHelpers.cmake:35 (add_library):
# INTERFACE_LIBRARY targets may only have whitelisted properties. The
# property "QT_PLUGIN_CLASS_NAME" is not allowed.
# Call Stack (most recent call first):
# src/designer/src/uiplugin/CMakeLists.txt:7 (qt_internal_add_module)
if(NOT target_type STREQUAL "INTERFACE_LIBRARY")
set(target_defines_genex
"$<TARGET_PROPERTY:${module_target},${prop_prefix}COMPILE_DEFINITIONS>")
set(defines_exist_genex "$<BOOL:${target_defines_genex}>")
set(target_defines_joined_genex
"$<${defines_exist_genex}:-D$<JOIN:${target_defines_genex},;-D>>")
endif()
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
# TODO: FIXME
# Passing COMPILE_OPTIONS can break add_custom_command() if the values contain genexes
# that add_custom_command does not support.
#
# Such a case happens on Linux where libraries linking against Threads::Threads bring in a
# '<$<COMPILE_LANG_AND_ID:CUDA,NVIDIA>' genex.
#
# If this is really required for headersclean (and qmake's headerclean implementation does
# actually pass all flags of the associated target), we'll have to replace the genex usage
# with an implementation that recursively processes a target's dependencies property
# to compile an expanded list of values for COMPILE_OPTIONS, and then filter out any genexes.
#
# This is similar to the proposed workaround at
# https://gitlab.kitware.com/cmake/cmake/-/issues/21074#note_814979
#
# See also https://gitlab.kitware.com/cmake/cmake/-/issues/21336
#
#set(target_compile_options_genex "$<TARGET_PROPERTY:${module_target},COMPILE_OPTIONS>")
#set(compile_options_exist_genex "$<BOOL:${target_compile_options_genex}>")
#set(target_compile_options_joined_genex
# "$<${compile_options_exist_genex}:$<JOIN:${target_compile_options_genex},;>>")
CMake: Fix headersclean interaction with header only modules Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed property names from INTERFACE libraries. And it was the wrong thing to do as well. Prefix the properties with INTERFACE_ as appropriate. Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only modules to the headerclean compile commands. This causes configuration issues with UiPlugin in qttools. Fortunately it seems that qmake doesn't do that for 'header_module's either. Finally don't query for the FRAMEWORK property on the passed target (INTERFACE libs can't be frameworks). Instead just query if the whole Qt build itself is a framework build. An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking headersclean add_custom_commands for UiPlugin in qttools. To avoid this the property was renamed to all lower case in 6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate issue, but it's possible it might resurface in the future with a different property name that wasn't renamed. In particular I thought it might happen with QT_NO_UTF8_SOURCE but it didn't. In case something like that happens again, the two possible solutions are to bump minimum CMake version requirement to 3.19 (where upper case property names are allowed to be queried from INTERFACE libs) or to implement recursive include directory fetching similar to our qt_internal_walk_libs implementation. Pick-to: 6.0 Task-number: QTBUG-86053 Task-number: QTBUG-82615 Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-06 15:14:46 +00:00
set(target_compile_flags_genex
"$<TARGET_PROPERTY:${module_target},${prop_prefix}COMPILE_FLAGS>")
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
set(compile_flags_exist_genex "$<BOOL:${target_compile_flags_genex}>")
set(target_compile_flags_joined_genex
"$<${compile_flags_exist_genex}:$<JOIN:${target_compile_flags_genex},;>>")
CMake: Use compiler launcher for headerclean rules This ensures ccache or sccache is used to cache the compilation of the headerclean checks. Task-number: QTBUG-82615 Change-Id: Ie944eb1d643e7271551c9f8337609741e419e9d8 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:50:25 +00:00
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU"
OR "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang"
OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
# Turn on some extra warnings not found in -Wall -Wextra.
set(hcleanFLAGS -Wall -Wextra -Werror -Woverloaded-virtual -Wshadow -Wundef -Wfloat-equal
-Wnon-virtual-dtor -Wpointer-arith -Wformat-security -Wno-long-long -Wno-variadic-macros
-pedantic-errors)
if(QT_FEATURE_reduce_relocations AND UNIX)
list(APPEND hcleanFLAGS -fPIC)
endif()
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
# these warnings are disabled because explicit constructors with zero or
# multiple arguments are permitted in C++11:
# 2304: non-explicit constructor with single argument may cause implicit type
# conversion
# 2305: declaration of 'explicit' constructor without a single argument is
# redundant
#
# ICC 14+ has a bug with -Wshadow, emitting it for cases where there's no
# shadowing (issue ID 0000698329, task DPD200245740)
list(APPEND hcleanFLAGS -wd2304,2305 -Wshadow)
else()
# options accepted by GCC and Clang
list(APPEND hcleanFLAGS -Wchar-subscripts -Wold-style-cast)
if (NOT ((TEST_architecture_arch STREQUAL arm)
OR (TEST_architecture_arch STREQUAL mips)))
list(APPEND hcleanFLAGS -Wcast-align)
endif()
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
list(APPEND hcleanFLAGS -Wzero-as-null-pointer-constant)
if (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 4.5)
list(APPEND hcleanFLAGS -Wdouble-promotion)
endif()
if (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 4.9)
list(APPEND hcleanFLAGS -Wfloat-conversion)
# GCC 9 has a lot of false positives relating to these
list(APPEND hcleanFlags -Wno-deprecated-copy -Wno-redundant-move
-Wno-format-overflow -Wno-init-list-lifetime)
endif()
endif()
endif()
Run headers_clean check with C++20 (gcc, clang) The headers are already somewhat tested with C++17 in the regular build. So let's try in the headers_clean check with C++20 instead. Using C++20 with MSVC 19.28 doesn't work yet though: corelib/tools/qalgorithms.h(247): error C2039: 'popcount': is not a member of 'std' corelib/tools/qhashfunctions.h(311): note: see declaration of 'std' corelib/tools/qalgorithms.h(247): error C3861: 'popcount': identifier not found ... Task-number: QTQAINFRA-4242 Change-Id: I1b48bcb9656fe1587fe03d3a17e3484c693aa295 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-09 13:18:35 +00:00
# Use strict mode C++20, with no GNU extensions (see -pedantic-errors above).
list(APPEND hcleanFLAGS -std=c++2a)
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
CMake: Fix headersclean to work on macOS It appears there's a difference between the chosen macOS compiler path in the CI versus the compiler path on my local machine. In the CI the chosen compiler path ends up 'being /usr/bin/clang++' whereas for me locally it's /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ For some reason the headersclean commands succeed in the CI, but locally they fail for me saying that standard library includes can not be found, unless an explicit sysroot flag is specified. I assume that in the CI the '/usr/bin/clang++' compiler shim chooses some implcit sysroot, whereas the longer Xcode compiler expects an explicit sysroot. It's probably also affected by the fact that in the CI we pass an explicit CMAKE_OSX_SYSROOT to a non-standard Xcode location e.g. /Applications/Xcode11.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk Note the '11' in the Xcode app name. Locally I don't pass a custom CMAKE_OSX_SYSROOT, and my Xcode is installed in a regular location e.g /Applications/Xcode.app. The sysroot flag and path is added to regular CXX compilation rules inside CMake's core (in cmLocalGenerator.cxx). Reuse the same variables that CMake uses and add them to our headersclean command rules. Task-number: QTBUG-82615 Change-Id: Ic03ea27e39471f5fa168eb5970bf3d3f1d1be251 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-16 15:21:04 +00:00
set(cxx_flags ${CMAKE_CXX_FLAGS})
if(APPLE AND CMAKE_OSX_SYSROOT)
list(APPEND cxx_flags "${CMAKE_CXX_SYSROOT_FLAG}" "${CMAKE_OSX_SYSROOT}")
endif()
CMake: Fix headersclean interaction with header only modules Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed property names from INTERFACE libraries. And it was the wrong thing to do as well. Prefix the properties with INTERFACE_ as appropriate. Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only modules to the headerclean compile commands. This causes configuration issues with UiPlugin in qttools. Fortunately it seems that qmake doesn't do that for 'header_module's either. Finally don't query for the FRAMEWORK property on the passed target (INTERFACE libs can't be frameworks). Instead just query if the whole Qt build itself is a framework build. An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking headersclean add_custom_commands for UiPlugin in qttools. To avoid this the property was renamed to all lower case in 6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate issue, but it's possible it might resurface in the future with a different property name that wasn't renamed. In particular I thought it might happen with QT_NO_UTF8_SOURCE but it didn't. In case something like that happens again, the two possible solutions are to bump minimum CMake version requirement to 3.19 (where upper case property names are allowed to be queried from INTERFACE libs) or to implement recursive include directory fetching similar to our qt_internal_walk_libs implementation. Pick-to: 6.0 Task-number: QTBUG-86053 Task-number: QTBUG-82615 Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-06 15:14:46 +00:00
if(APPLE AND QT_FEATURE_framework)
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
# For some reason CMake doesn't generate -iframework flags from the INCLUDE_DIRECTORIES
# generator expression we provide, so pass it explicitly and hope for the best.
CMake: Fix headersclean interaction with header only modules Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed property names from INTERFACE libraries. And it was the wrong thing to do as well. Prefix the properties with INTERFACE_ as appropriate. Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only modules to the headerclean compile commands. This causes configuration issues with UiPlugin in qttools. Fortunately it seems that qmake doesn't do that for 'header_module's either. Finally don't query for the FRAMEWORK property on the passed target (INTERFACE libs can't be frameworks). Instead just query if the whole Qt build itself is a framework build. An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking headersclean add_custom_commands for UiPlugin in qttools. To avoid this the property was renamed to all lower case in 6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate issue, but it's possible it might resurface in the future with a different property name that wasn't renamed. In particular I thought it might happen with QT_NO_UTF8_SOURCE but it didn't. In case something like that happens again, the two possible solutions are to bump minimum CMake version requirement to 3.19 (where upper case property names are allowed to be queried from INTERFACE libs) or to implement recursive include directory fetching similar to our qt_internal_walk_libs implementation. Pick-to: 6.0 Task-number: QTBUG-86053 Task-number: QTBUG-82615 Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-06 15:14:46 +00:00
list(APPEND framework_includes
Fix framework path for *_header_check targets When building a Qt module against an installer-provided Qt on macOS, the module pulls in the headersclean feature that creates the *_header_check targets. Those targets try to compile the public headers of the module, and the compilation command contains the -iframework argument. That -iframework argument is supposed to point to the directory where the Qt libs are installed. However, it pointed to the original CMAKE_INSTALL_PREFIX of the machine where Qt was packaged. Use the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable instead that contains the real installation location, even for an installer-provided Qt. Pick-to: 6.0 Fixes: QTBUG-90402 Change-Id: I27de8b3cc816488c2716042383b334d5c421452d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-01-19 16:17:40 +00:00
"-iframework" "${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_LIBDIR}")
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
endif()
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
foreach(header ${hclean_headers})
get_filename_component(input_path "${header}" ABSOLUTE)
Fix output files of the *_header_check targets Header files of a Qt module are usually found in subdirectories. Avoid creating object file paths like "header_foo/bar.h.o". When building with conan, the "header_foo" subdirectory was not created for whatever reason. Now, we make sure we have clean object file paths, e.g. "header_check/foo/bar.h.o", and we create the directory upfront before invoking the compiler. Fixes: QTBUG-90529 Change-Id: Ifa5d6b97e07fc4e249c58cda5128439d60b14f5f Reviewed-by: Kai Koehne <kai.koehne@qt.io> (cherry picked from commit 54980200c79b466a276a4d3054390e4b3162e9ed) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-01-26 13:53:13 +00:00
set(artifact_path "header_check/${header}.o")
get_filename_component(artifact_directory "${artifact_path}" DIRECTORY)
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
set(comment_header_path "${CMAKE_CURRENT_SOURCE_DIR}/${header}")
file(RELATIVE_PATH comment_header_path "${PROJECT_SOURCE_DIR}" "${comment_header_path}")
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
add_custom_command(
OUTPUT "${artifact_path}"
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
COMMENT "headersclean: Checking header ${comment_header_path}"
Fix output files of the *_header_check targets Header files of a Qt module are usually found in subdirectories. Avoid creating object file paths like "header_foo/bar.h.o". When building with conan, the "header_foo" subdirectory was not created for whatever reason. Now, we make sure we have clean object file paths, e.g. "header_check/foo/bar.h.o", and we create the directory upfront before invoking the compiler. Fixes: QTBUG-90529 Change-Id: Ifa5d6b97e07fc4e249c58cda5128439d60b14f5f Reviewed-by: Kai Koehne <kai.koehne@qt.io> (cherry picked from commit 54980200c79b466a276a4d3054390e4b3162e9ed) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-01-26 13:53:13 +00:00
COMMAND ${CMAKE_COMMAND} -E make_directory "${artifact_directory}"
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
COMMAND
${compiler_to_run} -c ${cxx_flags}
"${target_compile_flags_joined_genex}"
"${target_defines_joined_genex}"
${hcleanFLAGS}
"${target_includes_joined_genex}"
${framework_includes}
${hcleanDEFS}
-xc++ "${input_path}"
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
-o${artifact_path}
IMPLICIT_DEPENDS CXX
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
VERBATIM
COMMAND_EXPAND_LISTS)
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
list(APPEND hclean_artifacts "${artifact_path}")
endforeach()
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
# -Za would enable strict standards behavior, but we can't add it because
# <windows.h> and <GL.h> violate the standards.
headersclean: Check for all-W3 MSVC warnings C4180, C4458 were disabled already in 2012, in commit 6668f5becfb. C4577 was disabled due to QtScript being compiled without exception support in commit 97d7d80e735. Anyhow, Qt Script is now officially gone in Qt 6, and Qt headers do work just fine with C4180. Finally, C4458 is nowadays a W4 warning, so not enabled in the first place. Task-number: QTBUG-82615 Change-Id: I2f9b8e858817876b069a166129fbfac7ef3587a0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
2020-08-25 10:52:48 +00:00
set(hcleanFLAGS -std:c++17 -WX -W3)
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
# cl.exe needs a source path
get_filename_component(source_path "${QT_MKSPECS_DIR}/features/data/dummy.cpp" REALPATH)
foreach(header ${hclean_headers})
# We need realpath here to make sure path starts with drive letter
get_filename_component(input_path "${header}" REALPATH)
set(artifact_path "header_${header}.o")
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
set(comment_header_path "${CMAKE_CURRENT_SOURCE_DIR}/${header}")
file(RELATIVE_PATH comment_header_path "${PROJECT_SOURCE_DIR}" "${comment_header_path}")
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
add_custom_command(
OUTPUT "${artifact_path}"
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
COMMENT "headersclean: Checking header ${comment_header_path}"
COMMAND
${compiler_to_run} -nologo -c ${CMAKE_CXX_FLAGS}
"${target_compile_flags_joined_genex}"
"${target_defines_joined_genex}"
${hcleanFLAGS}
"${target_includes_joined_genex}"
${hcleanDEFS}
-FI "${input_path}"
-Fo${artifact_path} "${source_path}"
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
IMPLICIT_DEPENDS CXX
CMake: Fix headersclean to build with proper flags It's not sufficient to pass -I{prefix}/include when doing the header clean check. We need to propagate all target include directories and compile definitions, and also the compile flags for good measure. For macOS frameworks we also need to explicitly pass an -iframework flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style includes are found when building other repos than qtbase. Task-number: QTBUG-82615 Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:35:16 +00:00
VERBATIM
COMMAND_EXPAND_LISTS)
Port headersclean check to CMake Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-19 12:05:29 +00:00
list(APPEND hclean_artifacts "${artifact_path}")
endforeach()
else()
message(ERROR "CMAKE_CXX_COMPILER_ID \"${CMAKE_CXX_COMPILER_ID}\" is not supported for the headersclean check.")
endif()
add_custom_target(${module_include_name}_header_check
COMMENT "headersclean: Checking headers in ${module_include_name}"
DEPENDS ${hclean_artifacts}
VERBATIM)
add_dependencies(${module_target} ${module_include_name}_header_check)
endfunction()
Reference in New Issue Copy Permalink