CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2021-08-30T14:24:17-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/22555FindMPI extracts the wrong flags from mpich 3.4.22021-08-30T14:24:17-04:00Ben BoeckelFindMPI extracts the wrong flags from mpich 3.4.2`FindMPI` is getting a `MPI_C_COMPILE_OPTIONS:STRING=-framework` setting from the compiler wrappers which doesn't work on its own. More investigation is necessary to diagnose the root problem though.
Cc: @chuck.atkins @brad.king`FindMPI` is getting a `MPI_C_COMPILE_OPTIONS:STRING=-framework` setting from the compiler wrappers which doesn't work on its own. More investigation is necessary to diagnose the root problem though.
Cc: @chuck.atkins @brad.king3.21.2Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/22548Policy CMP0126 warning when using CheckLanguage.cmake with --trace-expand2021-08-19T10:25:19-04:00alcroitoPolicy CMP0126 warning when using CheckLanguage.cmake with --trace-expand
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj LANGUAGES)
include(CheckLanguage)
set(__lang CXX)
check_language(${__lang})
```
```
# Only happens on first configuration
cmake .. --trace-redirect=a.txt
```
```
Trace will be...
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj LANGUAGES)
include(CheckLanguage)
set(__lang CXX)
check_language(${__lang})
```
```
# Only happens on first configuration
cmake .. --trace-redirect=a.txt
```
```
Trace will be written to a.txt
-- Looking for a CXX compiler
-- Looking for a CXX compiler - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
CMake Warning (dev) at /Users/alex/Dev/cmake/Modules/CheckLanguage.cmake:102 (set):
Policy CMP0126 is not set: set(CACHE) does not remove a normal variable of
the same name. Run "cmake --help-policy CMP0126" for policy details. Use
the cmake_policy command to set the policy and suppress this warning.
For compatibility with older versions of CMake, normal variable
"CMAKE_CXX_COMPILER" will be removed from the current scope.
Call Stack (most recent call first):
CMakeLists.txt:8 (check_language)
This warning is for project developers. Use -Wno-dev to suppress it.
```
Using CMake 3.21.1.3.21.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22531[Qt] Changing a c++ source file trigger a rebuild of a lot of other source fi...2021-08-24T09:57:14-04:00مهدي شينون (Mehdi Chinoune)[Qt] Changing a c++ source file trigger a rebuild of a lot of other source files.That starts happen after 3.21.1
with 3.21.0 changing a file rebuild the file and the dependent target, I got a message like [1/4]. but after 3.21.1 I got message like [1/94] which is huge. interrupting the building before it starts and ...That starts happen after 3.21.1
with 3.21.0 changing a file rebuild the file and the dependent target, I got a message like [1/4]. but after 3.21.1 I got message like [1/94] which is huge. interrupting the building before it starts and relaunch it reset the count to [1/12] !!
My project is not small to be a reproducer.
cmake: 3.21.1
Generator: Ninja
OS: Windows/MinGW-w643.21.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22530VS: 3.21.{0,1} removes cl compile option /reference2021-08-16T14:21:49-04:00Brad KingVS: 3.21.{0,1} removes cl compile option /referenceSimilar to #22477, the `/reference mod=path` option does not map to `.vcxproj` file settings correctly.
See discussion [on discourse](https://discourse.cmake.org/t/3756/8).Similar to #22477, the `/reference mod=path` option does not map to `.vcxproj` file settings correctly.
See discussion [on discourse](https://discourse.cmake.org/t/3756/8).3.21.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22526FindPkgConfig sets ..._FOUND variables as cache variables, interaction with C...2021-08-19T10:27:30-04:00Craig ScottFindPkgConfig sets ..._FOUND variables as cache variables, interaction with CMP0126 NEW behaviorThe `FindPkgConfig` module uses an internal `_pkgconfig_set()` function to set various variables. It is also used to set `${_prefix}_FOUND` variables to 1, but this then makes that variable visible outside of the current scope. This inte...The `FindPkgConfig` module uses an internal `_pkgconfig_set()` function to set various variables. It is also used to set `${_prefix}_FOUND` variables to 1, but this then makes that variable visible outside of the current scope. This interacts with the changes in CMake 3.21 associated with CMP0126, leading to unexpected behavior when projects update to set CMP0126 to NEW. For an example of this see [QTBUG-95635](https://bugreports.qt.io/browse/QTBUG-95635).
I'd argue that the module shouldn't be setting any `..._FOUND` variables in the cache, but I don't know if we can change that to only set non-cache variables now. We would have to also consider the scenario where there was already such values in the cache from an earlier CMake version if we did change the behavior.3.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22512CMakeFindBinUtils: Behavior change between CMake 3.20.5 and CMake 3.21.12021-08-16T14:21:49-04:00Cristian AdamCMakeFindBinUtils: Behavior change between CMake 3.20.5 and CMake 3.21.1I have a [llvm-mingw](https://github.com/mstorsjo/llvm-mingw) build of Qt 5.15.2, clang 12 that I use to do a Qt Creator build.
My (CMake) script does:
```cmake
set(ENV{PATH} "${CMAKE_CURRENT_LIST_DIR}/Toolchain/llvm-mingw-lldbtest-x86...I have a [llvm-mingw](https://github.com/mstorsjo/llvm-mingw) build of Qt 5.15.2, clang 12 that I use to do a Qt Creator build.
My (CMake) script does:
```cmake
set(ENV{PATH} "${CMAKE_CURRENT_LIST_DIR}/Toolchain/llvm-mingw-lldbtest-x86_64/bin;$ENV{PATH}")
set(ENV{CC} clang)
set(ENV{CXX} clang++)
execute_process(COMMAND
${CMAKE_COMMAND}
-D "CMAKE_PREFIX_PATH=${CMAKE_CURRENT_LIST_DIR}/Qt/5.15.2/llvmmingw12_64;${CMAKE_CURRENT_LIST_DIR}/Clang-for-QtCreator/llvm-mingw"
...
```
With CMake 3.20.5 it works as I expect it:
```
CMAKE_ADDR2LINE:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/addr2line.exe
CMAKE_AR:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/ar.exe
CMAKE_CXX_COMPILER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/clang++.exe
CMAKE_C_COMPILER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/clang.exe
CMAKE_DLLTOOL:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/dlltool
CMAKE_LINKER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/ld
CMAKE_NM:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/nm.exe
CMAKE_OBJCOPY:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/objcopy.exe
CMAKE_OBJDUMP:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/objdump
CMAKE_RANLIB:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/ranlib.exe
CMAKE_RC_COMPILER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/windres.exe
CMAKE_READELF:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/readelf.exe
CMAKE_STRIP:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/strip.exe
Clang_DIR:PATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/lib/cmake/clang
```
All the tools are part of the `Toolchain` directory, and only the `Clang_DIR` comes from the `Clang-for-QtCreator` dir.
With CMake 3.21.1 I got the following:
```
CMAKE_ADDR2LINE:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-addr2line.exe
CMAKE_AR:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-ar.exe
CMAKE_CXX_COMPILER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/clang++.exe
CMAKE_C_COMPILER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/clang.exe
CMAKE_DLLTOOL:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-dlltool.exe
CMAKE_LINKER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/ld.lld.exe
CMAKE_NM:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-nm.exe
CMAKE_OBJCOPY:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-objcopy.exe
CMAKE_OBJDUMP:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-objdump.exe
CMAKE_RANLIB:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-ranlib.exe
CMAKE_RC_COMPILER:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Toolchain/llvm-mingw-lldbtest-x86_64/bin/windres.exe
CMAKE_READELF:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-readelf.exe
CMAKE_STRIP:FILEPATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/bin/llvm-strip.exe
Clang_DIR:PATH=C:/Projects/QtCreator-llvm-mingw/Clang-for-QtCreator/llvm-mingw/lib/cmake/clang
```
Which shows a different picture. It looks like the tools from `CMakeFindBinUtils.cmake` are taken from `CMAKE_PREFIX_PATH` which has precedence over `PATH` and differs from what CMake 3.20.5 is using.
I used `CMAKE_PREFIX_PATH` to specify the paths for `find_package`, and I expect CMake 3.21 to work as CMake 3.20.3.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22505When cmake_path command is introduced?2021-08-03T10:57:50-04:00Eisuke KawashimaWhen cmake_path command is introduced?Document of `get_filename_component` (v3.20 [rst](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0/Help/command/get_filename_component.rst#L6-9), [HTML](https://cmake.org/cmake/help/v3.20/command/get_filename_component.html)) states...Document of `get_filename_component` (v3.20 [rst](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0/Help/command/get_filename_component.rst#L6-9), [HTML](https://cmake.org/cmake/help/v3.20/command/get_filename_component.html)) states
> *Changed in version 3.19:* This command been superseded by `cmake_path()` command
But that of `cmake_path` (v3.20 [rst](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0/Help/command/cmake_path.rst#L4), [HTML](https://cmake.org/cmake/help/v3.20/command/cmake_path.html)) says
> *New in version 3.20.*
In v3.19, the doc of `cmake_path` does not exist, while the feature seems to have been included (eb583b0a660ba68e8e3b5f820301fde333619283, !5158).3.21.2Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/22501CPack adds a semicolon at the start of installation scripts when building RPM2021-08-03T11:01:13-04:00Artur SamarinCPack adds a semicolon at the start of installation scripts when building RPMWhen generating RPM with pre-install scripts (when using CPACK_RPM_PRE_INSTALL_SCRIPT_FILE variable) CPack generates spec file with extra semicolon in %pre section.
Source script file
```
X
```
Fragment of the generated .spec file
```
...When generating RPM with pre-install scripts (when using CPACK_RPM_PRE_INSTALL_SCRIPT_FILE variable) CPack generates spec file with extra semicolon in %pre section.
Source script file
```
X
```
Fragment of the generated .spec file
```
%pre
;X
```
The same issue is with other script types (post, postun, etc.) . **That leads to uninstallable RPMs.**
Source of the problem is line 14 of [Modules/Internal/CPack/CPackRPM.cmake](https://gitlab.kitware.com/cmake/cmake/-/blob/8e77f495b577b38676aaf274611bc3fb146e51a4/Modules/Internal/CPack/CPackRPM.cmake). Two values are passed to set() that joins them with a semicolon.3.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22494VS: Debug assert triggered during generation of INTERFACE library2021-08-02T14:07:21-04:00Dean GlazeskiVS: Debug assert triggered during generation of INTERFACE libraryMy team was recently working with interface libraries in one of our projects and I happened to be running a debug build of CMake during one of the generations. I hit a debug assert at `cmGeneratorTarget::IsSystemIncludeDirectory` around ...My team was recently working with interface libraries in one of our projects and I happened to be running a debug build of CMake during one of the generations. I hit a debug assert at `cmGeneratorTarget::IsSystemIncludeDirectory` around line 1208 that caused my generate to fail with this debug CMake. The release CMake seems to generate the correct Visual Studio solution and our build hasn't been impacted. I wanted to make sure there wasn't some hidden thing we might run into as a problem assuming the assert was there for a reason.
For a little more context, we are defining a header only interface library, but we'd like to see the headers in Visual Studio without having them appear in *every* linked target. To do that, we used `PRIVATE` in `target_sources` instead of `INTERFACE`. Because we were also using `include_directories` in a parent folder, it appears to be triggering this assert. I've put more details as comments within my attached reproduction test case.
[CMakeInterfaceBug.zip](/uploads/6245097967f211adcbbfee465cf4747a/CMakeInterfaceBug.zip)3.21.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22490Support for Mac OS X 10.4 broken since v. 3.202021-09-23T10:24:27-04:00Evan MillerSupport for Mac OS X 10.4 broken since v. 3.20As of CMake 3.20.1, `-rpath` is being added to the linker command when targeting all Apple platforms. However, `ld` will return an error when `-rpath` is combined with `-mmacosx-version-min=10.4`. The pre-3.20.1 behavior should be restor...As of CMake 3.20.1, `-rpath` is being added to the linker command when targeting all Apple platforms. However, `ld` will return an error when `-rpath` is combined with `-mmacosx-version-min=10.4`. The pre-3.20.1 behavior should be restored when targeting Mac OS 10.4 and earlier.
Downstream report: https://trac.macports.org/ticket/632613.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22487LINK_WHAT_YOU_USE adds -Wl,--no-as-needed to static libraries2021-08-07T08:08:07-04:00ajpennerLINK_WHAT_YOU_USE adds -Wl,--no-as-needed to static librariesWhen I enable the LINK_WHAT_YOU_USE option with cmake version 3.21.* I am finding that this now adds the "-Wl,--no-as-needed" linker option to the archiver used for static libraries. This option is not valid for the archiver and as a res...When I enable the LINK_WHAT_YOU_USE option with cmake version 3.21.* I am finding that this now adds the "-Wl,--no-as-needed" linker option to the archiver used for static libraries. This option is not valid for the archiver and as a result the build fails. If I rollback my cmake version to 3.18.5 everything works as expected. I am operating on production code so I did not pin down the exact version that exposes this bug.3.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22485CTest: Label regexes accumulate when calling ctest_test() multiple times2021-07-29T09:45:30-04:00Kyle EdwardsCTest: Label regexes accumulate when calling ctest_test() multiple times`CMakeLists.txt`:
```cmake
cmake_minimum_required(VERSION 3.20)
project(test NONE)
include(CTest)
add_test(NAME a COMMAND ${CMAKE_COMMAND} -E true)
set_property(TEST a PROPERTY LABELS a)
add_test(NAME b COMMAND ${CMAKE_COMMAND} -E tru...`CMakeLists.txt`:
```cmake
cmake_minimum_required(VERSION 3.20)
project(test NONE)
include(CTest)
add_test(NAME a COMMAND ${CMAKE_COMMAND} -E true)
set_property(TEST a PROPERTY LABELS a)
add_test(NAME b COMMAND ${CMAKE_COMMAND} -E true)
set_property(TEST b PROPERTY LABELS b)
```
`test.cmake`:
```cmake
set(CTEST_SOURCE_DIRECTORY <redacted>)
set(CTEST_BINARY_DIRECTORY <redacted>/build)
ctest_start(Experimental)
foreach(i a b)
ctest_test(INCLUDE_LABEL "^${i}")
endforeach()
```
When you run the `test.cmake` dashboard script, the second round of `ctest_test()` runs no tests, because the label regex `^a$` is left over from the first round, so it's now looking for tests that match both `^a$` and `^b$`. No such test exists.3.21.2Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/22482CUDA/Clang: "No rule to make target" with clang++-122021-07-29T08:45:47-04:00Serge RogatchCUDA/Clang: "No rule to make target" with clang++-12After setting `clang++-12` as the CUDA compiler, the build after CMake configuration produces an error like:
`make[2]: *** No rule to make target 'CMakeFiles/cudalink_exe.dir/exe2.cpp.o', needed by 'CMakeFiles/cudalink_exe.dir/sm_75.cubi...After setting `clang++-12` as the CUDA compiler, the build after CMake configuration produces an error like:
`make[2]: *** No rule to make target 'CMakeFiles/cudalink_exe.dir/exe2.cpp.o', needed by 'CMakeFiles/cudalink_exe.dir/sm_75.cubin'. Stop.`
A reproducer is attached:
[cmake_clang_cuda.tar.gz](/uploads/b684cbd4d4d340d53918ae030a6a92d6/cmake_clang_cuda.tar.gz)
CMake version: 3.21.0
CUDA version: 11.4
Clang version: 12.0.1
OS: Ubuntu 20.043.21.2Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22428Presets v3 inherited by v2 CMakeUserPresets.json bug2021-07-28T09:14:45-04:00scivisionPresets v3 inherited by v2 CMakeUserPresets.json bugCMakeUserPresets.json v2 cannot inherit from CMakePresets.json v3 unless also valid v2.
Upon investigation in !6353 is was determined this is a CMake 3.21.0 presets v3 bug.
CMakePresets.json
```json
{
"version": 3,
"configurePresets...CMakeUserPresets.json v2 cannot inherit from CMakePresets.json v3 unless also valid v2.
Upon investigation in !6353 is was determined this is a CMake 3.21.0 presets v3 bug.
CMakePresets.json
```json
{
"version": 3,
"configurePresets": [
{
"name": "default"
}
]
}
```
CMakeUserPresets.json, with above CMakePreset.json fails due to inheriting v3-only "default" preset.
Does not fail if I remove "inherits".
```json
{
"version": 2,
"configurePresets": [
{
"name": "new", "inherits": "default",
"generator": "Ninja",
"binaryDir": "build"
}
]
}
```
---
This bug was discovered when updating numerous projects CMakePresets.json v2 to v3, while users have untracked CMakeUserPresets.json that were still v2 and inheriting v3 presets, with the users having CMake 3.21.0.
The real-world CMakePresets.json has numerous parameters not relevant to this bug, the minimal case above reproduces the issue with CMake 3.21.03.21.2Kyle EdwardsKyle Edwards