CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-06-04T08:33:18-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/19298swift linker flags are propagated improperly for mixed language projects on W...2019-06-04T08:33:18-04:00Saleem Abdulrasoolswift linker flags are propagated improperly for mixed language projects on WindowsTrying to port libdispatch to the new Swift support, I noticed that the following causes problems on Windows:
```cmake
cmake_minimum_required(VERSION 3.14.20190523)
project(P LANGUAGES C CXX Swift)
```
The C/C++ checks for the linker a...Trying to port libdispatch to the new Swift support, I noticed that the following causes problems on Windows:
```cmake
cmake_minimum_required(VERSION 3.14.20190523)
project(P LANGUAGES C CXX Swift)
```
The C/C++ checks for the linker add `/MACHINE:x64` to the linker flags which propagate to the Swift check and cause issues.https://gitlab.kitware.com/cmake/cmake/-/issues/16439Add support for Clang targeting MSVC ABI but with GNU-like command line2019-05-29T09:22:17-04:00Ernst MaurerAdd support for Clang targeting MSVC ABI but with GNU-like command linetried to replace MinGW compiler in the project by specifying clang ones:
> cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=C:/dev/tools/LLVM/bin/clang.exe -DCMAKE_CXX_COMPILER=C:/dev/tools/LLVM/bin/clang++.exe -G "CodeBlocks - M...tried to replace MinGW compiler in the project by specifying clang ones:
> cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=C:/dev/tools/LLVM/bin/clang.exe -DCMAKE_CXX_COMPILER=C:/dev/tools/LLVM/bin/clang++.exe -G "CodeBlocks - MinGW Makefiles" C:\Users\amigo421\ClionProjects\hr2
however , cmake tries to use incorrect flags for clang:
> clang.exe /nologo /DWIN32 /D_WINDOWS /W3 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /FoCMakeFiles\cmTC_f50b2.dir\testCCompiler.c.obj /FdCMakeFiles\cmTC_f50b2.dir/ -c C:\Users\amigo421\ClionProjects\hr2\cmake-build-debug\CMakeFiles\CMakeTmp\testCCompiler.c
you see - cmake uses compiler flags from VC toolchain instead of expected GCC one
is it a bug or can be solved by using some additional settings?https://gitlab.kitware.com/cmake/cmake/-/issues/19203Improve LLVM for Visual Studio compiler detection2019-05-03T11:43:55-04:00Zufu LiuImprove LLVM for Visual Studio compiler detectionI maintained a non-official repository contains LLVM MSBuild script for Visual Studio 2010 to 2019 at https://github.com/zufuliu/llvm-utils
The toolset names are LLVM_v90, LLVM_v100, LLVM_v110, LLVM_v110_xp, LLVM_v120, LLVM_v120_xp, etc ...I maintained a non-official repository contains LLVM MSBuild script for Visual Studio 2010 to 2019 at https://github.com/zufuliu/llvm-utils
The toolset names are LLVM_v90, LLVM_v100, LLVM_v110, LLVM_v110_xp, LLVM_v120, LLVM_v120_xp, etc (set repository readme). All toolset name suffix are in lower case (`_v[0-9]+(_xp)?`).
Currently when running cmake like `cmake -Bbuild -H. -A x64 -T LLVM_v142`, the `CMAKE_C_COMPILER` and `CMAKE_CXX_COMPILER` not detected correctly compared to running `cmake -Bbuild -H. -A x64 -T llvm`. MSVC cl.exe is detected in former case, while clang-cl.exe in later case.
See the bug report at
https://github.com/zufuliu/llvm-utils/issues/2
Change (in file Modules/CMakeDetermineCompilerId.cmake)
```cmake
if(CMAKE_VS_PLATFORM_TOOLSET MATCHES "^[Ll][Ll][Vv][Mm]$")
set(id_cl_var "ClangClExecutable")
```
to
```cmake
if(CMAKE_VS_PLATFORM_TOOLSET MATCHES "^[Ll][Ll][Vv][Mm](_v[0-9]+(_xp)?)?$")
set(id_cl_var "ClangClExecutable")
```
could fix this.
Related bug: https://gitlab.kitware.com/cmake/cmake/issues/19174https://gitlab.kitware.com/cmake/cmake/-/issues/17119Static runtime with Visual studio 20152019-04-17T11:26:39-04:00Evgeny FimochkinStatic runtime with Visual studio 2015I try building applications with cxx flag /MT for release build and /MD for debug, but need to pass to the linker to the library libcmt and libcmtd accordingly.
As I can see now I can add libcmt or libcmtd to CMAKE_CXX_STANDARD_LIBRARIE...I try building applications with cxx flag /MT for release build and /MD for debug, but need to pass to the linker to the library libcmt and libcmtd accordingly.
As I can see now I can add libcmt or libcmtd to CMAKE_CXX_STANDARD_LIBRARIES, but how I can pass both libraries for all targets in the project?
Libraries libcmt and libcmtd is a part of static runtime.https://gitlab.kitware.com/cmake/cmake/-/issues/19160cmake-gui: default taskbar overlay icon on Windows2019-04-12T07:29:24-04:00mistersandman9495-mistersandman@users.noreply.gitlab.kitware.comcmake-gui: default taskbar overlay icon on WindowsSince CMake 3.14.0, a default overlay icon appears in the taskbar on Windows, when using `cmake-gui.exe`:
![cmake_icon_overlay](/uploads/669f105f37caf5575e59b96ae60efa5c/cmake_icon_overlay.png)
An attempt to set the overlay icon is mad...Since CMake 3.14.0, a default overlay icon appears in the taskbar on Windows, when using `cmake-gui.exe`:
![cmake_icon_overlay](/uploads/669f105f37caf5575e59b96ae60efa5c/cmake_icon_overlay.png)
An attempt to set the overlay icon is made [here](https://gitlab.kitware.com/cmake/cmake/blob/a550e2d6e48798d342a5ba7436013c6aa6ce5151/Source/QtDialog/CMakeSetupDialog.cxx#L306), although the resource `:/loading.png` is never defined and therefore not found, which makes Windows fall back to this default overlay icon. Also, I didn't find any code that would reset the overlay icon after loading, so I'm not sure what the intention was when introducing it.
Removing the line linked above fixes the issue.3.14.2https://gitlab.kitware.com/cmake/cmake/-/issues/19147cmake-gui: no theme on Windows since CMake 3.142019-04-09T08:01:05-04:00Maartencmake-gui: no theme on Windows since CMake 3.14CMake 3.14 does not use the default Windows theme anymore. Screenshots from the ZIP packages (3.13.4 and latest development distribution), installer version has the same problem.
<img src="/uploads/30b991d28c1edccbe6a470878345168b/3.13....CMake 3.14 does not use the default Windows theme anymore. Screenshots from the ZIP packages (3.13.4 and latest development distribution), installer version has the same problem.
<img src="/uploads/30b991d28c1edccbe6a470878345168b/3.13.png" width="300">
<img src="/uploads/b7e56782f9b9a12a74c6978f368e49db/3.14.png" width="300">3.14.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18240Intel Fortran for Windows and IPO2019-04-01T06:56:38-04:00yrHeTaTeJlbIntel Fortran for Windows and IPOSeems like CMAKE_Fortran_CREATE_STATIC_LIBRARY contains hardcoded `lib` command. It leads to link errors when I try to use Fortran(ifort) library compiled with `/Qipo` option in C++ project(MSVC). Currently I'm using this hack in my Fort...Seems like CMAKE_Fortran_CREATE_STATIC_LIBRARY contains hardcoded `lib` command. It leads to link errors when I try to use Fortran(ifort) library compiled with `/Qipo` option in C++ project(MSVC). Currently I'm using this hack in my Fortran project:
```
project(Foo Fortran)
if(WIN32 AND ${CMAKE_Fortran_CREATE_STATIC_LIBRARY} MATCHES "^lib.*")
set(CMAKE_Fortran_CREATE_STATIC_LIBRARY "xi${CMAKE_Fortran_CREATE_STATIC_LIBRARY}") #use xilib instead of lib
endif()
```
But, I think, CMake should be able to do it without such hacks.https://gitlab.kitware.com/cmake/cmake/-/issues/19049find_program returns wrong paths when searching on a Windows share2019-03-28T12:24:07-04:00Paul Bodenbennerfind_program returns wrong paths when searching on a Windows shareStarting with CMake 3.13.0 find_program returns wrong paths when searching on a Windows share. This did not happen on earlier versions, tested e.g. 3.12.4. When a network path is passed to find_program (e.g.: //host/path) the executable ...Starting with CMake 3.13.0 find_program returns wrong paths when searching on a Windows share. This did not happen on earlier versions, tested e.g. 3.12.4. When a network path is passed to find_program (e.g.: //host/path) the executable is found but the returned path has only one slash at the beginning (e.g.: /host/path).
* 3.12.4 --> works
* 3.13.0 --> does not work
* 3.14.0-rc4 --> does not work
The attached minimal example can be used to demonstrate the problem by using following command:
`cmake.exe -DPROGRAM_NAME=test -DPROGRAM_PATH=//host/path .`
The returned path is printed using the message command.
[CMakeLists.txt](/uploads/b0ca951d22d2571b7c7e97aea6c88b5f/CMakeLists.txt)3.14.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17518ToT Clang on Windows does not work2019-02-18T07:55:06-05:00Loo Rong JieToT Clang on Windows does not workIn October, CMake added a check to test if `--version` flag is available in clang [1]. If the flag is available, it should mean it is `clang.exe` or `clang++.exe` instead of `clang-cl.exe`.
However, `--version` was added into `clang-cl....In October, CMake added a check to test if `--version` flag is available in clang [1]. If the flag is available, it should mean it is `clang.exe` or `clang++.exe` instead of `clang-cl.exe`.
However, `--version` was added into `clang-cl.exe` as well in the same month [2]!
Please revert [1].
- [1]: https://gitlab.kitware.com/cmake/cmake/commit/b6d3a1c09a796ec0c29074c387953fb88ebfe874
- [2]: https://github.com/llvm-mirror/clang/commit/c5924addeeea29249ddbf048d3860c9e2198d2893.10.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18845CMake install operation very slow for VS2017 32-bit build2019-02-17T14:03:23-05:00Steve RobinsonCMake install operation very slow for VS2017 32-bit buildReproduction steps:
Reproduced on Windows 10 Pro v1809:
* Visual Studio 2017 (I used Community Edition)
* CMake (I used 3.13.3, both x86 and x64, CMake must be added to the PATH env var)
* Conan (https://conan.io/downloads.html)
1. Clo...Reproduction steps:
Reproduced on Windows 10 Pro v1809:
* Visual Studio 2017 (I used Community Edition)
* CMake (I used 3.13.3, both x86 and x64, CMake must be added to the PATH env var)
* Conan (https://conan.io/downloads.html)
1. Clone this repo:
https://gitlab.com/ssrobins/sfml-examples/
2. Open a terminal, cd to the repo, and run:
build_windows64.bat
This generates a 64-bit VS2017 project and does the build, install, and packaging.
Install/packaging step is quick, as expected since the total size of files being copied over is only 22 MB.
My CI system does the whole build, install, and package process in 2 minutes, 16 seconds:
https://gitlab.com/ssrobins/sfml-examples/-/jobs/151715635
3. Open a terminal, cd to the repo, and run:
build_windows.bat
This is the same as above except a 32-bit VS2017 project is generated.
The 'Install component' for each target takes much longer. My CI system takes 9 minutes, 13 seconds to do the build, install, and packaging:
https://gitlab.com/ssrobins/sfml-examples/-/jobs/151714703
macOS and linux 64-bit builds took less than a minute and a half:
https://gitlab.com/ssrobins/sfml-examples/-/jobs/151714552
https://gitlab.com/ssrobins/sfml-examples/-/jobs/151714553
The problem can be reproduced with the install command of a single target:
* cd build_windows\01_Tetris
* cmake.exe --trace -DBUILD_TYPE=Release -P cmake_install.cmake
The trace shows that it's primarily spending time on this command:
file(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/01_Tetris TYPE EXECUTABLE FILES D:/Code/sfml-examples/build_windows/01_Tetris/Release/01_Tetris.exe )
The command takes about a second for the 64-bit build and around 9 seconds for the 32-bit build.
This problem has forced me to comment out the install step on several targets to keep builds fast.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/18862CMAKE_SOURCE_DIR is not normalised in server mode2019-02-06T10:12:39-05:00Gregor JasnyCMAKE_SOURCE_DIR is not normalised in server modeHello,
I originally reported the bug here: https://github.com/vector-of-bool/vscode-cmake-tools/issues/642
But I suspect that the bug is in the cmake-server code where some normalisation does not take place.
### Brief Issue Summary
I ...Hello,
I originally reported the bug here: https://github.com/vector-of-bool/vscode-cmake-tools/issues/642
But I suspect that the bug is in the cmake-server code where some normalisation does not take place.
### Brief Issue Summary
I have the problem that the `if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)` expression does not return true for the root-level CMakeLists.txt file. That breaks some code that uses this expression to check if the project is the "root" level project or if it has been added via `add_subdirectory`.
To reproduce put the following into a `CMakeLists.txt` file and load it into vscode:
```
project(testcase NONE)
message(STATUS "CMAKE_SOURCE_DIR=${CMAKE_SOURCE_DIR}")
message(STATUS "CMAKE_CURRENT_SOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR}")
message(STATUS "CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR}")
message(STATUS "CMAKE_CURRENT_BINARY_DIR=${CMAKE_CURRENT_BINARY_DIR}")
```
If you configure you'll see the following output (note the different `c:` vs. `C:`):
```
[cmake] CMAKE_SOURCE_DIR=c:/Users/gjasny/Git/testcase
[cmake] CMAKE_CURRENT_SOURCE_DIR=C:/Users/gjasny/Git/testcase
[cmake] CMAKE_BINARY_DIR=c:/Users/gjasny/Git/testcase/build
[cmake] CMAKE_CURRENT_BINARY_DIR=C:/Users/gjasny/Git/testcase/build
```
If I run cmake on the command line everything works as expected:
```
cmake.exe -S c:\Users\gjasny\Git\testcase -B C:\Users\gjasny\Git\testcase
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.14393.
-- CMAKE_SOURCE_DIR=C:/Users/gjasny/Git/testcase
-- CMAKE_CURRENT_SOURCE_DIR=C:/Users/gjasny/Git/testcase
-- CMAKE_BINARY_DIR=C:/Users/gjasny/Git/testcase
-- CMAKE_CURRENT_BINARY_DIR=C:/Users/gjasny/Git/testcase
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/gjasny/Git/testcase
```
### Expected:
in the root-level of the project the `CMAKE_CURRENT_xxx_DIR` and `CMAKE_xxx_DIR` should be STREQUAL.
### Platform and Versions
- **Operating System**: Windows
- **CMake Version**: 3.13.3
- **VSCode Version**: 1.30.2
- **CMake Tools Extension Version**: 1.1.3
- **Compiler/Toolchain**: Visual C++ 2017
Thanks,
Gregorhttps://gitlab.kitware.com/cmake/cmake/-/issues/18855Ninja: Use depfile with Intel Compiler for Windows2019-02-06T10:12:37-05:00Brad KingNinja: Use depfile with Intel Compiler for WindowsWith [ninja PR 1039](https://github.com/ninja-build/ninja/pull/1039) merged, Ninja 1.9 will support the depfiles produced by the Intel Compiler for Windows. This means that with a sufficiently new Ninja, CMake's generator can switch to ...With [ninja PR 1039](https://github.com/ninja-build/ninja/pull/1039) merged, Ninja 1.9 will support the depfiles produced by the Intel Compiler for Windows. This means that with a sufficiently new Ninja, CMake's generator can switch to them over the showIncludes approach.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16178GHS-DetermineCompiler.cmake testing for the INTEGRITY RTOS?2019-01-18T08:51:24-05:00chrisbuxGHS-DetermineCompiler.cmake testing for the INTEGRITY RTOS?In GHS-DetermineCompiler.cmake, it seems that instead of checking for the GHS MULTI compiler, it is actually checking to see if the GHS INTEGRITY RTOS is available.
set(_compiler_id_pp_test "defined(__INTEGRITY)")
set(_compil...In GHS-DetermineCompiler.cmake, it seems that instead of checking for the GHS MULTI compiler, it is actually checking to see if the GHS INTEGRITY RTOS is available.
set(_compiler_id_pp_test "defined(__INTEGRITY)")
set(_compiler_id_version_compute "
# define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_DEC@(__INTEGRITY_MAJOR_VERSION)
# define @PREFIX@COMPILER_VERSION_MINOR @MACRO_DEC@(__INTEGRITY_MINOR_VERSION)
# define @PREFIX@COMPILER_VERSION_PATCH @MACRO_DEC@(__INTEGRITY_PATCH_VERSION)")
Since the GHS MULTI compiler can be used without the INTEGRITY RTOS, should this cmake file check for the __ghs__ definition instead?
set(_compiler_id_pp_test "defined(__ghs__)")
set(_compiler_id_version_compute "# define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_DEC@(__GHS_VERSION_NUMBER)")Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/16849NMake configuration on Windows fails2019-01-04T16:14:06-05:00Cavit Sina DogruNMake configuration on Windows failsConfiguring a simple cmake project for NMake fails but interestingly configuring it for Visual Studio works. Here is the error log:
```
Determining if the C compiler works failed with the following output:
Change Dir: C:/Users/Cavit/Cod...Configuring a simple cmake project for NMake fails but interestingly configuring it for Visual Studio works. Here is the error log:
```
Determining if the C compiler works failed with the following output:
Change Dir: C:/Users/Cavit/Codes/ObserverPattern/build/CMakeFiles/CMakeTmp
Run Build Command:"nmake" "/NOLOGO" "cmTC_ec538\fast"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" -f CMakeFiles\cmTC_ec538.dir\build.make /nologo -L CMakeFiles\cmTC_ec538.dir\build
Building C object CMakeFiles/cmTC_ec538.dir/testCCompiler.c.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe @C:\Users\Cavit\AppData\Local\Temp\nm191C.tmp
testCCompiler.c
Linking C executable cmTC_ec538.exe
"C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_ec538.dir --manifests -- C:\PROGRA~2\MICROS~1.0\VC\bin\link.exe /nologo @CMakeFiles\cmTC_ec538.dir\objects1.rsp @C:\Users\Cavit\AppData\Local\Temp\nm1A84.tmp
RC Pass 1 failed to run.
NMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
```
I have tried to use different CMake versions, 3.7.2 and 3.8.1, they both gave the same results.
I am not sure if this problem related to CMake or NMake, or if am I doing some silly mistake, I would like to find out the problem.https://gitlab.kitware.com/cmake/cmake/-/issues/8884Set Visual Studio project "custom environment variables" setting with CMake2018-12-11T20:23:24-05:00Kitware RobotSet Visual Studio project "custom environment variables" setting with CMakeThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8884). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8884). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/12327Appending Multiple COMPILE_FLAGS Produces Unexpected Results2018-12-07T09:59:39-05:00Kitware RobotAppending Multiple COMPILE_FLAGS Produces Unexpected ResultsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12327). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12327). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13033Enhance verbosity of tests failing with "OTHER_FAULT" on windows2018-12-07T09:59:15-05:00Kitware RobotEnhance verbosity of tests failing with "OTHER_FAULT" on windowsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13033). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13033). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13612FindMPI doesn't work correctly on Windows with OpenMPI 1.6.22018-12-07T09:58:50-05:00Kitware RobotFindMPI doesn't work correctly on Windows with OpenMPI 1.6.2This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13612). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13612). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13764is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for DL...2018-12-07T09:58:45-05:00Kitware Robotis_file_executable() from GetPrerequisites.cmake erroneously returns 0 for DLL on windowsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13764). Further discussion may take place here.
---
On Windows `is_file_executable()` checks the extension to determine whether ...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13764). Further discussion may take place here.
---
On Windows `is_file_executable()` checks the extension to determine whether the file is executable. DLL should also be considered as executable, so `fixup_bundle` would work.
```console
> cmake -P is_dll_executable.cmake
c:/windows/system32/kernel32.dll: 0
> type is_dll_executable.cmake
include(BundleUtilities)
set(f0 "c:/windows/system32/kernel32.dll")
is_file_executable(f0 is_dll_executable)
message("${f0}: ${is_dll_executable}")
```
expected output would be:
```
c:/windows/system32/kernel32.dll: 1
```
```patch
diff --git a/GetPrerequisites.cmake-orig b/GetPrerequisites.cmake
index 8f2754e..94ae7d1 100644
--- a/GetPrerequisites.cmake-orig
+++ b/GetPrerequisites.cmake
@@ -144,10 +144,10 @@ function(is_file_executable file result_var)
get_filename_component(file_full "${file}" ABSOLUTE)
string(TOLOWER "${file_full}" file_full_lower)
- # If file name ends in .exe on Windows, *assume* executable:
+ # If file name ends in .exe or .dll on Windows, *assume* executable:
#
if(WIN32 AND NOT UNIX)
- if("${file_full_lower}" MATCHES "\\.exe$")
+ if("${file_full_lower}" MATCHES "\\.exe$" OR "${file_full_lower}" MATCHES "\\.dll$")
set(${result_var} 1 PARENT_SCOPE)
return()
endif()
```https://gitlab.kitware.com/cmake/cmake/-/issues/13803Ninja: cmake generates RSP_FILE with back slashes for ninja2018-12-07T09:58:43-05:00Kitware RobotNinja: cmake generates RSP_FILE with back slashes for ninjaThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13803). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13803). Further discussion may take place here.