CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-11-06T11:43:43-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/17121FindBoost.cmake does not find boost libraries created with Visual Studio Comm...2018-11-06T11:43:43-05:00Janek GröhlFindBoost.cmake does not find boost libraries created with Visual Studio Community 2017Could't build a project depending on boost libraries with VS Community 2017.
The compiler version -vc150 would need to be added to the list of compiler versions.Could't build a project depending on boost libraries with VS Community 2017.
The compiler version -vc150 would need to be added to the list of compiler versions.https://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/17118VS: cmake 3.9.0 randomly errors out on Appveyor build machine with MSBuild.ex...2017-08-04T12:38:44-04:00Max HoraVS: cmake 3.9.0 randomly errors out on Appveyor build machine with MSBuild.exe failureRecently we have switched to cmake 3.9.0 and found random failures related to MSBuild.
Command line sample: cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
CMake output:
```
CMake Error at CMakeLists.txt:19 (project...Recently we have switched to cmake 3.9.0 and found random failures related to MSBuild.
Command line sample: cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
CMake output:
```
CMake Error at CMakeLists.txt:19 (project):
Failed to run MSBuild command:
C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 7/29/2017 12:38:16 AM.
The target "_ConvertPdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,37)" does not exist in the project, and will be ignored.
The target "_CollectPdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,70)" does not exist in the project, and will be ignored.
The target "_CollectMdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,38)" does not exist in the project, and will be ignored.
The target "_CopyMdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,71)" does not exist in the project, and will be ignored.
Project "C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj" on node 1 (default targets).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Release|x64. [C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj]
Done Building Project "C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj" (default target) (1) ->
(PrepareForBuild target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Release|x64. [C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.97
Exit code: 1
```
We have noticed that 3.9.0 version of cmake generates folder "3.9.0" and puts VCTargetsPath.vcxproj file into it.
Content of the `VCTargetsPath.vcxproj` on failure is following:
```
<?xml version="1.0" encoding="UTF-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{F3FC6D86-508D-3FB1-96D2-995F08B142EC}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
<Platform>x64</Platform>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props"/>
<PropertyGroup Label="Configuration">
<ConfigurationType>Utility</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<PlatformToolset>v140</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props"/>
<ItemDefinitionGroup>
<PostBuildEvent>
<Command>echo VCTargetsPath=$(VCTargetsPath)</Command>
</PostBuildEvent>
</ItemDefinitionGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets"/>
</Project>
```
Full content of CMake build directory during the failure is attached as [zip archive](/uploads/42747c0ddff0c4d88c0573960a2fba00/build.zip).
Link to AppVeyor job with failure: https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/build/1.0.2593/job/q484cyl1one8gn2l3.9.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17100cpack zip archives cannot contain long paths on windows2017-09-07T17:28:18-04:00Stevencpack zip archives cannot contain long paths on windowsTo witness, generate nmake or visual studio (2015) builds with the attached project and build the package target.
(maybe builds with other generators will reproduced, but I have not tried them)
Note that the packaging succeeds, but the ...To witness, generate nmake or visual studio (2015) builds with the attached project and build the package target.
(maybe builds with other generators will reproduced, but I have not tried them)
Note that the packaging succeeds, but the package does not contain all intended content.
[cpack_pathlimit.zip](/uploads/fcf202b5a24fb8af7061af77b73043cd/cpack_pathlimit.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/17095CMake v3.9: Windows installation GUI cannot show strings, shows numeric place...2017-08-03T11:36:07-04:00AlexBCMake v3.9: Windows installation GUI cannot show strings, shows numeric placeholdersPlatform: Windows
CMake version: 3.9
CMake installation wizard shows placeholders with numbers instead of strings. See attached screenshot.
![CMake_Install](/uploads/80af9c2c99b5d1b0d25c72dba75cb4e9/CMake_Install.png)Platform: Windows
CMake version: 3.9
CMake installation wizard shows placeholders with numbers instead of strings. See attached screenshot.
![CMake_Install](/uploads/80af9c2c99b5d1b0d25c72dba75cb4e9/CMake_Install.png)Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/17067Trying to add_test using cmd.exe2022-06-13T10:27:08-04:00Ákos TomposTrying to add_test using cmd.exeUsing cmake version 3.8.1
The following really short CMakeLists.txt file should add a single test that runs cmd /?. As running the help returns failure it should fail and with the --output-on-failure option you can see the output.
```
...Using cmake version 3.8.1
The following really short CMakeLists.txt file should add a single test that runs cmd /?. As running the help returns failure it should fail and with the --output-on-failure option you can see the output.
```
enable_testing()
add_test(NAME Test
COMMAND cmd /?
WORKING_DIRECTORY ".")
```
executing the test:
```
cmake . && ctest -C Debug --output-on-failure
```
The result is surprising:
```
Start 1: Test
1/1 Test #1: Test .............................***Failed 0.02 sec
Creates a directory.
MKDIR [drive:]path
MD [drive:]path
If Command Extensions are enabled MKDIR changes as follows:
MKDIR creates any intermediate directories in the path, if needed.
For example, assume \a does not exist then:
mkdir \a\b\c\d
is the same as:
mkdir \a
chdir \a
mkdir b
chdir b
mkdir c
chdir c
mkdir d
which is what you would have to type if extensions were disabled.
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.03 sec
The following tests FAILED:
1 - Test (Failed)
Errors while running CTest
```
Which is the help for the `md` command. And indeed the `ctest` runs `md` instead of `cmd`
It somehow omits the first character of the command. It doesn't do that with other commands though.https://gitlab.kitware.com/cmake/cmake/-/issues/17050Unix Makefiles vs Windows paths...2017-07-13T13:53:54-04:00Ryan C. GordonUnix Makefiles vs Windows paths...(Tested against CMake 3.8.2, prebuilt binary downloaded from cmake.org.)
When attempting to build with Mingw64, a Windows path with a drive letter on it will confuse GNU Make, producing a misleading error message. Here's a simplified te...(Tested against CMake 3.8.2, prebuilt binary downloaded from cmake.org.)
When attempting to build with Mingw64, a Windows path with a drive letter on it will confuse GNU Make, producing a misleading error message. Here's a simplified test case based on one I stumbled across in real project:
cmake_minimum_required(VERSION 3.2)
project(brokenmake)
find_library(PTHREAD_LIBRARY pthread)
add_executable(brokenmake brokenmake.c)
target_link_libraries(brokenmake ${PTHREAD_LIBRARY})
Just make a zero-byte file named "brokenmake.c" and run CMake like this:
cmake -G "Unix Makefiles" -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc .
CMake succeeds, but running "make" afterwards produces this error:
CMakeFiles/brokenmake.dir/build.make:93: *** target pattern contains no '%'. Stop.
The problem is this line in build.make:
brokenmake.exe: C:/cygwin/lib/libpthread.a
The ':' confuses GNU Make; it needs to be escaped...
brokenmake.exe: C\:/cygwin/lib/libpthread.a
...and then GNU Make works fine with this makefile (rather: it compiles and fails to link without a WinMain(), but GNU Make did the right thing at that point.)
I guess the Unix Makefile generator needs to check files for special characters (space, :, $, a few others?) and escape as appropriate?
--ryan.https://gitlab.kitware.com/cmake/cmake/-/issues/17047Add support for VS2017 Linux project generation2022-03-30T15:30:45-04:00Joerg SchumannAdd support for VS2017 Linux project generationI'd like to see Linux projects added to the Visual Studio generator, so one can generate VS projects from existing CMake Linux projects in order to use VS for development and compiling remotely.
According to [this SO answer](https://sta...I'd like to see Linux projects added to the Visual Studio generator, so one can generate VS projects from existing CMake Linux projects in order to use VS for development and compiling remotely.
According to [this SO answer](https://stackoverflow.com/a/44958071/27596), the following properties are necessary for VS 2017 to recognize a project a Linux project:
```
set_target_properties(
HelloLinux
PROPERTIES
VS_GLOBAL_KEYWORD "Linux"
VS_GLOBAL_ApplicationType "Linux"
VS_GLOBAL_ApplicationTypeRevision "1.0"
VS_GLOBAL_TargetLinuxPlatform "Generic"
VS_GLOBAL_LinuxProjectType "{D51BCBC9-82E9-4017-911E-C93873C4EA2B}"
)
```
But the comment also notes
> This actually works and produces a Linux .vcxproj project that is accepted by VS. But since we sidestepped CMake here, none of the other compiler/linker options you define in your CMake script will be assigned.
which is why native cmake support would be preferred.
~"os:windows"
~"triage:feature"
~"gen:msvc"https://gitlab.kitware.com/cmake/cmake/-/issues/16972MSYS2/MinGW DLL naming scheme2021-01-18T10:07:44-05:00evpobrMSYS2/MinGW DLL naming schemeWhen building library **foo** DLL with MSYS2/MinGW under Windows 7 in my case, CMake producing `libfoo.dll`, when DLL built with Autools is `libfoo-1.dll`. `SOVERSION` is set to `1` and VERSION is `1.0.0.0`.When building library **foo** DLL with MSYS2/MinGW under Windows 7 in my case, CMake producing `libfoo.dll`, when DLL built with Autools is `libfoo-1.dll`. `SOVERSION` is set to `1` and VERSION is `1.0.0.0`.https://gitlab.kitware.com/cmake/cmake/-/issues/16962cmake -E server changes default linefeed style of configure_file(...) to LF2018-01-23T09:08:47-05:00Kevin Puetzcmake -E server changes default linefeed style of configure_file(...) to LFWhen configuring my project using Qt creator 4.3 on Windows 7 x64 (which now uses cmake -E server) all configure_file outputs switched from CRLF to LF line endings. However, if they are later regenerated (e.g. ninja RERUN_CMAKE, make cma...When configuring my project using Qt creator 4.3 on Windows 7 x64 (which now uses cmake -E server) all configure_file outputs switched from CRLF to LF line endings. However, if they are later regenerated (e.g. ninja RERUN_CMAKE, make cmake_check_build_system, etc), they switch back to CRLF as before. This causes unnecessary rebuilds and build outputs that differ depending on whether the built is from the IDE's initial setup or an incremental run.
If overridden with NEWLINE_STYLE they can still be forced to either type, but the fact that the default is now inconsistent from run to run seems undesirable.
This misbehavior appears to be caused by the bundled libuv, which is setting the (deprecated) `_fmode = _O_BINARY` global variable
in MSVCRT (https://msdn.microsoft.com/en-us/library/ee2849wt.aspx) and thus changing the default behavior of all subsequent open calls process-wide. This is happening in [uv_fs_init](https://gitlab.kitware.com/cmake/cmake/blob/ed17516b31404dd42eab61c599c84933af485b34/Utilities/cmlibuv/src/win/fs.c#L118), which is called from uv_init and hence from the first call to most any nontrivial libuv function.
I am seeing this behavior from multiple CMake versions, as long as they support -E server (tested 3.7.2, 3.9.0-rc2)3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16943libelf RPATH parsing / install time substitution on Windows2017-07-07T10:33:11-04:00Nils Gladitzlibelf RPATH parsing / install time substitution on WindowsAssuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a ...Assuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a cross-compile setup targeting Linux.https://gitlab.kitware.com/cmake/cmake/-/issues/16937Windows MSI installer flashes briefly and exits2017-07-07T10:33:29-04:00Dan WolfWindows MSI installer flashes briefly and exitsAfter downloading the Windows MSI for 3.8.2, I ran it, but after a flash of a dialog (not even sure it has words populate), it exits. There are no error messages. I'm using Windows 10 with the latest Creator's Update.After downloading the Windows MSI for 3.8.2, I ran it, but after a flash of a dialog (not even sure it has words populate), it exits. There are no error messages. I'm using Windows 10 with the latest Creator's Update.https://gitlab.kitware.com/cmake/cmake/-/issues/16935Add TARGET_COMPILE_PDB_NAME generator expression2021-04-22T10:32:35-04:00Walter GrayAdd TARGET_COMPILE_PDB_NAME generator expressionI'd like to be able to query the PDB name of a target so that I can add it to the install package, however there does not appear to be any way for me to query the default PDB name for a given .libI'd like to be able to query the PDB name of a target so that I can add it to the install package, however there does not appear to be any way for me to query the default PDB name for a given .libhttps://gitlab.kitware.com/cmake/cmake/-/issues/16919Do not emit -isystem for INSTALL_INCLUDE_PATH2018-08-30T11:11:54-04:00Demi Marie ObenourDo not emit -isystem for INSTALL_INCLUDE_PATHWhen running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilat...When running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilation to fail with:
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ext/string_conversions.h:41:0,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/basic_string.h:6157,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/string:52,
from /usr/x86_64-w64-mingw32/sys-oot/mingw/include/boost/test/utils/basic_cstring/bcs_char_traits.hpp:25,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/utils/basic_cstring/basic_cstring.hpp:21,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/detail/global_typedef.hpp:15,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tree/observer.hpp:17,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test_log.hpp:18,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tools/old/impl.hpp:19,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/test_tools.hpp:46,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test.hpp:18,
from /home/dobenour/repos/SlipRock/src/test.cpp:16:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
The culprit is that CMake generates `-isystem` flags pointing to `INCLUDE_INSTALL_DIR`, when it should use plain `-I`.
Tested with version 3.8.1 from Fedora. There was a [GCC bug] about this behavior on GCC’s part, which was closed as WONTFIX.
[GCC bug]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129https://gitlab.kitware.com/cmake/cmake/-/issues/16913automoc: Too long path issue on Windows platform using cmake 3.8.12020-05-07T02:52:20-04:00Dominique LEDITautomoc: Too long path issue on Windows platform using cmake 3.8.1I upgraded the cmake version we used in our Windows build environment from 3.4.2 to 3.8.1.
We need this upgrade (or at least the upgrade to cmake 3.7.2) because we aim to update Visual Studio to 2017 version, and need for that to have t...I upgraded the cmake version we used in our Windows build environment from 3.4.2 to 3.8.1.
We need this upgrade (or at least the upgrade to cmake 3.7.2) because we aim to update Visual Studio to 2017 version, and need for that to have the corresponding CMake generator.
In Our build environment CMAKE_AUTOMOC is ON
As a result of the cmake version upgrade, I started to have too long path issue, on Windows platform (Windows 7/Windows server 2008 , Visual Studio 2013), with c++ source file generated by moc.
This is a result of the new location for auto-generated files(see AUTOMOC documentation https://cmake.org/cmake/help/v3.8/prop_tgt/AUTOMOC.html). They use to be located in the <CMAKE_CURRENT_BINARY_DIR> and are, with the 3.8 release located in <CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include directory (two more directory levels)
This is hard coded in CMake C++ source code with no way for customization.
So I only have two solutions:
- Re-organize our source code directory tree, trying to shorten directory names, rename the targets using shorter names
- Modify the CMake source code and rebuild CMake 3.8.1 on both Linux and Windows platforms
The first solution is too heavy and we don't have material time to plan such a huge change.
So I quickly patched two C++ cmake source code files to relocate the auto-generated moc files in <CMAKE_BINARY_DIR>/autogen/<target_name>_autogen directory and rebuild cmake 3.8.1 on both Linux and Windows platforms[PatchedCmakeFiles.zip](/uploads/a0c257edf45d93d5483043ff498a3d62/PatchedCmakeFiles.zip).
This is a really annoying problem and it would be very helpful to have an external way to customize the location of the auto-generated file (at least the root directory where to create the <target_name>_autogen directory) using a CMAKE macro for example
Hope this will be integrated quickly.
Thanks
Dominique3.9.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/16893Ninja generator doesn’t work in msys2-built cmake2017-05-26T11:17:20-04:00Norbert PfeilerNinja generator doesn’t work in msys2-built cmakeThe problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to...The problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to work with mingw-w64 which results in an inability for the generator to produce any files.
`codecvt::do_out` always returns `std::codecvt::error` when a range of more than 1 char is passed.
Changing [this condition](https://gitlab.kitware.com/cmake/cmake/blob/6b05e028f1a3afc7906908bd48d58993da02a9d9/Source/cm_codecvt.cxx#L61) to `>= 1` seems to fix it.
I’m not sure why it should work the way it currently is at all.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16878cmlibuv fails with Intel C Compiler on Windows2017-05-18T10:50:14-04:00Christian Pfeiffercmlibuv fails with Intel C Compiler on Windowslibuv itself has an issue fixed upstream by [this commit](https://github.com/libuv/libuv/commit/196eb8b94f7c5543e9057cac7a417fa5c0c5b8af) that causes the build to fail because `__declspec(inline)` isn't a valid attribute to Intel C (it's...libuv itself has an issue fixed upstream by [this commit](https://github.com/libuv/libuv/commit/196eb8b94f7c5543e9057cac7a417fa5c0c5b8af) that causes the build to fail because `__declspec(inline)` isn't a valid attribute to Intel C (it's also undocumented for MSVC).
Should we integrate that patch in `cmlibuv` to address this or accept it being broken until the next upstream release?Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16859install/strip broken when absolute DESTINATION is used in install() (on Windows)2021-02-01T13:35:12-05:00Patrick Storzinstall/strip broken when absolute DESTINATION is used in install() (on Windows)While trying to figure out #16858 I realized an absolute `DESTINATION` in `install()` commands completely breaks the `install/strip` target:
For a minimal CMakeLists
```
project (hello)
add_executable(hello helloworld.cpp)
install...While trying to figure out #16858 I realized an absolute `DESTINATION` in `install()` commands completely breaks the `install/strip` target:
For a minimal CMakeLists
```
project (hello)
add_executable(hello helloworld.cpp)
install (TARGETS hello DESTINATION "E:\\bin")
```
the following output is created in `cmake_install.cmake`
```
file(INSTALL DESTINATION "E:/bin" TYPE EXECUTABLE FILES "E:/Temp/Project/build/hello.exe")
if(EXISTS "$ENV{DESTDIR}/E:/bin/hello.exe" AND
NOT IS_SYMLINK "$ENV{DESTDIR}/E:/bin/hello.exe")
if(CMAKE_INSTALL_DO_STRIP)
execute_process(COMMAND "C:/msys64/mingw64/bin/strip.exe" "$ENV{DESTDIR}/E:/bin/hello.exe")
endif()
endif()
```
Obviously already the call to `if(EXISTS ...)` is bound to fail due to the illegal `$ENV{DESTDIR}/` prefix.
---
Even for relative paths this is prone to failure:
For a minimal CMakeLists (now with relative path)
```
project (hello)
add_executable(hello helloworld.cpp)
install (TARGETS hello DESTINATION "bin")
```
the following output is created in `cmake_install.cmake`
```
file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/bin" TYPE EXECUTABLE FILES "E:/Temp/Project/build/hello.exe")
if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/hello.exe" AND
NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/hello.exe")
if(CMAKE_INSTALL_DO_STRIP)
execute_process(COMMAND "C:/msys64/mingw64/bin/strip.exe" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/hello.exe")
endif()
endif()
```
As soon as `CMAKE_INSTALL_PREFIX` is set to an absolute path (for example the default `C:\Program Files`, but also pretty much any path variable CMake has to offer) the code will fail if `DESTDIR` is defined.
As a matter of fact I believe `${CMAKE_INSTALL_PREFIX}` even *has* to be absolute (unless I'm missing something) as relative paths would be relative to the root of the hard drive. (At least if I use `DCMAKE_INSTALL_PREFIX=""` in the example the executable ends up in `E:\bin\`)https://gitlab.kitware.com/cmake/cmake/-/issues/16850Ninja command concatenation incorrect on Windows2017-05-10T10:03:49-04:00Bernhard BurgermeisterNinja command concatenation incorrect on WindowsIf cmake needs to create a list of commands it creates one ninja command
```
cmd.exe /C "cmd1 && cmd2 && ..."
```
with cmdX being the complete command line including arguments. This fails if one of the cmdX contains the "||"-operator ...If cmake needs to create a list of commands it creates one ninja command
```
cmd.exe /C "cmd1 && cmd2 && ..."
```
with cmdX being the complete command line including arguments. This fails if one of the cmdX contains the "||"-operator for error handling, see attached [CMakeLists.txt](/uploads/a252026a3a7f5bae4e78684682d15f25/CMakeLists.txt). We use this to delete the target file if the first command fails in a POST_BUILD rule but here in the example it shows the effect without build too.
The attached project works correctly on Linux with Makefiles and Ninja and on Windows with NMake/JOM printing "first" and "second". But it fails on Windows with Ninja because of different preference of || and && operators in cmd.exe compared to Linux shell.
To fix this the commands can be grouped by brackets:
```
cmd.exe /C "( cmd1 ) && ( cmd2 ) && ..."
```
Currently we add these brackets manually as a workaround.
I can create a merge request to do this automatically if desired. Should the brackets by added always or only if || is contained?https://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.