CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-09-22T14:30:56-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/23988Ninja: UTF-8 response files without BOM lead to build errors2022-09-22T14:30:56-04:00Sjard Ole KrügerNinja: UTF-8 response files without BOM lead to build errorsThe attached [example](/uploads/aae1fab9f65a06ee5528d0094e9a402d/test.zip) fails with Cmake 3.24.0, Ninja 1.11.0 and MSVC 2019 on a Windows 10 machine (sorry for the cluttered file structure, long paths was the only way I found to force ...The attached [example](/uploads/aae1fab9f65a06ee5528d0094e9a402d/test.zip) fails with Cmake 3.24.0, Ninja 1.11.0 and MSVC 2019 on a Windows 10 machine (sorry for the cluttered file structure, long paths was the only way I found to force cmake/ninja to generate a linker response file).
`LINK : fatal error LNK1181: cannot open input file 'in order to2\force cmake to\generate an rsp file\we will need\a very long path in order\to exceed the cli\argument length limit and\add some umlauts like\äöü\CMakeFiles\object.dir\addition\add_char.cpp.obj'
ninja: build stopped: subcommand failed.`
The problem seems to be closely related to #21792. If I add the BOM manually to **@CMakeFiles\component.rsp**, the linker statement is successful.https://gitlab.kitware.com/cmake/cmake/-/issues/23978Ninja: Optionally use powershell scripts instead of batch files for long cust...2022-09-20T13:03:08-04:00Nicholas PatellaNinja: Optionally use powershell scripts instead of batch files for long custom commandsHi, I'm using the latest CMake and ninja on Windows.
I notice that when a custom command is longer than 8192 characters, rather than be written directly to the build.ninja file, it's written to a .bat file.
I'm experiencing an issue wi...Hi, I'm using the latest CMake and ninja on Windows.
I notice that when a custom command is longer than 8192 characters, rather than be written directly to the build.ninja file, it's written to a .bat file.
I'm experiencing an issue with .bat files on a particular version of Windows that I am not sure if Microsoft will fix expediently (see Motivation).
It would be nice to have an option to be able to change the behavior of long commands to write to a PS script instead of a .bat script.
Since my arguments have generator expressions, I can't use file(WRITE).
For now, my solution is to write a PS script incrementally using multiple COMMANDs, and then finally calling that PS script, but it isn't ideal.
If CMake could support alternate ways to invoke long commands out of the box, it would be helpful.
<details><summary>Motivation</summary>
When working with add_custom_command and add_custom_target, CMake writes commands that would exceed the command line limit to a .bat file.
However, on Windows Server 2016, when executing a .bat file that contains a command longer 8192, while no error is thrown, the 8192th character is deleted from the command arguments during .bat execution, and the invoked program receives corrupt arguments. In CMake + ninja builds, the consequence is that when passing a long list of files to a custom command, one of the arguments or file paths will become corrupt.
A simple way to see this is to write:
`powershell.exe -Command "& { echo 123456789123456789 }" > output.txt`
to a .bat file, and modify the string echoed ("123456789123456789") to be longer than 8192 characters.
If you run this, you will see that output.txt is missing a character from what should have been echoed.
This issue only happens on Windows Server 2016 (I haven't tried 2019) and does not happen on the latest Windows 10 Pro.
Issue tracking on Microsoft's Feedback Hub (upvote would be appreciated):
https://aka.ms/AAi2pi7
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/23882Set WINDOWS variable when running on a Windows target2022-09-07T16:04:35-04:00Cristian AdamSet WINDOWS variable when running on a Windows targetCurrently we have the `WIN32` variable for Windows, and the 32 suffix is a bit misleading for the users running on Windows x86_64 or Windows Arm64.
I have seen the documentation of [WIN32](https://cmake.org/cmake/help/latest/variable/WI...Currently we have the `WIN32` variable for Windows, and the 32 suffix is a bit misleading for the users running on Windows x86_64 or Windows Arm64.
I have seen the documentation of [WIN32](https://cmake.org/cmake/help/latest/variable/WIN32.html):
> Set to True when the target system is Windows, including Win64.
Currently there are other Windows variables set:
* WINCE
* WINDOWS_PHONE
* WINDOWS_STORE
I think the `WINDOWS` variable fits better than `WIN32`.https://gitlab.kitware.com/cmake/cmake/-/issues/23773Clang/Windows: vs_link_exe produces incorrect binary2022-12-12T18:07:54-05:00Michael SchmidtClang/Windows: vs_link_exe produces incorrect binaryI have the following setup:
OS: Windows 10
Arch: x86_64
Windows SDK: 10.0.19041.0 (Visual Studio 16 2019 toolchain only install)
MS Visual Studio: None
Additional LLVM Installation: 14.0.6
CMake: 3.20.3 and 3.21.1 (edit:) as ...I have the following setup:
OS: Windows 10
Arch: x86_64
Windows SDK: 10.0.19041.0 (Visual Studio 16 2019 toolchain only install)
MS Visual Studio: None
Additional LLVM Installation: 14.0.6
CMake: 3.20.3 and 3.21.1 (edit:) as well as 3.23.2 and 3.24.0-rc4
When I build a project with source coverage like the attached [sample project](/uploads/89f3959e7c4953a944cbf4d76103356b/CMakeLists.txt) with code [foo.cc](/uploads/1d5773206c6b41d8287ded8a88a2c973/foo.cc)
```
"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64
cmake .. -G Ninja -DCMAKE_CXX_COMPILER:FILEPATH="C:\Program Files\LLVM\bin\clang-cl.exe"
ninja
```
and run the resulting executable `foo.exe` the created profile file `default.profraw` is of format version 0x05 (second 64bit integer in the file) and cannot be processed with the installed tools of the LLVM installation which expect version 0x08 of the file format.
If I replace the linker rule command in CMakeFiles\rules.ninja
`cmd.exe /C "$PRE_LINK && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=$OBJECT_DIR --rc=C:\PROGRA~1\LLVM\bin\llvm-rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\mt.exe --manifests $MANIFESTS -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo $in /out:$TARGET_FILE /implib:$TARGET_IMPLIB /pdb:$TARGET_PDB /version:0.0 $LINK_FLAGS $LINK_PATH $LINK_LIBRARIES && $POST_BUILD"`
with the corresponding clang-cl.exe call
` command = cmd.exe /C "$PRE_LINK && "C:\Program Files\LLVM\bin\clang-cl.exe" /nologo $in /o $TARGET_FILE /INCREMENTAL -fprofile-instr-generate -fcoverage-mapping /link /implib:$TARGET_IMPLIB /pdb:$TARGET_PDB /version:0.0 $LINK_FLAGS $LINK_PATH $LINK_LIBRARIES && $POST_BUILD"
`
the correct file format is generated.
*Suspicion:*
The following is just a guess because cmake -E vs_link_exe is not documented and does not support --trace or --debug-output options.
-E vs_link_exe somehow links against the much older `C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\lib\x64\clang_rt.profile-x86_64.lib` and not `C:\Program Files\LLVM\lib\clang\14.0.6\lib\windows\clang_rt.profile-x86_64.lib`which would be correct for the toolchain, as `C:\PROGRA~1\LLVM\bin\clang-cl.exe` is used for compilation.https://gitlab.kitware.com/cmake/cmake/-/issues/23475How to handle DLL-only dependencies correctly on Windows2022-11-18T18:50:25-05:00Naiyang LinHow to handle DLL-only dependencies correctly on WindowsWe could not use target_link_libraries() with MODULE library or IMPORTED SHARED library without IMPORTED_IMPLIB. And we could not handle recursive dependency tracking of DLL's or full dependency analysis of a target.
There are some sim...We could not use target_link_libraries() with MODULE library or IMPORTED SHARED library without IMPORTED_IMPLIB. And we could not handle recursive dependency tracking of DLL's or full dependency analysis of a target.
There are some similiar topics:
- https://gitlab.kitware.com/cmake/cmake/-/issues/22195
- https://gitlab.kitware.com/cmake/cmake/-/issues/20448
- https://gitlab.kitware.com/cmake/cmake/-/issues/18400
- https://gitlab.kitware.com/cmake/cmake/-/issues/22993
- https://discourse.cmake.org/t/module-library-and-copying-target-runtime-dlls/5488https://gitlab.kitware.com/cmake/cmake/-/issues/23366IPO,Intel,Fortran: Static libraries generated with no longer link correctly.2022-03-30T10:43:29-04:00Andy VincentIPO,Intel,Fortran: Static libraries generated with no longer link correctly.- CMake: 3.22.3
- Ninja: 1.10.2
- Intel: 18.0.5.274
- MSVC: 2017
This is an issue I've just experienced whilst upgrading our CMake from 3.14.4 to 3.22.3, when using Ninja (unsure if this affects any other generators).
We have some proj...- CMake: 3.22.3
- Ninja: 1.10.2
- Intel: 18.0.5.274
- MSVC: 2017
This is an issue I've just experienced whilst upgrading our CMake from 3.14.4 to 3.22.3, when using Ninja (unsure if this affects any other generators).
We have some projects where various static libraries are compiled (with IPO turned on), which are then linked to a shared library containing other static-libraries or C/CXX code.
It seems that in CMake 3.21.1, a change was made, and the 'lib' tool from MSVC is used, instead of Intel's 'xilib' tool when linking the static library, which then causes an issue when linking the final shared library.
I've attached a small reproducer, which contains:
* A Fortran generated static library (with 1 subroutine)
* A shared library that contains C code, which links to the above. This also contains an export '.def' file, to export the Fortran subroutine.
The CMakeLists.txt encapsulates all of this. When the build occurs, the following is produced:
```
[1/2] Linking Fortran static library fortran_code.lib
f_code.f.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[2/2] Linking C shared library test_lib.dll
FAILED: test_lib.dll test_lib.lib
cmd.exe /C "cd . && C:\BuildTools\cmake-3.22.3-windows-x86_64\bin\cmake.exe -E vs_link_dll --intdir=CMakeFiles\test_lib.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2017\PROFES~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo CMakeFiles\test_lib.dir\c_code.c.obj /out:test_lib.dll /implib:test_lib.lib /pdb:test_lib.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /DEF:C:\workspaces\temp\fortran-static-lib-bug\exports.def /DEF:..\exports.def fortran_code.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\PROGRA~2\MICROS~2\2017\PROFES~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo CMakeFiles\test_lib.dir\c_code.c.obj /out:test_lib.dll /implib:test_lib.lib /pdb:test_lib.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /DEF:C:\workspaces\temp\fortran-static-lib-bug\exports.def /DEF:..\exports.def fortran_code.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\test_lib.dir/intermediate.manifest CMakeFiles\test_lib.dir/manifest.res" failed (exit code 1120) with the following output:
exports.def : error LNK2001: unresolved external symbol vmake_name_
test_lib.lib : fatal error LNK1120: 1 unresolved externals
ninja: build stopped: subcommand failed.
```
I've left some commented code in the CMakeLists.txt, which re-enables the use of 'xilib' via the 'CMAKE_Fortran_CREATE_STATIC_LIBRARY' variable. When this is uncommented, everything works as expected (and you can use 'dumpbin /EXPORTS' to see that all the functions are exported as expected).
[fortran-static-lib-bug.zip](/uploads/869207d9b2b252edd91e368635ddc314/fortran-static-lib-bug.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/23257Windows: -E create_symlink and security limitations2022-08-02T02:48:04-04:00Serg Kryvonosserg.kryvonos@qt.ioWindows: -E create_symlink and security limitationsUpdate the approach added by !2144 to use junctions, as suggested [here](https://superuser.com/a/1291446/140450).Update the approach added by !2144 to use junctions, as suggested [here](https://superuser.com/a/1291446/140450).https://gitlab.kitware.com/cmake/cmake/-/issues/23244MinGW: Honoring .manifest sources2022-08-15T12:23:29-04:00Brad KingMinGW: Honoring .manifest sourcesWith MSVC we link `.exe` and `.dll` files using special `cmake -E vs_link_exe` and `cmake -E vs_link_dll` helpers to embed `.manifest` sources by compiling them as a resource. Something similar may be needed on MinGW. This will need a ...With MSVC we link `.exe` and `.dll` files using special `cmake -E vs_link_exe` and `cmake -E vs_link_dll` helpers to embed `.manifest` sources by compiling them as a resource. Something similar may be needed on MinGW. This will need a policy to avoid colliding with projects that manually handle it with their own `.rc` files.https://gitlab.kitware.com/cmake/cmake/-/issues/23241FindOpenMP: Using libiomp5md.dll2022-02-20T03:28:07-05:00terrylyonsFindOpenMP: Using libiomp5md.dllIn a project with multiple components using openmp protocol, it is essential that they all use the same dll to provide the service. The mkl component links to the intel module libiomp5md.dll which does the job and is a drop in replacemen...In a project with multiple components using openmp protocol, it is essential that they all use the same dll to provide the service. The mkl component links to the intel module libiomp5md.dll which does the job and is a drop in replacement for the Microsoft version. FindLapack identifies the version shipped in the visual studio folder tree. The issue is that there seems no way to direct FindOpenMP to do the same. Components which rely on find_package OpenMP introduce a dependency to libomp.dll that results in unusable builds.
This is the issue: how to direct find_package(OpenMP) to use/inherit a particular (external) choice of link library and link library path consistently. Setting the obvious variables in the cache does not seem to have an effect.
This is a breaking issue for me.https://gitlab.kitware.com/cmake/cmake/-/issues/23014Windows: Directory rename sometimes fails2021-12-14T09:38:52-05:00Shimon DoodkinWindows: Directory rename sometimes failswhen using Vcpkg on WSL in Windows when installing large packages like boost that maybe takes long time for antivirus to scan or for os to notice the folder, the rename fails. with file access error
maybe this issue is related.
https:...when using Vcpkg on WSL in Windows when installing large packages like boost that maybe takes long time for antivirus to scan or for os to notice the folder, the rename fails. with file access error
maybe this issue is related.
https://gitlab.kitware.com/cmake/cmake/-/issues/19580
- I already had installed vcpkg in c:\vcpkg. (worked with it on windows)
- then I installed wsl2 on windows and installed ubuntu
- i installed build-essentials on ubuntu
- went to /mnt/c/vcpkg
- and recompiled vcpkg for linux with vcpkg\bootstrap-vcpkg.sh
- then i ran /mnt/c/vcpkg/vcpkg install boost
- and had many errors of on rename of folder freshly extracted from a zip file.
the error is
https://github.com/microsoft/vcpkg/issues/12204https://gitlab.kitware.com/cmake/cmake/-/issues/22918COMPILE_DEFINITIONS: Definition values with percent signs on Windows2021-11-16T12:00:42-05:00Jörg BornemannCOMPILE_DEFINITIONS: Definition values with percent signs on WindowsConsider a target with compile definitions like this
```
target_compile_definitions(myapp PRIVATE
TESTCASE_BUILDDIR="${CMAKE_BINARY_DIR}/foo%2bar"))
```
This works fine on Linux, but on Windows there will be errors. For example, MSVC’...Consider a target with compile definitions like this
```
target_compile_definitions(myapp PRIVATE
TESTCASE_BUILDDIR="${CMAKE_BINARY_DIR}/foo%2bar"))
```
This works fine on Linux, but on Windows there will be errors. For example, MSVC’s cl.exe yields “cl : Command line error D8038 : invalid argument”.
According to MS docs at https://docs.microsoft.com/en-us/cpp/build/reference/d-preprocessor-definitions?view=msvc-160#remarks percent sign should be written as doubled percent sign when passing it to the compiler with -D.
Given that `target_compile_definitions` already does some escaping, it should probably also take care of doubling the percent sign on Windows.
Discourse link: https://discourse.cmake.org/t/percent-signs-in-target-compile-definitions-on-windows/4489https://gitlab.kitware.com/cmake/cmake/-/issues/22899MSVC PDB generation strategies2022-10-26T09:51:34-04:00Ben BoeckelMSVC PDB generation strategiesIn !6721, I tried to improve CI by using flags that work with `sccache`. However, [CMake uses an incompatible strategy for PDB files](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6721#note_1082123) in that it uses a per-librar...In !6721, I tried to improve CI by using flags that work with `sccache`. However, [CMake uses an incompatible strategy for PDB files](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6721#note_1082123) in that it uses a per-library `.pdb` file rather than per-TU files which just doesn't work with any (simple) caching mechanism. I propose a per-target property which can be used to select the PDB strategy for the target (names subject to bikeshedding):
```cmake
set(CMAKE_PDB_STRATEGY PER_TU) # defaults to PER_TARGET for compat
set(CMAKE_PDB_LEVEL NONE) # or DEFAULT or EDIT_AND_CONTINUE
# also CMAKE_PDB_LEVEL_<CONFIG> with sensible defaults per config
```
AFAICT, `EDIT_AND_CONTINUE` is not compatible with `PER_TU` since it requires `/ZI` which is incompatible with `sccache` (fine for CI which doesn't need `EDIT_AND_CONTINUE` anyways).
Things to consider:
- See CMP0091 for how to move the existing flags out of the global settings into these target properties
- Behaviors with MSVC-emulating compilers (`clang-cl`)?
- Gathering per-TU `.pdb` files into a final target-wide `.pdb` file (related: how do `OBJECT` libraries do this?).
- Could/should `PDB_LEVEL` be shared at some level with other compilers (`-g`, `-ggdb`, `-Og`, etc.)?
- Can `PDB_STRATEGY` also encompass `-gsplit-dwarf`?
- What to do if the strategy doesn't support the level? Downgrade the strategy, level, or error?
See also:
- #10189 (`/Zi` vs `/ZI` for Debug builds)
- #19549 (using `/Z` at all for Release builds)
- #20256 (separate debug info, generally)
- #16874 (NatVis support)
- #20812 (default flag selection for MSVC)
Cc: @brad.king @craig.scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/22668clang-cl: Use new value "ClangCl" for CMAKE_<LANG>_COMPILER_ID2023-11-17T07:07:17-05:00Deniz Bahadirclang-cl: Use new value "ClangCl" for CMAKE_<LANG>_COMPILER_IDWith the introduction of `clang-cl` on Windows (conditionally) setting compiler-options in CMake became more difficult.
While `clang` accepts traditional Clang/GCC options, `clang-cl` is a frontend which accepts MSVC options but no lon...With the introduction of `clang-cl` on Windows (conditionally) setting compiler-options in CMake became more difficult.
While `clang` accepts traditional Clang/GCC options, `clang-cl` is a frontend which accepts MSVC options but no longer directly accepts traditional Clang/GCC options.
Now, one not only has to check the `CMAKE_<LANG>_COMPILER_ID` variable but additionally `CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT`. (See: #22666)
Even worse, CMake-code that originally worked perfectly fine on different operating systems with different compilers now fails on Windows because it can no longer differentiate between `clang` and `clang-cl`. This is particularly true when using the generator-expression `$<COMPILE_LANG_AND_ID:...>` or `$<CXX_COMPILER_ID:...>` etc. (See: #22432)
---
I therefore suggest to introduce a new value for `CMAKE_<LANG>_COMPILER_ID` called "`ClangCl`" (similar to "`AppleClang`") which shall be used when `clang-cl` is used, to simply differentiate between `clang` and `clang-cl`.
Of course, that should also work with the associated generator-expressions.https://gitlab.kitware.com/cmake/cmake/-/issues/22667Clang: Detection of frontent-variant versus --driver-mode2021-09-22T10:46:24-04:00Deniz BahadirClang: Detection of frontent-variant versus --driver-modeThe detection of Clang's frontent-variant, the logic that calculates `CMAKE_<LANG>_COMPILER_FRONTENT_VARIANT`, is not working reliable in all situations.
On Windows it seems to work when using just `clang` (respective `clang++`) or `cla...The detection of Clang's frontent-variant, the logic that calculates `CMAKE_<LANG>_COMPILER_FRONTENT_VARIANT`, is not working reliable in all situations.
On Windows it seems to work when using just `clang` (respective `clang++`) or `clang-cl` for `CMAKE_C_COMPILER` and `CMAKE_CXX_COMPILER`.
But when also using Clang's `--driver-mode` option the detection fails (or succeeds out of sheer luck).
---
For example when using the following `CMakeLists.txt` file:
```cmake
cmake_minimum_required(VERSION 3.19...3.21)
project( DetectCompiler
VERSION 1.0.0
LANGUAGES C CXX
)
message(STATUS "CMAKE_C_COMPILER_ID = ${CMAKE_C_COMPILER_ID}")
message(STATUS "CMAKE_C_SIMULATE_ID = ${CMAKE_C_SIMULATE_ID}")
message(STATUS "CMAKE_C_COMPILER FRONTEND_VARIANT = ${CMAKE_C_COMPILER_FRONTEND_VARIANT}")
message(STATUS "CMAKE_CXX_COMPILER_ID = ${CMAKE_CXX_COMPILER_ID}")
message(STATUS "CMAKE_CXX_SIMULATE_ID = ${CMAKE_CXX_SIMULATE_ID}")
message(STATUS "CMAKE_CXX_COMPILER FRONTEND_VARIANT = ${CMAKE_CXX_COMPILER_FRONTEND_VARIANT}")
```
It fails for `clang --driver-mode=cl` / `clang++ --driver-mode=cl`:
```
cmake -G "Ninja" -DCMAKE_C_COMPILER=clang;--driver-mode=cl -DCMAKE_CXX_COMPILER=clang++;--driver-mode=cl ../source
-- The C compiler identification is Clang 12.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 12.0.0 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe - broken
CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler
"C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/dbahadir/cmake-tests/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/PROGRA~2/MICROS~2/2019/PROFES~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe cmTC_d60bd && [1/2] Building C object CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj
C:\PROGRA~2\MICROS~2\2019\PROFES~1\VC\Tools\Llvm\x64\bin\clang.exe --driver-mode=cl -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -MD -MT CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj -MF CMakeFiles\cmTC_d60bd.dir\testCCompiler.c.obj.d -o CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj -c testCCompiler.c
clang: warning: unknown argument ignored in clang-cl: '-g' [-Wunknown-argument]
clang: warning: unknown argument ignored in clang-cl: '-MF' [-Wunknown-argument]
clang: error: no such file or directory: 'CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj'
clang: error: no such file or directory: 'CMakeFiles\cmTC_d60bd.dir\testCCompiler.c.obj.d'
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
See also "C:/Users/dbahadir/cmake-tests/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/dbahadir/cmake-tests/build/CMakeFiles/CMakeError.log".
```
---
For completeness, it succeeds (out of sheer luck) for `clang --driver-mode=gcc` / `clang++ --driver-mode=g++`:
```
cmake -G "Ninja" -DCMAKE_C_COMPILER=clang;--driver-mode=gcc -DCMAKE_CXX_COMPILER=clang++;--driver-mode=g++ ../compiler-detection-tests/
-- The C compiler identification is Clang 12.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 12.0.0 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
-- CMAKE_C_COMPILER_ID = Clang
-- CMAKE_C_SIMULATE_ID = MSVC
-- CMAKE_C_COMPILER FRONTEND_VARIANT = GNU
-- CMAKE_CXX_COMPILER_ID = Clang
-- CMAKE_CXX_SIMULATE_ID = MSVC
-- CMAKE_CXX_COMPILER FRONTEND_VARIANT = GNU
-- Configuring done
-- Generating done
```https://gitlab.kitware.com/cmake/cmake/-/issues/22551file(GET_RUNTIME_DEPENDENCIES...) misses dependencies on Windows if paths don...2021-09-14T02:15:25-04:00Dave Efile(GET_RUNTIME_DEPENDENCIES...) misses dependencies on Windows if paths don't start with a drive letter and contain forward slashesWhen paths on Windows don't include a drive letter, GET_RUNTIME_DEPENDENCIES can miss some dependencies.
Steps to reproduce:
* Save this basic script file to disk - [GetRuntimeDependencies.cmake](/uploads/ee93d07b52a1a1c4440d7c5f7ead93c...When paths on Windows don't include a drive letter, GET_RUNTIME_DEPENDENCIES can miss some dependencies.
Steps to reproduce:
* Save this basic script file to disk - [GetRuntimeDependencies.cmake](/uploads/ee93d07b52a1a1c4440d7c5f7ead93cc/GetRuntimeDependencies.cmake)
* Get a DLL with dependencies to query (I happen to be using boost iostreams)
* Run the script
Expected result:
* Unresolved dependencies are listed (in my case libbz2 and zlib)
Actual result:
* No unresolved dependencies are listed
Example:
```
cmake -D LIBRARIES=/Users/Dave/boost/bin/boost_iostreams-mt.dll -P GetRuntimeDependencies.cmake
-- Resolved runtime dependencies:
-- Unresolved runtime dependencies:
cmake -D LIBRARIES=\Users\Dave\boost\bin\boost_iostreams-mt.dll -P GetRuntimeDependencies.cmake
-- Resolved runtime dependencies:
-- Unresolved runtime dependencies: libbz2.dll;zlib.dll
cmake -D LIBRARIES=C:/Users/Dave/boost/bin/boost_iostreams-mt.dll -P GetRuntimeDependencies.cmake
-- Resolved runtime dependencies:
-- Unresolved runtime dependencies: libbz2.dll;zlib.dll
cmake -D LIBRARIES=C:\Users\Dave\boost\bin\boost_iostreams-mt.dll -P GetRuntimeDependencies.cmake
-- Resolved runtime dependencies:
-- Unresolved runtime dependencies: libbz2.dll;zlib.dll
```
The above was the minimum I could find to reproduce it. There are similar issues if the DIRECTORIES paths have no drive prefix and start with forward slashes.
I've had a dig through the code, though I'm not familiar with it and got a bit lost quite quickly.
I'm using dumpbin, but I don't think it's relevant.https://gitlab.kitware.com/cmake/cmake/-/issues/22465ClangCL: Add support for system includes2021-07-24T19:42:42-04:00Gregor JasnyClangCL: Add support for system includesHello,
I'm testing ClangCL (from VS2022 preview 2) and noticed that it does not support system includes. I was able to hack-in support by adding the following two lines to my `CMakeLists.txt`:
```cmake
set(CMAKE_INCLUDE_SYSTEM_FLAG_C "...Hello,
I'm testing ClangCL (from VS2022 preview 2) and noticed that it does not support system includes. I was able to hack-in support by adding the following two lines to my `CMakeLists.txt`:
```cmake
set(CMAKE_INCLUDE_SYSTEM_FLAG_C "-Xclang -isystem -Xclang ")
set(CMAKE_INCLUDE_SYSTEM_FLAG_CXX "-Xclang -isystem -Xclang ")
```
Would you please consider adding similar functionality to the proper CMake Platform modules?
Thanks,
Gregorhttps://gitlab.kitware.com/cmake/cmake/-/issues/22450message: color output on Windows2021-07-21T11:33:46-04:00Brad Kingmessage: color output on Windows!6105 added `message()` color by message type, resolving #16183. However, it was reverted on Windows by !6369 due to #22444, and especially https://gitlab.kitware.com/cmake/cmake/-/issues/22444#note_987530. A new approach will be neede...!6105 added `message()` color by message type, resolving #16183. However, it was reverted on Windows by !6369 due to #22444, and especially https://gitlab.kitware.com/cmake/cmake/-/issues/22444#note_987530. A new approach will be needed to print color output on Windows while also preserving LF newlines and console encoding conversion.https://gitlab.kitware.com/cmake/cmake/-/issues/22442generate_export_header in project with C and CXX languages always goes CXX2021-07-19T22:18:31-04:00Samuel Marksgenerate_export_header in project with C and CXX languages always goes CXXI have a project with C and CXX.
```cmake
project(pp VERSION 0.0.0 LANGUAGES C CXX)
```
I'm careful to make all the headers .h and fully C compatible (with `` and all). Even guarding them with:
```c
#ifdef __cplusplus
extern "C" {
#endi...I have a project with C and CXX.
```cmake
project(pp VERSION 0.0.0 LANGUAGES C CXX)
```
I'm careful to make all the headers .h and fully C compatible (with `` and all). Even guarding them with:
```c
#ifdef __cplusplus
extern "C" {
#endif
```
But the newly C-compatible [`generate_export_header`](https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html) always generates CXX headers even when the target has this explicitly:
```cmake
set_target_properties("${LIBRARY_NAME}" PROPERTIES LINKER_LANGUAGE C)
```
Only just realised that my linker issues [MSVC only: undefined extern] are from an incorrectly generated export header.
For now I'll commit a generated header to version-control and use that on MSVC, but if you could fix this on CMake's end that would be great. Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/22441CPack/NSIS: "Invalid escape sequence \P" Windows paths2021-07-26T11:01:05-04:00Samuel MarksCPack/NSIS: "Invalid escape sequence \P" Windows pathsGiven `-DMYINSTALLPATH="C:\Program Files\foo"` then I get an error above invalid escape sequences at CPackConfig.cmake:33. So I:
`file(TO_CMAKE_PATH ${MYINSTALLPATH} MYINSTALLPATH)`
Then in NSIS64 generator (CPack) it doesn't let me pre...Given `-DMYINSTALLPATH="C:\Program Files\foo"` then I get an error above invalid escape sequences at CPackConfig.cmake:33. So I:
`file(TO_CMAKE_PATH ${MYINSTALLPATH} MYINSTALLPATH)`
Then in NSIS64 generator (CPack) it doesn't let me press "Next" because the slashes are in the wrong direction. So I:
`string(REPLACE "/" "\\" MYINSTALLPATH "${MYINSTALLPATH}")`; which brings me back to the original error. I'm running 3.21.0 (with that minimum version required).
EDIT: This worked. But I'm guessing it's not the right solution
```cmake
if (WIN32)
string(REPLACE "/" "\\\\" MYINSTALLPATH "${MYINSTALLPATH}")
endif()
```https://gitlab.kitware.com/cmake/cmake/-/issues/22236clang-cl 7.0.0 invalid option '/notify_update'2021-05-25T09:41:16-04:00emptyVoidclang-cl 7.0.0 invalid option '/notify_update'Here's the output:
```
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- The CXX compiler identification is Clang 7.0.0 wi...Here's the output:
```
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- The CXX compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - failed
[cmake] -- Check for working C compiler: C:/Program Files (x86)/something/something/clang-cl.exe
[cmake] -- Check for working C compiler: C:/Program Files (x86)/something/something/clang-cl.exe - broken
[cmake] CMake Error at C:/Program Files/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
[cmake] The C compiler
[cmake]
[cmake] "C:/Program Files (x86)/something/something/clang-cl.exe"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: D:/Projects/test/build/CMakeFiles/CMakeTmp
[cmake]
[cmake] Run Build Command(s):C:/PROGRA~2/something/Ninja/ninja.exe cmTC_8c4ed && [1/2] Building C object CMakeFiles\cmTC_8c4ed.dir\testCCompiler.c.obj
[cmake] [2/2] Linking C executable cmTC_8c4ed.exe
[cmake] FAILED: cmTC_8c4ed.exe
[cmake] cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_8c4ed.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\rc.exe --mt=C:\PROGRA~2\something\LLVM\bin\llvm-mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2017\BUILDT~1\VC\Tools\MSVC\1416~1.270\bin\Hostx86\x86\link.exe /nologo CMakeFiles\cmTC_8c4ed.dir\testCCompiler.c.obj /out:cmTC_8c4ed.exe /implib:cmTC_8c4ed.lib /pdb:cmTC_8c4ed.pdb /version:0.0 /machine:X86 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
[cmake] MT: command "C:\PROGRA~2\something\LLVM\bin\llvm-mt.exe /nologo /manifest CMakeFiles\cmTC_8c4ed.dir/intermediate.manifest /out:CMakeFiles\cmTC_8c4ed.dir/embed.manifest /notify_update" failed (exit code 0x1) with the following output:
[cmake] llvm-mt: error: invalid option '/notify_update'
[cmake] ninja: build stopped: subcommand failed.
```