CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-11-10T10:44:46-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/17444CMake thinks mt.exe failed even though it succeeded2017-11-10T10:44:46-05:00Isuru FernandoCMake thinks mt.exe failed even though it succeededI get
```
MT: command "mt /nologo /manifest CMakeFiles\hello_world.dir/intermediate.manifest /out:CMakeFiles\hello_world.dir/embed.manifest /notify_update" failed (exit code 0x41020001) with the following output:
```
Exit code 0x4102000...I get
```
MT: command "mt /nologo /manifest CMakeFiles\hello_world.dir/intermediate.manifest /out:CMakeFiles\hello_world.dir/embed.manifest /notify_update" failed (exit code 0x41020001) with the following output:
```
Exit code 0x41020001 is a success code according to https://developercommunity.visualstudio.com/content/problem/138528/155-preview-tons-of-random-linker-errors-that-work.html and https://msdn.microsoft.com/en-us/library/windows/desktop/aa363651(v=vs.85).aspx3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17298Ninja rule for MS resource compiler has too many double quotes2017-09-27T07:14:20-04:00massNinja rule for MS resource compiler has too many double quotesI'm using CMake 3.9.3 on Window 10 with Visual Studio 2015 Update 3.
I've noticed that when my project has a space in its name, the MS resource compiler fails to compile my project but when I remove the space everything works.
At firs...I'm using CMake 3.9.3 on Window 10 with Visual Studio 2015 Update 3.
I've noticed that when my project has a space in its name, the MS resource compiler fails to compile my project but when I remove the space everything works.
At first I thought it was a pathing problem, maybe some path wasn't getting quoted, instead it's the exact opposite - too many quotes!
Here is the rule generated for Ninja as it pertains to RC (tool paths have been abbreviated).
```
#############################################
# Rule for compiling RC files.
rule RC_COMPILER__
depfile = $DEP_FILE
deps = gcc
command = "C:/.../cmcldeps.exe" RC $in "$DEP_FILE" $out "Note: including file: " "C:/.../cl.exe" C:\...\rc.exe $DEFINES $INCLUDES $FLAGS /fo$out $in
description = Building RC object $out
```
Note that `$DEP_FILE` is surrounded by double quotes. When my project's name has no spaces the command line looks like this (again, paths are shortened):
```
"C:/.../cmcldeps.exe" RC C:\...\Resource.rc "src\CMakeFiles\OneWord.dir\Resource.rc.res.d" "src\CMakeFiles\OneWord.dir\Resource.rc.res" "Note: including file: " "C:/.../cl.exe" C:\...\rc.exe -DNDEBUG /fo"src\CMakeFiles\OneWord.dir\Resource.rc.res" C:\...\Resource.rc
```
When I have a space, CMake correctly surrounds any paths using it with double-quotes. However, As you can see from the rule, `$DEP_FILE` is also always surrounded by quotes, this destroys the command line like so:
```
"C:/.../cmcldeps.exe" RC C:\...\Resource.rc ""src\CMakeFiles\Two Words.dir\Resource.rc.res.d"" "src\CMakeFiles\Two Words.dir\Resource.rc.res" "Note: including file: " "C:/.../cl.exe" C:\...\rc.exe -DNDEBUG /fo"src\CMakeFiles\Two Words.dir\Resource.rc.res" C:\...\Resource.rc
```
This causes the second parameter to RC to be `""` rather than `"src\CMakeFiles\Two Words.dir\Resource.rc.res.d"`
I'm currently getting around it by having removed the quotes from around `$DEP_FILE` in `cmNinjaTargetGenerator.cxx:441`. I'm not sure if that's the right fix, but it unblocks me.
Thank you3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16803Opt-in to new Win32 API that allows paths longer than 260 characters2017-10-18T10:23:30-04:00Taylor Braun-JonesOpt-in to new Win32 API that allows paths longer than 260 charactersCPack fails when packaging files in a deeply nested tree with total path length greater than 260 characters:
```
CPack Error: ERROR while packaging files: Error opening "some/long/filepath...": No such file or directory
```
Globally op...CPack fails when packaging files in a deeply nested tree with total path length greater than 260 characters:
```
CPack Error: ERROR while packaging files: Error opening "some/long/filepath...": No such file or directory
```
Globally opting in to the new Win32 API for the entire system fixes the problem (by enabling registry key `HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled` on Windows 10 build 1607 or newer) but CMake binaries should opt-in so this registry change is not necessary by enabling the `ws2:longPathAware` option in the manifest:
```xml
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
```
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
Note that this is somewhat counter to the proposal in #164853.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16482MSVC standard version switches2018-03-31T07:42:05-04:00Nils GladitzMSVC standard version switchesVisual Studio C++ 2015 Update 3 introduced standard version switches [1].
They seem to only make sense for >= C++14 which I assume becomes relevant with the changes in !299 (#16468).
Specifically for C++17 features `/std:c++latest`...Visual Studio C++ 2015 Update 3 introduced standard version switches [1].
They seem to only make sense for >= C++14 which I assume becomes relevant with the changes in !299 (#16468).
Specifically for C++17 features `/std:c++latest` (and later `/std:c++17`) might be required.
<br/>
[1] https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16266Ninja generator passes -std option to clang-cl2018-02-20T16:28:55-05:00Jørgen IbsenNinja generator passes -std option to clang-clWhen Ninja is targeting Clang's MSVC compatible tools (clang-cl), and you require a certain C++ version, it passes the `-std` option, which Clang 3.8.1 does not accept.
For this example:
~~~.cmake
cmake_minimum_required(VERSION 3.6)...When Ninja is targeting Clang's MSVC compatible tools (clang-cl), and you require a certain C++ version, it passes the `-std` option, which Clang 3.8.1 does not accept.
For this example:
~~~.cmake
cmake_minimum_required(VERSION 3.6)
project(foo CXX)
add_executable(foo foo.cpp)
set_property(TARGET foo PROPERTY CXX_STANDARD "11")
set_property(TARGET foo PROPERTY CXX_STANDARD_REQUIRED TRUE)
~~~
~~~.cpp
int main() { auto i = 5; }
~~~
I get:
~~~
[1/2] Building CXX object CMakeFiles\foo.dir\foo.cpp.obj
FAILED: CMakeFiles/foo.dir/foo.cpp.obj
D:\LLVM\msbuild-bin\cl.exe /nologo /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -std=gnu++11 /showIncludes /FoCMakeFiles\foo.dir\foo.cpp.obj /FdCMakeFiles\foo.dir\ -c foo.cpp
clang-cl.exe: error: unknown argument: '-std=gnu++11'
ninja: build stopped: subcommand failed.
~~~
3.10.0