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

234 lines
10 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"
CMake: remove support for building Qt with the old Intel compiler This hasn't worked for some time. It's not in our CI and I don't think it was working at all. When I tried to build it, I ran into several problems with C++17 and an Internal Compiler Error I did not have any interest in working around. After discussing with the Intel compiler team, it was decided that fixing those issues in the old compiler is not going to happen. Instead, their recommendation is to adopt the new LLVM-based compiler, which the last commit added support for. This commit does not remove qmake support for the old ICC. It's possible someone is using qmake with a non-Qt6 project and ICC. Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-12 20:39:37 +00:00
OR "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang|IntelLLVM")
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
# 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()
CMake: remove support for building Qt with the old Intel compiler This hasn't worked for some time. It's not in our CI and I don't think it was working at all. When I tried to build it, I ran into several problems with C++17 and an Internal Compiler Error I did not have any interest in working around. After discussing with the Intel compiler team, it was decided that fixing those issues in the old compiler is not going to happen. Instead, their recommendation is to adopt the new LLVM-based compiler, which the last commit added support for. This commit does not remove qmake support for the old ICC. It's possible someone is using qmake with a non-Qt6 project and ICC. Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-12 20:39:37 +00:00
# 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)
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
endif()
CMake: remove support for building Qt with the old Intel compiler This hasn't worked for some time. It's not in our CI and I don't think it was working at all. When I tried to build it, I ran into several problems with C++17 and an Internal Compiler Error I did not have any interest in working around. After discussing with the Intel compiler team, it was decided that fixing those issues in the old compiler is not going to happen. Instead, their recommendation is to adopt the new LLVM-based compiler, which the last commit added support for. This commit does not remove qmake support for the old ICC. It's possible someone is using qmake with a non-Qt6 project and ICC. Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-12 20:39:37 +00:00
if (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 4.9)
list(APPEND hcleanFLAGS -Wfloat-conversion)
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: remove support for building Qt with the old Intel compiler This hasn't worked for some time. It's not in our CI and I don't think it was working at all. When I tried to build it, I ran into several problems with C++17 and an Internal Compiler Error I did not have any interest in working around. After discussing with the Intel compiler team, it was decided that fixing those issues in the old compiler is not going to happen. Instead, their recommendation is to adopt the new LLVM-based compiler, which the last commit added support for. This commit does not remove qmake support for the old ICC. It's possible someone is using qmake with a non-Qt6 project and ICC. Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-12 20:39:37 +00:00
# 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)
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
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 running of headersclean targets when CMAKE_CXX_FLAGS is set We were passing the full option from the user as a single string in the command-line to the compiler. clang++ -c "-O3 -g1 -march=tigerlake -mprefer-vector-width=256 -maes" [...] error: invalid integral value '3 -g1 -march=tigerlake -mprefer-vector-width=256 -maes' in '-O3 -g1 -march=tigerlake -mprefer-vector-width=256 -maes' Pick-to: 6.2 6.3 Fixes: QTBUG-100315 Change-Id: I6fcda969a9e9427198bffffd16ce83150d4e4263 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-01-28 18:37:20 +00:00
separate_arguments(cxx_flags NATIVE_COMMAND ${CMAKE_CXX_FLAGS})
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
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}")
Add missing framework paths to header check targets CMake doesn't add framework include paths for the includes if add_custom_command is used. When all Qt modules are installed to a single directory, frameworks could be found under QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX, but for Conan builds each module is installed to the separate directory. These directories need to be listed in the QT_ADDITIONAL_PACKAGES_PREFIX_PATH variables family. This takes into account directories that are listed in the QT_ADDITIONAL_PACKAGES_PREFIX_PATH variables and considers they can contain frameworks. Pick-to: 6.2 Fixes: QTBUG-96511 Change-Id: I664381df4859a2e85c399cd94dc2f3996e452c03 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-20 10:41:35 +00:00
# If additional package prefixes are provided, we consider they can contain frameworks
# as well.
foreach(prefix IN LISTS _qt_additional_packages_prefix_paths)
if(prefix MATCHES "/lib/cmake$") # Cut CMake files path
string(APPEND prefix "/../..")
endif()
get_filename_component(prefix "${prefix}" ABSOLUTE)
set(libdir "${prefix}/${INSTALL_LIBDIR}")
if(EXISTS "${libdir}")
list(APPEND framework_includes
"-iframework" "${libdir}")
endif()
endforeach()
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: Compile with -std=c++latest, -Zc:__cplusplus on MSVC c++latest does check that our headers also work with upcoming C++20 support in MSVC. It also implicitly sets -permissive-, which checks for stricter standards compliance. Pick-to: 6.1 Task-number: QTBUG-91117 Change-Id: Iaf1547191969213d570a1b2f59888ad04a7977ab Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-18 07:41:15 +00:00
set(hcleanFLAGS -std:c++latest -Zc:__cplusplus -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