CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-28T11:44:32-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25833Automoc uses the Debug version of moc2024-03-28T11:44:32-04:00Andreas HaferburgAutomoc uses the Debug version of mocThis is a follow up to https://gitlab.kitware.com/cmake/cmake/-/issues/25707.
I'm not sure if/how much code I need to post here.
We use Conan to add Debug and Release builds of Qt 6.6.2.
`find_package(Qt6 CONFIG REQUIRED COMPONENTS Co...This is a follow up to https://gitlab.kitware.com/cmake/cmake/-/issues/25707.
I'm not sure if/how much code I need to post here.
We use Conan to add Debug and Release builds of Qt 6.6.2.
`find_package(Qt6 CONFIG REQUIRED COMPONENTS Core Widgets)`
The AutogenInfo.json points to the Debug version of moc.exe.
![image](/uploads/882a8929978f03f9f02eda68fa3ca4f8/image.png)
![image](/uploads/f5348f5f6b5110ab5f3515f86de26545/image.png)
(There's a .pdb file next to it, and we don't build Release with symbols.)
The [documentation of AUTOMOC_EXECUTABLE](https://cmake.org/cmake/help/latest/prop_tgt/AUTOMOC_EXECUTABLE.html#prop_tgt:AUTOMOC_EXECUTABLE) says
> Usually this property does not need to be set. Only consider this property if auto-detection of moc can not work -- e.g. because you are building the moc binary as part of your project.https://gitlab.kitware.com/cmake/cmake/-/issues/25822cmake-gui: empty generator or toolset fails on the reconfigure while set insi...2024-03-26T03:10:06-04:00Alex Overchenkocmake-gui: empty generator or toolset fails on the reconfigure while set inside the script# Description
I need to load default valued inside the main `CMakeLists.txt` script.
If you keep `generator` & `toolset` values from CMake GUI empty, they really pass empty values.
If I correctly understand the #24864, this should wor...# Description
I need to load default valued inside the main `CMakeLists.txt` script.
If you keep `generator` & `toolset` values from CMake GUI empty, they really pass empty values.
If I correctly understand the #24864, this should work after upgrading to 3.29.0, but it really doesn't work.
# Environment
CMake GUI 3.29.0
Windows 10 Pro
Visual Studio 17 2022 generator
# Error text from GUI log
* Nothing was specified in generator & toolset
```txt
CMake Error: Error: generator platform:
Does not match the platform used previously: x64
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
```
* generator was set as `x64`
```txt
CMake Error: Error: generator toolset:
Does not match the toolset used previously: v143
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
```
* both generator & toolset specified
```txt
Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19045.
Configuring done (0.0s)
```
# Steps to reproduce
1. Create empty folder with `CMakeLists.txt` file:
```cmake
cmake_minimum_required(VERSION 3.24)
if(NOT CMAKE_GENERATOR_TOOLSET)
set(CMAKE_GENERATOR_TOOLSET "v143" CACHE INTERNAL "Visual Studio toolset to use for CMake")
endif()
if(NOT CMAKE_GENERATOR_PLATFORM)
set(CMAKE_GENERATOR_PLATFORM "x64" CACHE INTERNAL "Visual Studio platform to use for CMake")
endif()
if(NOT CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE)
set(CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE "x64" CACHE INTERNAL "Host architecture to use for CMake")
endif()
project(Test)
```
2. Load project from CMake GUI
3. Delete cache through `File`->`Delete Cache`
4. Press `Configure` button
5. Use this settings (or another from log):
![image](/uploads/4f52561f2191a9eb23fb2929a9acb81a/image.png)
6. Press `Finish`
7. Wait for configure is finished
8. Press `Configure` button again
9. See the errorhttps://gitlab.kitware.com/cmake/cmake/-/issues/25820FindLibXml2: 3.29.0 finds wrong libxml2.a in build for MSVC ABI2024-03-27T08:17:11-04:00Alexander NeumannFindLibXml2: 3.29.0 finds wrong libxml2.a in build for MSVC ABIrelated #23975 !9173
currently trying to update CMake in vcpkg to 3.29 and saw this:
```
[5067/5075] C:\Windows\system32\cmd.exe /C "cd . && D:\downloads\tools\cmake-3.29.0-windows\cmake-3.29.0-windows-i386\bin\cmake.exe -E vs_link_dll...related #23975 !9173
currently trying to update CMake in vcpkg to 3.29 and saw this:
```
[5067/5075] C:\Windows\system32\cmd.exe /C "cd . && D:\downloads\tools\cmake-3.29.0-windows\cmake-3.29.0-windows-i386\bin\cmake.exe -E vs_link_dll --intdir=tools\lldb\source\API\CMakeFiles\liblldb.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests -- C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1438~1.331\bin\Hostx64\x86\link.exe @CMakeFiles\liblldb.rsp /out:bin\liblldb.dll /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:17.0 /machine:X86 /nologo /debug /INCREMENTAL && cd ."
FAILED: bin/liblldb.dll lib/liblldb.lib
C:\Windows\system32\cmd.exe /C "cd . && D:\downloads\tools\cmake-3.29.0-windows\cmake-3.29.0-windows-i386\bin\cmake.exe -E vs_link_dll --intdir=tools\lldb\source\API\CMakeFiles\liblldb.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests -- C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1438~1.331\bin\Hostx64\x86\link.exe @CMakeFiles\liblldb.rsp /out:bin\liblldb.dll /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:17.0 /machine:X86 /nologo /debug /INCREMENTAL && cd ."
LINK Pass 1: command "C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1438~1.331\bin\Hostx64\x86\link.exe @CMakeFiles\liblldb.rsp /out:bin\liblldb.dll /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:17.0 /machine:X86 /nologo /debug /INCREMENTAL /MANIFEST /MANIFESTFILE:tools\lldb\source\API\CMakeFiles\liblldb.dir/intermediate.manifest tools\lldb\source\API\CMakeFiles\liblldb.dir/manifest.res" failed (exit code 1120) with the following output:
Creating library lib\liblldb.lib and object lib\liblldb.exp
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlFreeDoc referenced in function "public: void __thiscall lldb_private::XMLDocument::Clear(void)" (?Clear@XMLDocument@lldb_private@@QAEXXZ)
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlDocGetRootElement referenced in function "public: class lldb_private::XMLNode __thiscall lldb_private::XMLDocument::GetRootElement(char const *)" (?GetRootElement@XMLDocument@lldb_private@@QAE?AVXMLNode@2@PBD@Z)
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlGetProp referenced in function "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall lldb_private::XMLNode::GetAttributeValue(char const *,char const *)const " (?GetAttributeValue@XMLNode@lldb_private@@QBE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBD0@Z)
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlSetGenericErrorFunc referenced in function "public: bool __thiscall lldb_private::XMLDocument::ParseFile(char const *)" (?ParseFile@XMLDocument@lldb_private@@QAE_NPBD@Z)
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlParseFile referenced in function "public: bool __thiscall lldb_private::XMLDocument::ParseFile(char const *)" (?ParseFile@XMLDocument@lldb_private@@QAE_NPBD@Z)
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlReadMemory referenced in function "public: bool __thiscall lldb_private::XMLDocument::ParseMemory(char const *,unsigned int,char const *)" (?ParseMemory@XMLDocument@lldb_private@@QAE_NPBDI0@Z)
lldbHost.lib(XML.cpp.obj) : error LNK2019: unresolved external symbol __imp__xmlFree referenced in function "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall lldb_private::XMLNode::GetAttributeValue(char const *,char const *)const " (?GetAttributeValue@XMLNode@lldb_private@@QBE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBD0@Z)
D:\downloads\tools\perl\5.38.0.1\c\lib\libxml2.a : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
```
Currently running CI with --trace-expand and --debug-find to see what is going on.3.29.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25818Kernel panic when bootstrapping on Mac OS X 10.7.52024-03-26T09:06:32-04:00Ryan Carsten SchmidtKernel panic when bootstrapping on Mac OS X 10.7.5Running the `./bootstrap` script to build recent CMake on Mac OS X 10.7.5 causes a kernel panic. IOW, the OS crashes and stops responding and the computer must be restarted manually. AFAIK, 10.7.x is the only macOS version affected. The ...Running the `./bootstrap` script to build recent CMake on Mac OS X 10.7.5 causes a kernel panic. IOW, the OS crashes and stops responding and the computer must be restarted manually. AFAIK, 10.7.x is the only macOS version affected. The name of the process running when the kernel panic occurs is `cmake`. The crash occurs right as the bootstrap `cmake` process is starting to run. I [have observed this](https://trac.macports.org/ticket/68718) on a VMware ESXi virtual machine on a 2009 Xserve and on a real 2011 13" MacBook Pro. @kencu [reports observing this](https://trac.macports.org/ticket/67540#comment:15) on a Parallels VM and also on real Mac hardware.
I do not recall seeing this problem with CMake versions before 3.28.0-rc1. I did see this problem with release candidates of CMake 3.28.0 and the latest 3.29.x code from the repository as of commit cff8aefc6aa5fcf5c659b2c40027c86618426005 from March 22. @kencu reports that 3.28.4 does not have the problem.
@kencu pointed to #25414 and !9176 as being possibly related. !9176 was included in CMake 3.28.2 and later but not 3.29.x. Since !9176 is a large changeset I did not try applying it to the current code but I did test whether it is the reason for the problem being solved in 3.28.x.
Using this command to build (after [installing clang-3.7 with MacPorts](https://ports.macports.org/port/clang-3.7)) on the 2011 MacBook Pro:
```
mkdir build && cd build
CC=clang-mp-3.7 CXX=clang++-mp-3.7 CXXFLAGS="-stdlib=libc++ -D_DARWIN_C_SOURCE" ../bootstrap --parallel=$(sysctl -n hw.activecpu)
```
I tested commit adb3e13d323aeb19c3824112cfa712cc122db3b4 which was right before the use of libuv was reverted and experienced the kernel panic. And I tested bcbb212df704d36736731aa567b291fd97401804 which is the commit in which the use of libuv was reverted and the crash does not occur, so this does indeed appear to be the solution to the kernel panic. A subsequent `make -j$(sysctl -n hw.activecpu)` fails when building the bundled cmcurl but that's a separate problem.3.29.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25815Swift: CMAKE_COLOR_DIAGNOSTICS does not affect Swift2024-03-26T07:56:17-04:00Evan WildeSwift: CMAKE_COLOR_DIAGNOSTICS does not affect SwiftSetting the `CMAKE_COLOR_DIAGNOSTICS` does not add the `-color-diagnostics` flag to Swift invocations, so Swift doesn't emit color diagnostics.Setting the `CMAKE_COLOR_DIAGNOSTICS` does not add the `-color-diagnostics` flag to Swift invocations, so Swift doesn't emit color diagnostics.3.30.0https://gitlab.kitware.com/cmake/cmake/-/issues/25814clang-tidy CXX modules on Windows2024-03-25T13:46:03-04:00Mani T.clang-tidy CXX modules on WindowsIs clang-tidy on Windows (aka cl.exe) supposed to work when module are enabled but there is no module in the target?
I have seen different ways of triggering this error and I don't know enough to know if it is just tools (cl.exe, clang-t...Is clang-tidy on Windows (aka cl.exe) supposed to work when module are enabled but there is no module in the target?
I have seen different ways of triggering this error and I don't know enough to know if it is just tools (cl.exe, clang-tidy, cmake) not there yet or an issue.
Here is the error:
```
"C:\Program Files\CMake\bin\cmake.exe" -E __run_co_compile --tidy="C:/Program Files/LLVM/bin/clang-tidy.exe;-extra-arg=-Wno-unknown-warning-option;-extra-arg=-Wno-ignored-optimization-argument;-extra-arg=-Wno-unused-command-line-argument;-p;-extra-arg=/std:c++23;--extra-arg-before=--driver-mode=cl" --source=D:\_Dev\Projects\PersonalWorks\Projects\TestUtilities\TestUtilities\BasicTestsGenerator.cpp -- C:\PROGRA~1\MIB055~1\2022\Preview\VC\Tools\MSVC\1440~1.336\bin\Hostx64\x64\cl.exe /nologo /TP -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -DTESTUTILITIES_STATIC_DEFINE -ID:\_Dev\Projects\PersonalWorks\Projects\TestUtilities -ID:\_Dev\Projects\PersonalWorks\_Out\build\Windows-Msvc-Ninja-Debug\Projects\TestUtilities -external:ID:\_Dev\Projects\PersonalWorks\_Out\vcpkg_installed\x64-windows\include -external:W0 /EHsc /MP /Ob0 /Od /RTC1 -std:c++latest -MDd -Zi /GL /MP /diagnostics:column /sdl /DYNAMICBASE /guard:cf /W4 /w14242 /w14254 /w14263 /w14265 /w14287 /we4289 /w14296 /w14311 /w14545 /w14546 /w14547 /w14549 /w14555 /w14619 /w14640 /w14826 /w14905 /w14906 /w14928 /permissive- /showIncludes @Projects\TestUtilities\CMakeFiles\TestUtilities.dir\TestUtilities\BasicTestsGenerator.cpp.obj.modmap /FoProjects\TestUtilities\CMakeFiles\TestUtilities.dir\TestUtilities\BasicTestsGenerator.cpp.obj /FdProjects\TestUtilities\CMakeFiles\TestUtilities.dir\TestUtilities.pdb /FS -c D:\_Dev\Projects\PersonalWorks\Projects\TestUtilities\TestUtilities\BasicTestsGenerator.cpp
error: no such file or directory: '@Projects\TestUtilities\CMakeFiles\TestUtilitiesGBenchmark.dir\TestUtilities\BasicTestsGenerator.cpp.obj.modmap' [clang-diagnostic-error]
error: no such file or directory: '@Projects\TestUtilities\CMakeFiles\TestUtilitiesTestsGTest.dir\TestUtilities\BasicTestsGenerator.cpp.obj.modmap' [clang-diagnostic-error]
Error while processing D:\_Dev\Projects\PersonalWorks\Projects\TestUtilities\TestUtilities\BasicTestsGenerator.cpp.
Error while processing D:\_Dev\Projects\PersonalWorks\Projects\TestUtilities\TestUtilities\BasicTestsGenerator.cpp.
```
This caught my eye, the "@" made me thing something is wrong here.
`@Projects\TestUtilities\CMakeFiles\TestUtilities.dir\TestUtilities\BasicTestsGenerator.cpp.obj.modmap `
What I think is relevant here (I might be wrong) is how I set the target sources. This target doesn't have any modules. (But I do have a function that does all the right CMake call so other targets could have modules. I am assuming it is valid to pass an empty FILE_SET.
```
set(moduleFiles
)
target_sources(${targetName}
PRIVATE ${privateFiles}
PUBLIC
FILE_SET CXX_MODULES FILES ${moduleFiles}
##PUBLIC
##FILE_SET CXX_MODULE_HEADER_UNITS FILES ${headerUnitFiles}
PUBLIC ${publicFiles}
INTERFACE ${interfaceFiles}
)
```
At first I thought the issue was empty modmap, then I saw this one.
```
"C:\Program Files\CMake\bin\cmake.exe" -E __run_co_compile --tidy="C:/Program Files/LLVM/bin/clang-tidy.exe;-extra-arg=-Wno-unknown-warning-option;-extra-arg=-Wno-ignored-optimization-argument;-extra-arg=-Wno-unused-command-line-argument;-p;-extra-arg=/std:c++23;--extra-arg-before=--driver-mode=cl" --source=D:\_Dev\Projects\PersonalWorks\Projects\Core\Core\CoreUtility.ixx -- C:\PROGRA~1\MIB055~1\2022\Preview\VC\Tools\MSVC\1440~1.336\bin\Hostx64\x64\cl.exe /nologo /TP -DCORE_STATIC_DEFINE -DFMT_SHARED -DTESTUTILITIES_STATIC_DEFINE -ID:\_Dev\Projects\PersonalWorks\Projects\Core -ID:\_Dev\Projects\PersonalWorks\_Out\build\Windows-Msvc-Ninja-Debug\Projects\Core -ID:\_Dev\Projects\PersonalWorks\_Out\build\Windows-Msvc-Ninja-Debug\Projects\Config -ID:\_Dev\Projects\PersonalWorks\Projects\TestUtilities -ID:\_Dev\Projects\PersonalWorks\_Out\build\Windows-Msvc-Ninja-Debug\Projects\TestUtilities -external:ID:\_Dev\Projects\PersonalWorks\_Out\vcpkg_installed\x64-windows\include -external:W0 /EHsc /MP /Ob0 /Od /RTC1 -std:c++latest -MDd -Zi /GL /MP /diagnostics:column /sdl /DYNAMICBASE /guard:cf /W4 /w14242 /w14254 /w14263 /w14265 /w14287 /we4289 /w14296 /w14311 /w14545 /w14546 /w14547 /w14549 /w14555 /w14619 /w14640 /w14826 /w14905 /w14906 /w14928 /permissive- /showIncludes @Projects\Core\CMakeFiles\Core.dir\Core\CoreUtility.ixx.obj.modmap /FoProjects\Core\CMakeFiles\Core.dir\Core\CoreUtility.ixx.obj /FdProjects\Core\CMakeFiles\Core.dir\Core.pdb /FS -c D:\_Dev\Projects\PersonalWorks\Projects\Core\Core\CoreUtility.ixx
error: no such file or directory: 'Projects\Core\CMakeFiles\Core.dir\CoreUtility.ifc' [clang-diagnostic-error]
Error while processing D:\_Dev\Projects\PersonalWorks\Projects\Core\Core\CoreUtility.ixx.
```
Which is not empty
```
-interface
-ifcOutput Projects\Core\CMakeFiles\Core.dir\CoreUtility.ifc
```
So now I am confused, and think that clang-tidy just can't read modmaps?
Also that "@" in the cmd line is it right?
Though I can't give cmd line ( I don't have them anymore), I managed to get the same errors with Clang and Clang-tidy on Linux It might have been: Ubuntu noble with default cmake and default Clang from the distribution, but I am not sure.
Thanks
p.s. I see this on cmake 3.28.1 and the just released 3.29https://gitlab.kitware.com/cmake/cmake/-/issues/25812Feature request: CMake presets should make the build directory2024-03-22T14:37:31-04:00Farid ZakariaFeature request: CMake presets should make the build directoryI am migrating our codebase to CMakePresets which I am enjoying however it is weird that there is now this "unified" way to specify all the CMake arguments but you still have to create the build directory.
Should CMake do the `mkdir` f...I am migrating our codebase to CMakePresets which I am enjoying however it is weird that there is now this "unified" way to specify all the CMake arguments but you still have to create the build directory.
Should CMake do the `mkdir` for us when it's using CMakePresets?https://gitlab.kitware.com/cmake/cmake/-/issues/25810FindCURL cannot find curl static library2024-03-26T09:01:09-04:00Alex OverchenkoFindCURL cannot find curl static libraryOne of the possible names for the Windows static library for CURL is `libcurl_a.lib`.
But it really tries to find only:
```
curl
# Windows MSVC prebuilts:
curllib
libcurl_imp
curllib_static
# Windows older "Win32 - MSVC" prebuilts (libc...One of the possible names for the Windows static library for CURL is `libcurl_a.lib`.
But it really tries to find only:
```
curl
# Windows MSVC prebuilts:
curllib
libcurl_imp
curllib_static
# Windows older "Win32 - MSVC" prebuilts (libcurl.lib, e.g. libcurl-7.15.5-win32-msvc.zip):
libcurl
```
Example of providing the same library is [here](https://github.com/mtconnect/cstream/blob/master/win32/curl-7.22.0/lib/libcurl_a.lib).
OS: Windows 10
CMake: 3.283.30.0https://gitlab.kitware.com/cmake/cmake/-/issues/25809try_compile() drops CMAKE_<LANG>_USING_LINKER_... vars where <LANG> has a hyp...2024-03-24T14:33:37-04:00Craig Scotttry_compile() drops CMAKE_<LANG>_USING_LINKER_... vars where <LANG> has a hyphen or underscoreThe regular expression used [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Source/cmCoreTryCompile.cxx?ref_type=tags#L1165-L1167) to decide what variables to pass to the try_compile() when `CMAKE_LINKER_TYPE` is defined is:...The regular expression used [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Source/cmCoreTryCompile.cxx?ref_type=tags#L1165-L1167) to decide what variables to pass to the try_compile() when `CMAKE_LINKER_TYPE` is defined is:
```
cmsys::RegularExpression linkerTypeDef{
"^CMAKE_[A-Za-z]+_USING_LINKER_"
};
```
This doesn't match the variables where the language is something like `ASM_NASM` or `ASM-ATT`. Underscores and hyphens need to be added to the `[...]` to allow such languages to be included.
We also have no test coverage for that particular `if()` block. It would be good to add a test to verify the expected variables do get passed down to the `try_compile()`.3.29.1Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/25808Incorrectly ordered dependency for imported target with Ninja generator2024-03-22T10:55:34-04:00ChardIncorrectly ordered dependency for imported target with Ninja generatorIf a dependency is added to an imported target then the _Ninja_ generator does not appear to wire up this dependency _before_ the dependency on the actual imported binary (`IMPORTED_LOCATION`).
This means if the binary itself depends o...If a dependency is added to an imported target then the _Ninja_ generator does not appear to wire up this dependency _before_ the dependency on the actual imported binary (`IMPORTED_LOCATION`).
This means if the binary itself depends on something then that does not get evaluated, resulting in a build failure.
There are many ways this could be caused, but the provided example reproduces the issue via a symbolic link to the imported library location.
Steps:
* Create a build (binary) dir.
* `cmake <path-to-example> -G Ninja` (configure)
* `ninja` (build)
* `rm indirection` (remove symlink)
* `ninja` (rebuild)
It can be seen in the _build.ninja_ file that the symlink dependency follows the imported library binary dependency.
The _GNU Makefiles_ generator does not have the same problem (the symlink is correctly re-created).
A workaround for the _Ninja_ generator is to wire up an extra explicit rule on the imported binary (provided in example).
[CMakeLists.txt](/uploads/869bdb619bb1ad14869c0a13c7651e64/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/25807FindMPI: Fails with CMake-3.29.0 and Intel oneAPI 2023.22024-03-26T07:43:03-04:00Changkai QiuFindMPI: Fails with CMake-3.29.0 and Intel oneAPI 2023.2This is on Windows 10 with VS 2019 community 16.11.34This is on Windows 10 with VS 2019 community 16.11.343.29.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25805cmake (1) --toolchain relative to -S path and not in cwd2024-03-22T17:19:54-04:00scivisioncmake (1) --toolchain relative to -S path and not in cwdI think this bug existed since cmake(1) --toolchain feature was added, or at least in CMake 3.26 and 3.28 on Linux and Windows.
Expected: `cmake -S <src> --toolchain <path>` is not impacted by `<src>`.
Bug: the `--toolchain <path>` is ...I think this bug existed since cmake(1) --toolchain feature was added, or at least in CMake 3.26 and 3.28 on Linux and Windows.
Expected: `cmake -S <src> --toolchain <path>` is not impacted by `<src>`.
Bug: the `--toolchain <path>` is relative to `<src>` if <path> is not absolute and not in cwd.
Specifically these argument forms of `--toolchain` fail if `-S <src>` is specified not as `.` and toolchain file is not in cwd.
```sh
cmake -S anywhere --toolchain ./a/mytool.cmake
cmake -S anywhere --toolchain a/mytool.cmake
```
## works
If I am in a cwd such that the toolchain is at `../mytool.cmake` that works:
```sh
cmake -S anywhere --toolchain ../mytool.cmake
# if that is the relative path to mytool.cmake
```
This also works
```sh
cmake -S . --toolchain a/mytool.cmake
#or
cmake --toolchain a/mytool.cmake
```https://gitlab.kitware.com/cmake/cmake/-/issues/25801ctest: modifying PATH via ENVIRONMENT property2024-03-21T09:21:59-04:00b1an b1anctest: modifying PATH via ENVIRONMENT propertycmake does not pass env to program correctly in a test case. The original report is in [VS developemnt community](https://developercommunity.visualstudio.com/t/CMake-cmake-does-not-pass-env-to-progr/10620955). Full test project is [test....cmake does not pass env to program correctly in a test case. The original report is in [VS developemnt community](https://developercommunity.visualstudio.com/t/CMake-cmake-does-not-pass-env-to-progr/10620955). Full test project is [test.zip](/uploads/f08e83e3587b6b2dcb6ca94fe9c4edc9/test.zip).https://gitlab.kitware.com/cmake/cmake/-/issues/25799Ninja: Detection of msvc_deps_prefix for clang-cl 18.12024-03-20T09:34:36-04:00Michael H.Ninja: Detection of msvc_deps_prefix for clang-cl 18.1Environment: MS Windows 11 cmake version: 3.26 - 3.28
During a build of llvm-project (version 18.1.1) using the Ninja generator and using the clang compilers (CMAKE_C_COMPILER": "clang-cl", "CMAKE_CXX_COMPILER": "clang-cl") I got the fo...Environment: MS Windows 11 cmake version: 3.26 - 3.28
During a build of llvm-project (version 18.1.1) using the Ninja generator and using the clang compilers (CMAKE_C_COMPILER": "clang-cl", "CMAKE_CXX_COMPILER": "clang-cl") I got the following error:
```
[main] Building folder: llvm-project
[build] Starting build
[proc] Executing command: ...\local\bin\cmake.EXE --build D:/temp/llvm-project/hbexbuild/x64 --parallel 32 --target install
[build] ninja: error: FindFirstFileExA(Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared): Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
[build]
[proc] The command: ...\local\bin\cmake.EXE --build D:/temp/llvm-project/hbexbuild/x64 --parallel 32 --target install exited with code: 1
[driver] Build completed: 00:00:01.174
[build] Build finished with exit code 1
```
It tracked this down to
```
...
tools/llvm-config/ExtensionDependencies.inc
tools/llvm-config/LibraryDependencies.inc
projects/openmp/runtime/src/CMakeFiles/omp.dir/libomp.rc.res: #deps 17, deps mtime 7322090345723586 (VALID)
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/sdv_driverspecs.h
Note: including file: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/includ/concurrencysal.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/driverspecs.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/winpackagefamily.h
Note: including file: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/includesal.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/SpecStrings.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/winapifamily.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/verrsrc.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/commctrl.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/dde.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/dlgs.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winnt.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winuser.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winver.h
Note: including file: D:/temp/llvm-project/openmp/runtime/src/kmp_platform.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winresrc.h
Note: including file: D:/temp/llvm-project/hbexbuild/x64/projects/openmp/runtime/src/kmp_config.h
...
```
using `ninja -t deps`.
The reason for the problem is that `msvc_deps_prefix` detection failed. The detection of the prefix is done with a regular expression inside of `Modules\CMakeDetermineCompilerId.cmake`. I found the following deficiencies with the regular expression:
1. It is not documented and not understandable without documentation
2. It is wrong and unnecessary complex (the second part of this statement is also true for the 3.29.0-rc4.
I here provide a patch against 3.28.3 which solves 1. and 2.
[fix_msvc_deps_prefix-3.28.3-new.patch](/uploads/390769b92a81a8f649eb4e3043476a00/fix_msvc_deps_prefix-3.28.3-new.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/25795Add cmake.exe to Path on Windows by default2024-03-19T14:47:47-04:00Nazar MokrynskyiAdd cmake.exe to Path on Windows by defaultOriginally reported at https://github.com/chocolatey-community/chocolatey-packages/issues/2442, but turned up to be the default upstream behavior of MSI installer.
Please consider adding `cmake.exe` to `Path` in default installation, su...Originally reported at https://github.com/chocolatey-community/chocolatey-packages/issues/2442, but turned up to be the default upstream behavior of MSI installer.
Please consider adding `cmake.exe` to `Path` in default installation, such that users can use it right away.https://gitlab.kitware.com/cmake/cmake/-/issues/25792Ninja+Fortran: Module dependency not detected from INCLUDEd file2024-03-20T09:55:55-04:00Brad KingNinja+Fortran: Module dependency not detected from INCLUDEd fileConsider this example with a module dependency inside a file included by the Fortran `INCLUDE` directive:
```console
$ cat CMakeLists.txt
cmake_minimum_required (VERSION 3.26)
project(Example Fortran)
add_executable(main main.f90 foo.f9...Consider this example with a module dependency inside a file included by the Fortran `INCLUDE` directive:
```console
$ cat CMakeLists.txt
cmake_minimum_required (VERSION 3.26)
project(Example Fortran)
add_executable(main main.f90 foo.f90)
$ cat main.f90
include "included.f90"
program main
!use foo ! uncomment to work around
call included_subroutine
end program
$ cat included.f90
subroutine included_subroutine
use foo
call foo_subroutine
end subroutine
$ cat foo.f90
module foo
contains
subroutine foo_subroutine
print *, "Hello World!"
end subroutine
end module
```
The dependency of `main.f90.o` on `foo.mod` is not discovered unless the work around is uncommented:
```console
$ ninja CMakeFiles/main.dir/main.f90.o
...
Fatal Error: Cannot open module file ‘foo.mod’ for reading at (1): No such file or directory
```3.28.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25789Makefiles: Odd behavior with rebuild_cache attached to stdout2024-03-19T03:24:42-04:00Mathieu MalaterreMakefiles: Odd behavior with rebuild_cache attached to stdoutConsider the following CMakeLists.txt:
```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
project(p)
execute_process(COMMAND ${CMAKE_COMMAND}
-P ${CMAKE_CURRENT_SOURCE_DIR}/demo.cmake
ERROR_VARIABLE my_VERSION)
message("1...Consider the following CMakeLists.txt:
```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
project(p)
execute_process(COMMAND ${CMAKE_COMMAND}
-P ${CMAKE_CURRENT_SOURCE_DIR}/demo.cmake
ERROR_VARIABLE my_VERSION)
message("1: ${my_VERSION}")
string(REPLACE "." ";" my_VERSION_LIST "${my_VERSION}")
list(GET my_VERSION_LIST 0 my_VERSION_MAJOR)
list(GET my_VERSION_LIST 1 my_VERSION_MINOR)
list(GET my_VERSION_LIST 2 my_VERSION_PATCH)
message("2: ${my_VERSION_MAJOR}")
```
where:
```
$ cat demo.cmake
set(GIT_VERSION 1.2.3)
message("${GIT_VERSION}")
```
Here is what I see from my Ubuntu system:
```
$ cmake .. && echo "-- done ---" && make rebuild_cache
1: 1.2.3
2: 1
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/demo/bin
-- done ---
Running CMake to regenerate build system...
1: 1.2.3
CMake Error at CMakeLists.txt:9 (list):
list index: 1 out of range (-1, 0)
CMake Error at CMakeLists.txt:10 (list):
list index: 2 out of range (-1, 0)
2: 1;2;3
-- Configuring incomplete, errors occurred!
See also "/tmp/demo/bin/CMakeFiles/CMakeOutput.log".
make: *** [Makefile:81: rebuild_cache] Error 1
```
However using a file output:
```
$ cmake .. && echo "-- done ---" && make rebuild_cache >& /tmp/my.log && echo "this time ok"
1: 1.2.3
2: 1
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/demo/bin
-- done ---
this time ok
```
Using:
```
$ cmake --version
cmake version 3.22.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```
and
```
$ make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
```https://gitlab.kitware.com/cmake/cmake/-/issues/25788Fortran+Ninja: add_dependencies does not make modules available since CMake 3.282024-03-19T15:11:52-04:00scivisionFortran+Ninja: add_dependencies does not make modules available since CMake 3.28As noted by https://gitlab.kitware.com/cmake/cmake/-/issues/25425#note_1496770
```sh
git clone https://github.com/Goddard-Fortran-Ecosystem/pFUnit
# for reference I was on commit 10e99ef99
cmake -Bbuild -G Ninja
cmake --build build -...As noted by https://gitlab.kitware.com/cmake/cmake/-/issues/25425#note_1496770
```sh
git clone https://github.com/Goddard-Fortran-Ecosystem/pFUnit
# for reference I was on commit 10e99ef99
cmake -Bbuild -G Ninja
cmake --build build -t funit
```
issue happens with / without `-j1` or `-t` options, even repeatedly trying to build.
This example was with macOS, CMake 3.28.3, Ninja 1.11.1, and Gfortran 13.
This target is defined in "src/funit/CMakeLists.txt" and "src/funit/asserts/CMakeLists.txt" as target "asserts" OBJECT library
```
FAILED: src/funit/CMakeFiles/funit-main.dir/FUnit.F90.o src/funit/mod/funit.mod
/opt/homebrew/bin/gfortran-13 -IpFUnit/src/funit -IpFUnit/build/src/funit/mod -IpFUnit/include -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1 -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/src/v1/mod -IpFUnit/build/extern/fArgParse/mod -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v2 -IpFUnit/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v2 -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/src/v2/mod -g -cpp -O0 -ffree-line-length-none -fallow-argument-mismatch -fbacktrace -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -Jsrc/funit/mod -fPIC -fdiagnostics-color=always -fopenmp -fpreprocessed -c src/funit/CMakeFiles/funit-main.dir/FUnit.F90-pp.f90 -o src/funit/CMakeFiles/funit-main.dir/FUnit.F90.o
pFUnit/src/funit/FUnit.F90:4:8:
4 | use PF_Assert
| 1
Fatal Error: Cannot open module file 'pf_assert.mod' for reading at (1): No such file or directory
```https://gitlab.kitware.com/cmake/cmake/-/issues/25786'ARGN' prints empty on command line console2024-03-17T17:27:06-04:00Nihal Agarwal'ARGN' prints empty on command line consoleCmake 3.22.1
For the following code:
```
set(TEMP_VAR "It is a temp varaible 1")
set(TEMP_VAR2 "It is a temp varaible 2")
function( fn_name var var2 )
message( "${var} value is = ${${var}}" )
message( "${var2} value is = ${${var2}}" )
...Cmake 3.22.1
For the following code:
```
set(TEMP_VAR "It is a temp varaible 1")
set(TEMP_VAR2 "It is a temp varaible 2")
function( fn_name var var2 )
message( "${var} value is = ${${var}}" )
message( "${var2} value is = ${${var2}}" )
message( "ARGN: ${ARGN}" ) # all variable name
message( "ARGC: ${ARGC}" )
message( "ARG0: ${ARGV0}" )
message( "ARG1: ${ARGV1}" )
endfunction()```
fn_name(TEMP_VAR TEMP_VAR2)
```
I am getting following output:
```
TEMP_VAR value is = It is a temp varaible 1
TEMP_VAR2 value is = It is a temp varaible 2
ARGN:
ARGC: 2
ARG0: TEMP_VAR
ARG1: TEMP_VAR2
```
So, the **ARGN** is printed as empty, but when I removed the parameters from the function signature, the ARGN prints the expected result.
```
set(TEMP_VAR "It is a temp varaible 1")
set(TEMP_VAR2 "It is a temp varaible 2")
function( fn_name )
message( "ARGN: ${ARGN}" ) # all variable name
message( "ARGC: ${ARGC}" )
message( "ARG0: ${ARGV0}" )
message( "ARG1: ${ARGV1}" )
endfunction()
fn_name(TEMP_VAR TEMP_VAR2)
```
Output:
```
ARGN: TEMP_VAR;TEMP_VAR2
ARGC: 2
ARG0: TEMP_VAR
ARG1: TEMP_VAR2
```
as I didn't find info from the Documentation. It looks like a bug for me.https://gitlab.kitware.com/cmake/cmake/-/issues/25785(re)running cmake with ninja and clang-cl triggers ninja error about FindFirs...2024-03-20T09:34:38-04:00risa2000(re)running cmake with ninja and clang-cl triggers ninja error about FindFirstFileExA (possible regression)It seems the problem resurfaced in Visual Studio 17.8.5 with cmake version 3.27.2-msvc1 and still remains there in VS 17.9.3 with cmake version 3.28.0-msvc1.
When having a CMake project configured with ninja generator and with clang-cl ...It seems the problem resurfaced in Visual Studio 17.8.5 with cmake version 3.27.2-msvc1 and still remains there in VS 17.9.3 with cmake version 3.28.0-msvc1.
When having a CMake project configured with ninja generator and with clang-cl as a C/C++ compiler, cmake/ninja would trigger an error:
_ninja : error : FindFirstFileExA(Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared): The filename, directory name, or volume label syntax is incorrect._
I have first reported it on VS community forum here: https://developercommunity.visualstudio.com/t/rerunning-cmake-with-ninja-and-clang-c/10567377 and with the help from MS we concluded that it is not problem in clang or visual studio, but possibly in cmake. This problem is triggered with a new clang-cl (v18 built from LLVM master branch), but not with the one currently shipped with the VS (clang-cl v16.0.5)
Code to reproduce the problem is attached to this post. In order to reproduce it you need conan package manager (1.x) installed - I am using conan 1.62.0
To execute cmake correctly on the project, you need to create the conan “install” folder first, by running the batch file conan\\conan_install_all.cmd (run this from top level project dir as prescribed here, the paths to conan profiles are hardcoded there).
Then run CMake cache generation from VS IDE the usual way. You can do this for “native” MS cl compiler and for clang-cl compiler. Once the cache for clang-cl is generated and build the first time, the subsequent builds fail with the error. The only way to continue is to delete and regenerate the cache completely.
The same build with MS cl compiler works alright.
I already tested that one needs to use conan generated toolchain file for CMake. Building it without one does not trigger the error. Also when you remove the resource file main.rc from the build, it will pass all right.
[cmake_test.zip](/uploads/44f0ffe9ab3e84e165993bdbf4fb4191/cmake_test.zip)