summaryrefslogtreecommitdiffstats
path: root/cmake/QtHeadersClean.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: remove support for building Qt with the old Intel compilerThiago Macieira2021-10-131-32/+18
| | | | | | | | | | | | | | | | | | 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>
* CMake: add support for Intel's LLVM-based compilerThiago Macieira2021-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This includes a few cleanups to our .cmake files where it was easier to combine existing sections of Clang / AppleClang that no longer needed to be distinct. icpx could be replaced with a shell script: exec `basename $0`/clang++ --intel "$@" tst_qnumeric is not passing FAIL! : tst_QNumeric::classifyF() Compared values are not the same Actual (qFpClassify(tiny / two)): 2 Expected (FP_SUBNORMAL) : 3 Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)] FAIL! : tst_QNumeric::classifyD() Compared values are not the same Actual (qFpClassify(tiny / two)): 2 Expected (FP_SUBNORMAL) : 3 Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)] FAIL! : tst_QNumeric::floatDistance(denormal) Compared values are not the same Actual (qFloatDistance(from, stop)): 0 Expected (expectedDistance) : 4194304 Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)] FAIL! : tst_QNumeric::doubleDistance(denormal) Compared values are not the same Actual (qFloatDistance(from, stop)): 0 Expected (expectedDistance) : 2251799813685248 Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)] P Change-Id: Icb2516126f674e7b8bb3fffd16ad59431e8c3379 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add missing framework paths to header check targetsAlexey Edelev2021-09-201-0/+15
| | | | | | | | | | | | | | | | | 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>
* headersclean: Compile with -std=c++latest, -Zc:__cplusplus on MSVCKai Köhne2021-03-041-1/+1
| | | | | | | | | | | 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>
* Run headers_clean check with C++20 (gcc, clang)Kai Köhne2021-02-151-2/+2
| | | | | | | | | | | | | | | | 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>
* Fix output files of the *_header_check targetsJoerg Bornemann2021-01-271-1/+3
| | | | | | | | | | | | | | | | | 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>
* Fix framework path for *_header_check targetsJoerg Bornemann2021-01-191-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix headersclean interaction with header only modulesAlexandru Croitor2020-11-251-12/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix headersclean to build with proper flagsAlexandru Croitor2020-10-231-11/+74
| | | | | | | | | | | | | | | | 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>
* CMake: Use compiler launcher for headerclean rulesAlexandru Croitor2020-10-231-2/+8
| | | | | | | | | 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>
* CMake: Fix headersclean to work on macOSAlexandru Croitor2020-10-231-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* headersclean: Fix include paths for dependent modulesKai Koehne2020-09-211-2/+4
| | | | | | | | | | | | Having ${QT_BUILD_DIR}/include as include path is not enough for modules outside of qtbase. They also need to pick up headers from e.g. Qt Core, which are available only in "${CMAKE_INSTALL_PREFIX}/include" This amends db21bad936a761f475145886f1e06dfcfa11eb80 Fixes: QTBUG-82615 Change-Id: Ib003a66ce039bf1ab6e21a3b1cd86923207eb3db Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* headersclean: Check for all-W3 MSVC warningsKai Koehne2020-08-261-6/+1
| | | | | | | | | | | | | | | 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>
* Port headersclean check to CMakeKai Koehne2020-08-251-0/+139
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 09:11:27 +0000