CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-28T15:15:57-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/23910CPack: WiX 4 support2024-03-28T15:15:57-04:00Ben BoeckelCPack: WiX 4 supportInvestigating WiX 4 in order to avoid WiX 3's lacking support of Windows longpaths (`\\?\` prefixes). However, the previews do not provide `candle` or `light`. I'm not sure what exactly replaces them as I haven't found release notes.
/c...Investigating WiX 4 in order to avoid WiX 3's lacking support of Windows longpaths (`\\?\` prefixes). However, the previews do not provide `candle` or `light`. I'm not sure what exactly replaces them as I haven't found release notes.
/cc @brad.king3.30.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23975MSVC: Finding libraries named lib${name}.a generated by meson2024-03-26T08:55:48-04:00Yonggang LuoMSVC: Finding libraries named lib${name}.a generated by mesonhttps://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa
Also add option to generate static library for MSVC like meson does.https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa
Also add option to generate static library for MSVC like meson does.3.29.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24216Windows: Problems with PATH-derived find_library search prefixes2024-03-25T15:31:09-04:00Brad KingWindows: Problems with PATH-derived find_library search prefixesSince CMake 3.3, on Windows, the `find_path`, `find_file`, and `find_library` commands compute search prefixes from the `PATH` entries of the form `$prefix/bin`.
The change was made by commit ffc06c12397e7cda7307afcfc8a79ebda4a786a6 for...Since CMake 3.3, on Windows, the `find_path`, `find_file`, and `find_library` commands compute search prefixes from the `PATH` entries of the form `$prefix/bin`.
The change was made by commit ffc06c12397e7cda7307afcfc8a79ebda4a786a6 for #15370, and was originally made for all platforms. CMake 3.6 reverted it for non-Windows platforms in commit b30b32a4931080280680aa5b439c0d4918553c56 due to finding shared libraries in undesired prefixes. However, the justification for to retain the behavior on Windows was stated in the commit message:
> The motivation was to support MSYS, MinGW and similar Windows platforms in their default environments automatically.
The idea is that on Windows one typically sets `PATH` as part of establishing specific development environments, so we might as well use that information to automatically find libraries and headers for the target environment.
Recently, !7694 taught `find_library` to search for the `libfoo.a` naming convention even for the MSVC ABI, for #23975. However, that regressed existing build environments as reported in https://gitlab.kitware.com/cmake/cmake/-/issues/23975#note_1280921 and #24168. Discussion in #24168 identified that `find_path` had already been finding MinGW headers even when using MSVC, but they previously went unused by luck because `find_library` was not finding the corresponding MinGW library prior to considering the `libfoo.a` naming convention. **The problems encountered with searching for the `libfoo.a` naming convention were not inherent, but were due to searching MinGW prefixes even when using MSVC, because they were derived from the `PATH`.**
!7962 resolved the regressions for the 3.25 series by reverting the change, but both issues' discussions identified more **general problems with searching `PATH`-derived prefixes**. They are very similar to the reasons CMake 3.6 reverted the behavior on non-Windows systems. I'm opening this issue to **propose dropping that behavior** on Windows too, and to discuss alternative ways to find MSYS and MinGW packages in their respective development environments without using `PATH` to derive search prefixes in general.3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16033WiX 4.x might require new XML namespace2024-03-24T15:25:38-04:00Kitware RobotWiX 4.x might require new XML namespaceThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16033). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16033). Further discussion may take place here.Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/25764FindPython3: add support for Python3_FIND_ABI under Windows2024-03-14T09:18:35-04:00LE GARREC VincentFindPython3: add support for Python3_FIND_ABI under WindowsDocumentation says : "So, on Windows systems, when Python3_FIND_ABI is defined, Python distributions from python.org will be found only if value for each flag is OFF or ANY."
I tried to implement a workaround because I need to have pyde...Documentation says : "So, on Windows systems, when Python3_FIND_ABI is defined, Python distributions from python.org will be found only if value for each flag is OFF or ANY."
I tried to implement a workaround because I need to have pydebug to use pybind11 in Debug mode : [Windows Python with Debug Libraries Installed causes linker error](https://github.com/pybind/pybind11/issues/3403)
List of problems I found :
- If I set `Python3_FIND_ABI(ON ANY ANY)`, `Python3_FIND_UNVERSIONED_NAMES` search `python` instead of `pythond` / `python_d`.
- `sys.abiflags` doesn't work for Windows. So don't try to read `sys.abiflags` to check if an interpreter is good. Also don't update `Python3_ABIFLAGS` when interpreter has been checked.
- `Changed in version 3.8: Default flags became an empty string (m flag for pymalloc has been removed).
` [System-specific parameters and functions](https://docs.python.org/3/library/sys.html). I didn't do any change about this change.https://gitlab.kitware.com/cmake/cmake/-/issues/25639CMake doesn't respect 8.3 short paths for source and build directory2024-02-01T09:33:54-05:00Cristian AdamCMake doesn't respect 8.3 short paths for source and build directory### Preamble
In order to have support for long paths on Windows CMake needs to support short paths first.
### Long paths support for Windows
Windows has support for long paths (>255 characters) since Windows 10 version 1607 released o...### Preamble
In order to have support for long paths on Windows CMake needs to support short paths first.
### Long paths support for Windows
Windows has support for long paths (>255 characters) since Windows 10 version 1607 released on August 2015. But the applications need to [opt-in](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later) in order to use the new functionality.
The Visual C++ compiler has been developed in the nineties and the reported [issue](https://developercommunity.visualstudio.com/t/compiler-cant-find-source-file-in-path-/10221576) is being considered but not yet fixed (Jan 2024).
Ninja build system has been [fixed](https://github.com/ninja-build/ninja/pull/2225) but the 1.12.0 release has not been made, latest release was [v1.11.1](https://github.com/ninja-build/ninja/releases/tag/v1.11.1) on Aug 30, 2022.
### Qt Applications Windows problem
At [QTCREATORBUG-26786](https://bugreports.qt.io/browse/QTCREATORBUG-26786) there is an issue compiling Qt Creator itself.
At [QTBUG-117413](https://bugreports.qt.io/browse/QTBUG-117413) there is a bug report with a broader Qt application issue.
This is an issue since user cannot compile Qt applications on Windows with the recommended Visual C++ toolchain.
### Small Hello World example
Let's say we have this `main.cpp` C++ Hello World program:
```cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello Long Path Windows World!" << endl;
return 0;
}
```
and a `CMakeLists.txt` like this:
```cmake
cmake_minimum_required(VERSION 3.5)
project(HelloWorld LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(HelloWorld main.cpp)
include(GNUInstallDirs)
install(TARGETS HelloWorld
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
)
```
These two files are located in the following path:
```plaintext
C:\Projects\ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters
```
Then I've tried the following configure command:
```plaintext
$ cmake -S HelloWorld -B build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug -GNinja -DCMAKE_BUILD_TYPE=Debug
```
This fails due to long path support missing from `cl.exe` and `ninja.exe`:
<details>
<summary>
configuration error message
</summary>
<pre>
$ cmake -S HelloWorld -B build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug -GNinja -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.38.33130/bin/Hostarm64/arm64/cl.exe
CMake Warning in C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-qo4hom/CMakeLists.txt:
The object file directory
C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-qo4hom/CMakeFiles/cmTC_87735.dir/./
has 279 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file
testCXXCompiler.cxx.obj
cannot be safely placed under this directory. The build may not work
correctly.
CMake Error:
Running
'C:/Tools/Ninja/ninja.exe' '-C' 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-qo4hom' '-t' 'recompact'
failed with:
ninja: error: loading 'build.ninja': The system cannot find the path specified.
CMake Error at C:/Program Files/CMake/share/cmake-3.28/Modules/CMakeTestCXXCompiler.cmake:49 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
C:\Projects\ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters
</pre>
</details>
### Short 8.3 paths
CMake has already instances of using 8.3 short paths for [Ninja for the C/C++ compiler path](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmNinjaTargetGenerator.cxx#L875) and for a [Visual C++ 6.0 linker issue](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmMSVC60LinkLineComputer.cxx#L31)
Aimed with this information I've had a look at how the 8.3 short paths would look like:
```plaintext
26/01/2024 13:36 <DIR> THISPA~1 ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters
Directory of C:\Projects\THISPA~1
26/01/2024 14:45 <DIR> BUILD-~1 build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug
26/01/2024 14:10 <DIR> HELLOW~1 HelloWorld
```
My expectation was that if I provide short 8.3 names CMake would simply work:
```
$ cmake -S c:\Projects\THISPA~1\HELLOW~1 -B c:\projects\THISPA~1\BUILD-~1 -GNinja -DCMAKE_BUILD_TYPE=Debug
```
<details>
<summary>
configuration error message
</summary>
<pre>
$ cmake -S c:\Projects\THISPA~1\HELLOW~1 -B c:\projects\THISPA~1\BUILD-~1 -GNinja -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.38.33130/bin/Hostarm64/arm64/cl.exe
CMake Warning in C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-obxgga/CMakeLists.txt:
The object file directory
C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-obxgga/CMakeFiles/cmTC_e312f.dir/./
has 279 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file
testCXXCompiler.cxx.obj
cannot be safely placed under this directory. The build may not work
correctly.
CMake Error:
Running
'C:/Tools/Ninja/ninja.exe' '-C' 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-obxgga' '-t' 'recompact'
failed with:
ninja: error: loading 'build.ninja': The system cannot find the path specified.
CMake Error at C:/Program Files/CMake/share/cmake-3.28/Modules/CMakeTestCXXCompiler.cmake:49 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
</pre>
</details>
### Short 8.3 path 'simulation'
Then I decided to move the long path directory somewhere else and create the short paths explicitly (created `THISPA~1`, `HELLOW~1` and `BUILD-~1`)
The configuration worked as expected:
```plaintext
C:\Projects\THISPA~1
$ cmake -S c:\Projects\THISPA~1\HELLOW~1 -B c:\projects\THISPA~1\BUILD-~1 -GNinja -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is MSVC 19.38.33134.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.38.33130/bin/Hostarm64/arm64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.9s)
-- Generating done (0.0s)
-- Build files have been written to: C:/Projects/THISPA~1/BUILD-~1
```
Then I've copied the content of the short build directory into the long directory and swapped back the long path directory.
Building worked as expected since all paths are short paths:
```plaintext
C:\Projects\THISPA~1
$ cmake --build BUILD-~1 --verbose
Change Dir: 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug'
Run Build Command(s): C:/Tools/Ninja/ninja.exe -v
[1/2] C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1438~1.331\bin\HOSTAR~1\arm64\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 -std:c++17 /showIncludes /FoCMakeFiles\HelloWorld.dir\main.cpp.obj /FdCMakeFiles\HelloWorld.dir\ /FS -c C:\Projects\THISPA~1\HELLOW~1\main.cpp
[2/2] C:\Windows\system32\cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\HelloWorld.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\arm64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\arm64\mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1438~1.331\bin\HOSTAR~1\arm64\link.exe /nologo CMakeFiles\HelloWorld.dir\main.cpp.obj /out:HelloWorld.exe /implib:HelloWorld.lib /pdb:HelloWorld.pdb /version:0.0 /machine:ARM64 /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 ."
C:\Projects\THISPA~1
$ cmake --build BUILD-~1 --verbose
Change Dir: 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug'
Run Build Command(s): C:/Tools/Ninja/ninja.exe -v
ninja: no work to do.
C:\Projects\THISPA~1
$ build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug\HelloWorld.exe
Hello Long Path Windows World!
```
### Conclusion
If CMake would support short 8.3 paths it would also support long paths and help A LOT of Windows users that complain about this.
Tools like Qt Creator would then give the 8.3 paths for the `-S` and `-B` parameters and the CMake would just do its job! :smile:
### Note
Also posted [on discourse](https://discourse.cmake.org/t/9941).https://gitlab.kitware.com/cmake/cmake/-/issues/20751Clang CUDA on Windows doesn't build without manual flags and standard paths2024-01-23T14:56:25-05:00Corentin SchreiberClang CUDA on Windows doesn't build without manual flags and standard pathsI have just tried to use CMake 3.17.20200520-g81e8f62 and clang to compile a CUDA project we normally build with nvcc. I bumped into a few issues:
- [x] ~~CMake seems to ignore the ``CMAKE_CUDA_COMPILER_WORKS`` option, so the compiler c...I have just tried to use CMake 3.17.20200520-g81e8f62 and clang to compile a CUDA project we normally build with nvcc. I bumped into a few issues:
- [x] ~~CMake seems to ignore the ``CMAKE_CUDA_COMPILER_WORKS`` option, so the compiler check is always performed.~~ This is [intended](https://gitlab.kitware.com/cmake/cmake/-/issues/20751#note_764869).
- [x] ~~At least during the compiler test, CMake does not seem to forward the ``CMAKE_CUDA_ARCHITECTURES`` values to clang, I have to set it manually using ``CMAKE_CUDA_FLAGS=--cuda-gpu-arch=XXX``. Otherwise it tries to compile for ``sm_20``, which apparently my CUDA installation (CUDA 10.1) doesn't support.~~ This was because ``cuda-path`` wasn't set, see below.
- [x] ~~Related to the above, I don't know how to make CMake compile for multiple GPU architectures at once. ``CMAKE_CUDA_ARCHITECTURES`` can contain an array of architectures (since nvcc can compile for multiple architectures at once), but since clang can only compile for one architecture at a time with ``--cuda-gpu-arch``, I cannot build multiple architectures with the trick above.~~ Trick no longer required.
- [x] CMake does not seem to forward the path to the CUDA runtime to clang, I have to set it manually using ``CMAKE_CUDA_FLAGS=--cuda-path=XXX``.
- [x] When linking the test program, the clang linker cannot find the CUDA lib files because the linker include path is set to just ``<CUDA_PATH>/lib`` (which is empty) instead of ``<CUDA_PATH>/lib/x64`` (which contains the 64bit lib files). I copied the lib files manually into the ``lib`` folder.
After that last step, CMake decided the compiler was working.
Then I went on to compile our project, a shared library, in ``CMAKE_BUILD_TYPE=RelWithDebInfo``. Generator is MinGW Makefiles. Compilation went fine, however at link time there were inconsistencies in the runtime libraries being used. CXX files correctly used ``MD_DynamicRelease``, but CU files used ``MT_StaticRelease``. This can be seen below.
With ``VERBOSE=1``, ``mingw32-make`` reports the following CXX compiler command being used:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE <CUSTOM_PREPROCESSOR> <CUSTOM_INCLUDE_PATHS> -O2 -g -DNDEBUG -Xclang -gcodeview -D_DLL -D_MT -Xclang --dependent-lib=msvcrt <CUSTOM_COMPILER_OPTS> -o <OUTPUT_FILE> -c <CXX_FILE>
```
and the following CU compiler command:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE <CUSTOM_PREPROCESSOR> <CUSTOM_INCLUDE_PATHS> --cuda-gpu-arch=sm_30 --cuda-path=C:/mingw/cuda --cuda-gpu-arch=sm_30 <CUSTOM_COMPILER_OPTS> -std=gnu++14 -x cuda -c <CUDA_FILE> -o <OUTPUT_FILE>
```
and for the linker:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -O2 -g -DNDEBUG -Xclang -gcodeview -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -shared -o <OUTPUT_DLL> -Xlinker /implib:<LIBRARY>.lib -Xlinker /pdb:<LIBRARY>.pdb -Xlinker /version:0.0 <OBJECTS> <LINK_LIBS>
```
Notice how ``-D_DLL -D_MT`` are missing for the CU compilation command, but also other important compilation flags, like ``-O2 -g``. Notice also how there are now two ``--cuda-gpu-arch=sm_30``; I guess one of them is the one I added manually in ``CMAKE_CUDA_FLAGS`` (to make the compiler test pass) and the other was added by CMake somehow.https://gitlab.kitware.com/cmake/cmake/-/issues/17412Can't execute Windows batch built-in commands with forward slashes on paths2023-12-31T18:13:26-05:00Francesco PrettoCan't execute Windows batch built-in commands with forward slashes on pathsOperating system: Windows 10 64bit, Version 1709 (Build 16299.19)
CMake: 3.9.4
Batch built-in commands are not supported in CMake `execute_process` directive. This is unfortunate since there are some useful commands like `mklink` that a...Operating system: Windows 10 64bit, Version 1709 (Build 16299.19)
CMake: 3.9.4
Batch built-in commands are not supported in CMake `execute_process` directive. This is unfortunate since there are some useful commands like `mklink` that are not available as executables. The trick to make them callable in cmake is to prefix them with batch calling `cmd /C command`. Also batch evaluation seems to prevent evaluating paths with forward slashes, unless they are quoted. So for example:
```
>cmd /c dir C:/
Invalid switch - "".
```
The command will work correctly only with the path quoted:
```
>cmd /c dir "C:/"
Volume in drive C has no label.
Volume Serial Number is A2C9-35E5
Directory of C:\
[..]
```
Now, if I try to execute the same command with CMake putting it in a `script.cmake`:
```
set(builtin "dir \"C:/\"")
message("cmd /c ${builtin}")
execute_process(COMMAND cmd /c "${builtin}")
```
I get:
```
>cmake -P script.cmake
cmd /c dir "C:/"
The filename, directory name, or volume label syntax is incorrect.
```
If I remove the escaped quotes I get the same error as regular batch evaluation:
```
>cmake -P script.cmake
cmd /c dir C:/
Invalid switch - "".
```
Other tries still won't allow me to call the builtin command in CMake with paths with forward slashes.https://gitlab.kitware.com/cmake/cmake/-/issues/254733.28.0-rc6: execute_process now finds extension-less commands in PATH on Windows2023-12-05T09:21:19-05:00Brad King3.28.0-rc6: execute_process now finds extension-less commands in PATH on WindowsThe fix in !9017 for #25450 broke
```cmake
execute_process(COMMAND cmd ...)
```
on Windows in a MSYS2 environment. The problem is that an extension-less `cmd` tool is in the `PATH`, but it is a shell script with a shebang line, and we...The fix in !9017 for #25450 broke
```cmake
execute_process(COMMAND cmd ...)
```
on Windows in a MSYS2 environment. The problem is that an extension-less `cmd` tool is in the `PATH`, but it is a shell script with a shebang line, and we cannot run it from a native Windows calling process.
I've also posted this information in upstream [libuv PR 4241](https://github.com/libuv/libuv/pull/4241#pullrequestreview-1763163945), which !9017 backported.3.28.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/254503.28.0-rc5: execute_process no longer supports executables without any extension2023-12-04T14:58:35-05:00Alexander Neumann3.28.0-rc5: execute_process no longer supports executables without any extensionvcpkg CI run with 3.28-rc5 still shows regressions:
https://github.com/microsoft/vcpkg/pull/35326
I am mostly concerned about the ryu build failure since this seems to be related to a subtle change how `execute_process` treats directori...vcpkg CI run with 3.28-rc5 still shows regressions:
https://github.com/microsoft/vcpkg/pull/35326
I am mostly concerned about the ryu build failure since this seems to be related to a subtle change how `execute_process` treats directories or similar.
The command is:
```
"E:/vcpkg_folders/new_master/installed/x64-windows-release/tools/bazel
--batch build --cpu=x64_windows --conlyopt=-nologo --conlyopt=-DWIN32
--conlyopt=-D_WINDOWS --conlyopt=-W3 --conlyopt=-utf-8 --conlyopt=-MP
--conlyopt=-MD --conlyopt=-O2 --conlyopt=-Oi --conlyopt=-Gy
--conlyopt=-DNDEBUG --conlyopt=-Z7 --linkopt=-machine:x64 --linkopt=-nologo
--linkopt=-DEBUG --linkopt=-INCREMENTAL:NO --linkopt=-OPT:REF
--linkopt=-OPT:ICF --verbose_failures --strategy=CppCompile=standalone
//ryu //ryu:ryu_printf"
```
The error is:
`no such file or directory`
Using CMake 3.27.1 the port simply builds3.28.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/25431CMake 3.28: Project using C++20 modules fails to build when using Ninja (/Mul...2023-11-20T08:00:47-05:00ZingamCMake 3.28: Project using C++20 modules fails to build when using Ninja (/MultiConfig) generator on WindowsThe attached sample project uses C++20 presets on Windows. I am using the latest Visual Studio 2022 Preview to build the project.
The project has a few CMake presets Ninja, Ninja-MultiConfig and Visual Studio 17 2022
If I use the built-i...The attached sample project uses C++20 presets on Windows. I am using the latest Visual Studio 2022 Preview to build the project.
The project has a few CMake presets Ninja, Ninja-MultiConfig and Visual Studio 17 2022
If I use the built-in CMake 3.27 + Ninja generator or a Visual 2022 the project builds. If I use an external CMake 3.28 + Ninja the project fails to build. Visual Studio Code + the respective extensions yield the same result.
The output when "Ninja (MSVC)" CMake presets is selected:
```
>------ Rebuild All started: Project: RToolBoxTest, Configuration: default.ninja.msvc ------
[1/1] Cleaning all built files...
Cleaning... 0 files.
[1/11] Scanning X:\GitHub\RToolBoxTest\RToolBox\modules\RToolBox.cppm for CXX dependencies
RToolBox.cppm
[2/11] Scanning X:\GitHub\RToolBoxTest\RToolBox\modules\System\Window.cppm for CXX dependencies
Window.cppm
[3/11] Building RC object examples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\__\Resources\Windows\SampleGame.rc.res
[4/11] Generating CXX dyndep file CMakeFiles\RToolBox.dir\CXX.dd
[5/11] Building CXX object examples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\src\main.cpp.obj
FAILED: examples/SimpleGameMain/CMakeFiles/SimpleGameMain.dir/src/main.cpp.obj
"C:\PROGRA~1\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.39.33218\bin\Hostx64\x64\cl.exe" /nologo /TP -DNOATOM -DNOCLIPBOARD -DNOCOMM -DNOCTLMGR -DNODEFERWINDOWPOS -DNODRAWTEXT -DNOGDICAPMASKS -DNOHELP -DNOICONS -DNOKANJI -DNOKERNEL -DNOKEYSTATES -DNOMCX -DNOMEMMGR -DNOMENUS -DNOMETAFILE -DNOMINMAX -DNONLS -DNOOPENFILE -DNOPROFILER -DNORASTEROPS -DNOSCROLL -DNOSERVICE -DNOSOUND -DNOSYSCOMMANDS -DNOSYSMETRICS -DNOTEXTMETRIC -DNOWH -DNOWINOFFSETS -DOEMRESOURCE -DSTRICT -DUNICODE -DWIN32_LEAN_AND_MEAN -D_UNICODE -IX:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\.. /DWIN32 /D_WINDOWS /EHsc /Ob0 /Od /RTC1 -std:c++latest -MDd -Zi /JMC /showIncludes /Foexamples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\src\main.cpp.obj /Fdexamples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\ /FS -c X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(6): error C2230: could not find module 'rmm.RToolBox'
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(10): error C3083: 'rmm': the symbol to the left of a '::' must be a type
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(10): error C2039: 'rtoolbox': is not a member of '`global namespace''
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(10): error C2878: 'rtoolbox': a namespace or class of this name does not exist
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2653: 'rt': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2065: 'Window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2146: syntax error: missing ';' before identifier 'window'
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2065: 'window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2653: 'rt': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2065: 'Description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(19): error C2065: 'window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(21): error C2065: 'window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(22): error C2065: 'window': undeclared identifier
[6/11] Building CXX object CMakeFiles\RToolBox.dir\modules\System\Platforms\Window_Windows.cpp.obj
FAILED: CMakeFiles/RToolBox.dir/modules/System/Platforms/Window_Windows.cpp.obj
"C:\PROGRA~1\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.39.33218\bin\Hostx64\x64\cl.exe" /nologo /TP -DNOATOM -DNOCLIPBOARD -DNOCOMM -DNOCTLMGR -DNODEFERWINDOWPOS -DNODRAWTEXT -DNOGDICAPMASKS -DNOHELP -DNOICONS -DNOKANJI -DNOKERNEL -DNOKEYSTATES -DNOMCX -DNOMEMMGR -DNOMENUS -DNOMETAFILE -DNOMINMAX -DNONLS -DNOOPENFILE -DNOPROFILER -DNORASTEROPS -DNOSCROLL -DNOSERVICE -DNOSOUND -DNOSYSCOMMANDS -DNOSYSMETRICS -DNOTEXTMETRIC -DNOWH -DNOWINOFFSETS -DOEMRESOURCE -DSTRICT -DUNICODE -DWIN32_LEAN_AND_MEAN -D_UNICODE /DWIN32 /D_WINDOWS /EHsc /Ob0 /Od /RTC1 -std:c++latest -MDd -Zi /JMC /showIncludes /FoCMakeFiles\RToolBox.dir\modules\System\Platforms\Window_Windows.cpp.obj /FdCMakeFiles\RToolBox.dir\RToolBox.pdb /FS -c X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(10): error C2230: could not find module 'rmm.RToolBox'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(15): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(18): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(18): error C2061: syntax error: identifier 'Description'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(29): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(29): error C2061: syntax error: identifier 'ResourceID'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(42): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(42): error C3646: 'description': unknown override specifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(42): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(45): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(46): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(45): error C7550: 'rmm::rtoolbox::Implementation::{ctor}': the qualified name in this context names a constructor, not a type
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(46): error C2065: 'Description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(46): error C2065: 'description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(47): error C2062: type 'void' unexpected
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(48): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(49): error C2059: syntax error: '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(49): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(49): error C2447: '{': missing function header (old-style formal list?)
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(66): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(75): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(81): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(88): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(112): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2761: 'void rmm::rtoolbox::Implementation::SetIcon(void) noexcept const': redeclaration of member is not allowed
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2065: 'ResourceID': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2146: syntax error: missing ')' before identifier 'icon'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(119): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(119): error C2447: '{': missing function header (old-style formal list?)
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(127): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(154): error C3536: 'titleStr': cannot be used before it is initialized
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(161): error C2660: 'CreateWindowExW': function does not take 10 arguments
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winuser.h(4437): note: see declaration of 'CreateWindowExW'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(161): note: while trying to match the argument list '(int, long, int, int, int, int, nullptr, nullptr, HMODULE, nullptr)'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(179): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2065: 'Description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2062: type 'void' unexpected
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(5): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(5): error C2065: 'data': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(6): error C2059: syntax error: '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(6): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(6): error C2447: '{': missing function header (old-style formal list?)
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): warning C4508: 'rmm::rtoolbox::{dtor}': function should return a value; 'void' return type assumed
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(12): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(12): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(12): error C2270: 'Hide': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(18): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(18): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(18): error C2270: 'Show': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(24): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(24): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(24): error C2270: 'Run': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(30): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(30): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(30): error C2270: 'GetHandle': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2182: 'SetIcon': this use of 'void' is not valid
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2065: 'ResourceID': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2146: syntax error: missing ')' before identifier 'icon'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(37): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(37): error C2447: '{': missing function header (old-style formal list?)
[7/11] Building CXX object CMakeFiles\RToolBox.dir\modules\System\Window.cppm.obj
Window.cppm
[8/11] Building CXX object libraries\RTMain\CMakeFiles\RToolBox-main.dir\src\RTMain.cpp.obj
ninja: build stopped: subcommand failed.
Rebuild All failed.
```
This is the output when using CMake presets "MSBuild (MSVC)"
```
>------ Rebuild All started: Project: RToolBoxTest, Configuration: default.msbuild.msvc ------
MSBuild version 17.9.0-preview-23551-05+34ae4f308 for .NET Framework
MSBuild version 17.9.0-preview-23551-05+34ae4f308 for .NET Framework
1>Checking Build System
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/CMakeLists.txt
Scanning sources for module dependencies...
RToolBox.cppm
Window.cppm
Compiling...
Window.cppm
RToolBox.cppm
Window_Windows.cpp
RToolBox.vcxproj -> X:\GitHub\RToolBoxTest\build\default.msbuild.msvc\Debug\RToolBox.lib
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/libraries/RTMain/CMakeLists.txt
RTMain.cpp
RToolBox-main.vcxproj -> X:\GitHub\RToolBoxTest\build\default.msbuild.msvc\libraries\RTMain\RToolBox-main.dir\Debug\RToolBox-main.lib
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/examples/SimpleGameMain/CMakeLists.txt
main.cpp
SimpleGameMain.vcxproj -> X:\GitHub\RToolBoxTest\build\default.msbuild.msvc\examples\SimpleGameMain\Debug\SimpleGameMain.exe
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/CMakeLists.txt
Rebuild All succeeded.
```https://gitlab.kitware.com/cmake/cmake/-/issues/25355cmcldeps regression: rc compilation fails2023-10-24T08:40:12-04:00Ben Boeckelcmcldeps regression: rc compilation failsThere's a report [on `vcpkg`](https://github.com/microsoft/vcpkg/issues/34597) related to compiling `zlib` where !8665 caused a regression in `cmcldeps`. More investigation necessary.
This was also discussed [on discourse](https://disco...There's a report [on `vcpkg`](https://github.com/microsoft/vcpkg/issues/34597) related to compiling `zlib` where !8665 caused a regression in `cmcldeps`. More investigation necessary.
This was also discussed [on discourse](https://discourse.cmake.org/t/9230).
Cc: @kyle.edwards @brad.king3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24235Clang on Windows does not show color diagnostics unless -fansi-escape-codes i...2023-10-23T12:06:38-04:00Alvin WongClang on Windows does not show color diagnostics unless -fansi-escape-codes is addedOn Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes...On Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes` to the C/CXX flags. I tested two different scenarios:
- Windows console (cmd.exe) + ninja + [llvm-mingw](https://github.com/mstorsjo/llvm-mingw)
- GitHub Actions Windows runner + mingw32-make + llvm-mingw
I am not sure if this counts as a CMake issue or Clang's, but Clang always uses the Windows console API by default unless -fansi-escape-codes is given, and I guess it doesn't have direct access to the Windows console when run under make or ninja.https://gitlab.kitware.com/cmake/cmake/-/issues/19108MSVC: Add abstraction for runtime library selection2023-09-07T07:12:57-04:00Brad KingMSVC: Add abstraction for runtime library selectionCMake currently [hard codes](https://gitlab.kitware.com/cmake/cmake/blob/v3.14.1/Modules/Platform/Windows-MSVC.cmake#L361-364) defaults for `/MD` and `/MDd`. There is a [FAQ entry](https://gitlab.kitware.com/cmake/community/wikis/FAQ#ho...CMake currently [hard codes](https://gitlab.kitware.com/cmake/cmake/blob/v3.14.1/Modules/Platform/Windows-MSVC.cmake#L361-364) defaults for `/MD` and `/MDd`. There is a [FAQ entry](https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-build-my-msvc-application-with-a-static-runtime) on how to change them but the process is not simple and requires knowing CMake's existing default. That means we cannot even change our default from `/MD` to `-MD` without a policy.
Instead we should introduce a first-class abstraction for choosing the MSVC runtime library via an enumeration. We've long hesitated to do this because the idea of "runtime library selection" touches on related concepts on several platforms. We can avoid that scope creep by simply defining an abstraction that applies *only when targeting the MSVC ABI on Windows* (regardless of what compiler is being used).
3.15.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/13939NSIS installer doesn't honor standard user permission2023-09-06T11:19:10-04:00Kitware RobotNSIS installer doesn't honor standard user permissionThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13939). Further discussion may take place here.
---
When installing an NSIS package generated by CMake as a standard user, the insta...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13939). Further discussion may take place here.
---
When installing an NSIS package generated by CMake as a standard user, the installer tries to install the program into the "all users" location, which fails because of permissions. It should install into the user's directory.
The bug seems to have been introduced while fixing #12923 (commit c4a0bcea775981dea86d527f66161c98f5e05e95). Whereas the first correction from +3 to +4 was correct to enable the recognition of power users, the second change
```patch
- StrCmp $1 "Power" 0 +3
+ StrCmp $1 "Power" 0 +4
```
is wrong. It will jump to `StrCpy $SV_ALLUSERS "AllUsers"` instead of `Goto done` for a standard user. This change should be reverted.3.28.0https://gitlab.kitware.com/cmake/cmake/-/issues/23305Clang/Windows: Race when using `cmake -E vs_link_exe` with llvm-mt2023-08-17T10:26:12-04:00Haowei WuClang/Windows: Race when using `cmake -E vs_link_exe` with llvm-mtI am debugging a weird llvm test failures in our builder which popped up a few month ago, which is caused by the fact that an executable generated during llvm's cmake configuration step could not be executed, so the tests won't get the c...I am debugging a weird llvm test failures in our builder which popped up a few month ago, which is caused by the fact that an executable generated during llvm's cmake configuration step could not be executed, so the tests won't get the correct error string on Windows. An example test failure can seen [https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8832262407257821617/overview](https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8832262407257821617/overview) after cmake switched to llvm-mt by default in patch [https://github.com/Kitware/CMake/commit/b12aec6c8daa3e087e6d0fa0441f59622251eb46](https://github.com/Kitware/CMake/commit/b12aec6c8daa3e087e6d0fa0441f59622251eb46). At first I thought it was a llvm-mt.exe bug. But after I managed to generate a minimal reproducer, it seems to be an issue with cmake's vs_link_exe feature.
How to reproduce the issue:
* Install Visual Studio, make sure Windows SDK 10 is also installed (I tested both VS2019 and VS2022, the free community version is OK).
* Build Clang/LLVM for windows (or you can use the [one](https://chrome-infra-packages.appspot.com/p/fuchsia/third_party/clang/windows-amd64/+/integration) built from our builders. You might have to manually symlink `clang-cl.exe`, `clang++.exe` to `clang.exe` and `lld-link.exe` to `lld.exe` as some ZIP program does not process symlinks on windows correctly)
* Build CMake (or use the prebuilt from [https://cmake.org/download/](https://cmake.org/download/), I used `cmake-3.23.0-rc2-windows-x86_64.zip`)
* Download the reproducer `llvm-mt-reproduce.zip` from this ticket and extract it.
* Assuming clang-cl.exe is placed under `C:\src\clang\windows-amd64\bin` and cmake.exe is placed under `C:\src\cmake-3.23.0-rc2-windows-x86_64\bin`, open `x64 Native Tools Command Prompt for VS` from the start menu.
* Navigate to the directory that contains the extracted files from the reproducer package, run:
```
C:\src\llvm-mt-reproduce>run-with-cmake.bat
...
C:\src\llvm-mt-reproduce>out\getErrc.exe
Access is denied.
C:\src\llvm-mt-reproduce>
```
The `getErrc.exe` is a program generated during llvm's cmake configuration step to extract the correct error message string for llvm's unit tests. When this step fails, all error message related unit test will fail, causing the test failures we saw on our builders. The content of the batch file used in the reproducer package is listed as follow:
```
SETLOCAL
set CLANG_CL_PATH=C:\src\clang\windows-amd64\bin\clang-cl.exe
set CMAKE_PATH=C:\src\cmake-3.23.0-rc2-windows-x86_64\bin\cmake.exe
set MT_PATH=C:\src\clang\windows-amd64\bin\llvm-mt.exe
::set MT_PATH="C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\mt.exe"
set RC_PATH="C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe"
::set RC_PATH=C:\src\clang\windows-amd64\bin\llvm-rc.exe
set LINKER_PATH=C:\src\clang\windows-amd64\bin\lld-link.exe
%CLANG_CL_PATH% /nologo -TP /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /Brepro /bigobj /W4 -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation /Gw -no-canonical-prefixes /MDd /Zi /Ob0 /Od /RTC1 -std:c++14 /showIncludes /Foout\getErrc.cpp.obj /Fdout\ -c -- .\getErrc.cpp
%CMAKE_PATH% -E vs_link_exe --intdir=out --rc=%RC_PATH% --mt=%MT_PATH% --manifests -- %LINKER_PATH% /nologo out\getErrc.cpp.obj /out:out\getErrc.exe /implib:out\getErrc.lib /pdb:out\getErrc.pdb /version:0.0 /machine:x64 /STACK:10000000 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
```
You can change the paths in `run-with-cmake.bat` file if your paths does not match mine.
On my machine, the `getErrc.exe` generated from cmake's vs_link step cannot be executed and will always result in "this app cannot run on your PC" error and "Access is denied" will be printed to the cmd. How ever, if you run `run-with-cmake.bat` again (to be precise, to run the `cmake -E vs_link_exe ...` from the batch file), the `out\getErrc.exe` generated by the 2nd run will work without any issues:
```
C:\src\llvm-mt-reproduce> C:\src\cmake-3.23.0-rc2-windows-x86_64\bin\cmake.exe -E vs_link_exe --intdir=out --rc="C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe" --mt=C:\src\clang\windows-amd64\bin\llvm-mt.exe --manifests -- C:\src\clang\windows-amd64\bin\lld-link.exe /nologo out\getErrc.cpp.obj /out:out\getErrc.exe /implib:out\getErrc.lib /pdb:out\getErrc.pdb /version:0.0 /machine:x64 /STACK:10000000 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
C:\src\llvm-mt-reproduce>out\getErrc.exe
no such file or directory;is a directory;invalid argument;permission denied
C:\src\llvm-mt-reproduce>
```
So it make me suspect that there might be an data race issue here. When the `cmake -E vs_link_exe ...` was invoked the first time, an incomplete manifest file that was still being written might have been present to the linker and embedded to the final getErrc.exe, causing the error messages we saw. When running the command twice, the manifest file were already correctly generated, so this time the executable has the correct manifest file embedded. If this is the case, I think this is a bug on cmake side and should be fixed.
A few other observations:
1. When I add `--trace` flag to the `cmake -E vs_link_exe ...` (so final command line looks like ) to get the command traces, the original successful cmake invocation will result in error with messages:
```
Running with trace output on.
CMake Warning:
Ignoring extra path from command line:
"advapi32.lib"
CMake Error: Unknown argument --
CMake Error: Run 'cmake --help' for all supported options.
```
Is it a cmake flag parser bug? I have to use Windows audit mode to record the command line flags in order to debug this failure.
2. The feature currently implemented by llvm-mt is very limited (only `/manifest` and `/out` flags are implemented, others are not) compared to the original `mt.exe` provided by Windows MSVC. Is it too early for cmake to set llvm-mt by default on Windows? Can we switch it back to the `mt.exe`?
[llvm-mt-reproduce.zip](/uploads/69d0304ac7ee24a2db6502f1eb480820/llvm-mt-reproduce.zip)3.21.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16713Setting CMAKE_SYSTEM_VERSION is confusing (for Windows 10 SDK selection)2023-04-06T09:13:35-04:00Maik RiechertSetting CMAKE_SYSTEM_VERSION is confusing (for Windows 10 SDK selection)In #15670 support was added for setting the "Windows target platform version" in the VS2015 generator.
The first thing I tried was `set( CMAKE_SYSTEM_VERSION 10.0.10586.0)` within the CMakeLists file, which didn't have any effect. I the...In #15670 support was added for setting the "Windows target platform version" in the VS2015 generator.
The first thing I tried was `set( CMAKE_SYSTEM_VERSION 10.0.10586.0)` within the CMakeLists file, which didn't have any effect. I then tried it on the command line via `-DCMAKE...` which worked. Since command line arguments are cache variables I thought I'd try `set( CMAKE_SYSTEM_VERSION 10.0.10586.0 CACHE INTERNAL "")` within CMakeLists but that didn't work. Now, this whole process took quite long and it was hard to debug, especially since there was only sparse documentation related to choosing the "Windows target platform version" in cmake.
I still don't know if my approach with the command line argument is the right one. I would be happy about advice but also to use this issue for tracking any improvements to documentation regarding this feature.3.27.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24657CUDA/NVCC/Windows/Ninja: CUDA architecture flags break in response files2023-03-31T08:05:14-04:00LucasCUDA/NVCC/Windows/Ninja: CUDA architecture flags break in response filesHi,
I use CMake to compile CUDA accelerated code. I set the CUDA architectures according to the docs as
```
#...
set(CMAKE_CUDA_ARCHITECTURES 50 52 60 61 70 75 80 86)
#...
```
However on Windows nvcc throws the following error:
```
[1...Hi,
I use CMake to compile CUDA accelerated code. I set the CUDA architectures according to the docs as
```
#...
set(CMAKE_CUDA_ARCHITECTURES 50 52 60 61 70 75 80 86)
#...
```
However on Windows nvcc throws the following error:
```
[1/7] Building CUDA object CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj
FAILED: CMakeFiles/spline_psf_cu_impl.dir/src/spline_psf_gpu.cu.obj
C:\PROGRA~1\NVIDIA~2\CUDA\v11.7\bin\nvcc.exe -forward-unknown-to-host-compiler --options-file CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj.rsp -MD -MT CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj -MF CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj.d -x cu -rdc=true -c %SRC_DIR%\cpp_cuda_c\src\spline_psf_gpu.cu -o CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj -Xcompiler=-FdCMakeFiles\spline_psf_cu_impl.dir\spline_psf_cu_impl.pdb,-FS
nvcc fatal : 'sm_52' is not in 'keyword=value' format
```
I believe this should be a CMake bug, no? The build on linux works fine.
You can take a look at the GH Action log
- [3_build__windows-2022__windows__powershell_.txt](/uploads/3d170ecc2bf43c393a1583d75adb7c1f/3_build__windows-2022__windows__powershell_.txt)
- [1_build__ubuntu-22.04__ubuntu__bash_-l__0__.txt](/uploads/979c4bd65cc96515e872095d2c2ff2c5/1_build__ubuntu-22.04__ubuntu__bash_-l__0__.txt)
or reproduce it with a fork of this
https://github.com/Haydnspass/SplinePSF/commit/0326f76e492b9aa54c8ff0088764da843d047257
Interestingly the status badge is still green even if the build fails.
PS: CMake also seems not too handle to long lines on windows, that's why I have to set https://github.com/Haydnspass/SplinePSF/blob/0326f76e492b9aa54c8ff0088764da843d047257/cpp_cuda_c/CMakeLists.txt#L73.27.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24622Dependencies for windows resource (.rc) files are not detected correctly2023-03-21T11:19:36-04:00Andrzej SzombierskiDependencies for windows resource (.rc) files are not detected correctlyCMake (at least with the Ninja back-end) scans only for #include-style dependencies in .rc files. When a binary file (such as an application icon) is compiled into a .res file, the build system doesn't know this, and doesn't regenerate t...CMake (at least with the Ninja back-end) scans only for #include-style dependencies in .rc files. When a binary file (such as an application icon) is compiled into a .res file, the build system doesn't know this, and doesn't regenerate the resource file when the dependency is updated.
Trivial example below:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.10)
project(example)
add_executable(example example.c example.rc)
```
example.c
```
int main(){return 0;}
```
example.rc
```
1 ICON DISCARDABLE "example.ico"
```
example.ico - use any icon file
How to reproduce:
```
$ cmake -G Ninja ..
[...]
-- Build files have been written to: C:/Users/ld/resourcebug/build
ld@w10vm VC ~/resourcebug/build
$ ninja
[1/3] Building C object CMakeFiles\example.dir\example.c.obj
[2/3] Building RC object CMakeFiles\example.dir\example.rc.res
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation. All rights reserved.
[3/3] Linking C executable example.exe
ld@w10vm VC ~/resourcebug/build
$ touch ../example.ico
ld@w10vm VC ~/resourcebug/build
$ ninja
ninja: no work to do.
```
Expected result: the executable is rebuilt with the updated iconhttps://gitlab.kitware.com/cmake/cmake/-/issues/24611Clang 16 on Windows for C++20 modules2023-03-21T08:58:47-04:00huangqinjinClang 16 on Windows for C++20 modules### Information
- CMake: 3.26.0
- Ninja: 1.11.0
- Clang: 16.0.0
- OS: Windows 10
Tests a simple program at https://github.com/huangqinjin/cxxmodules/tree/master/named-module.
### Issue 1
```
C:/Program Files/LLVM/bin/clang-scan-deps.ex...### Information
- CMake: 3.26.0
- Ninja: 1.11.0
- Clang: 16.0.0
- OS: Windows 10
Tests a simple program at https://github.com/huangqinjin/cxxmodules/tree/master/named-module.
### Issue 1
```
C:/Program Files/LLVM/bin/clang-scan-deps.exe -format=p1689 -- C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -O0 -std=gnu++20 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -x c++ C:/Users/huangqinjin/Projects/cxxmodules/named-module/hello.cppm -c -o named-module\CMakeFiles\named-module.dir\hello.cppm.obj -MT named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi -MD -MF named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi.d > named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi
error: no such file or directory: '>'
error: no such file or directory: 'named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi'
```
The stdout redirection cannot be used here.
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.0/Modules/Compiler/Clang-CXX.cmake#L42
### Issue 2 (After bypass issue 1)
Generated a strange BMI file `named-moduleCMakeFilesnamed-module.dirhello.pcm` in cmake binary dir.
The conetent of the response file `named-module\CMakeFiles\named-module.dir\hello.cppm.obj.modmap` is
```
-x c++-module
-fmodule-output=named-module\CMakeFiles\named-module.dir\hello.pcm
```
Seems to me that clang does not support back slash.
### Issue 3
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -O0 -std=gnu++20 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -MD -MT named-module/CMakeFiles/named-module.dir/main.cpp.obj -MF named-module\CMakeFiles\named-module.dir\main.cpp.obj.d @named-module\CMakeFiles\named-module.dir\main.cpp.obj.modmap -o named-module/CMakeFiles/named-module.dir/main.cpp.obj -c C:/Users/huangqinjin/Projects/cxxmodules/named-module/main.cpp
C:/Users/huangqinjin/Projects/cxxmodules/named-module/main.cpp:1:8: fatal error: module 'hello' not found
```
After investigation, clang C++20 module only supports `-std=c++20`, `-std=gnu++20` is not supported currently. So
`set(CMAKE_CXX_EXTENSIONS OFF)` is required.3.26.1Brad KingBrad King