CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2021-10-04T10:39:53-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17242Need support for dynamic 'deployment content' for UWP/WinRT projects2021-10-04T10:39:53-04:00Brad DavisNeed support for dynamic 'deployment content' for UWP/WinRT projectsI'm working with a large Qt based project using CMake and Visual Studio 2017 (among other target platforms). We're trying to make our code work on the UWP/WinRT platform. Both Qt and CMake have functionality that allows us to look at a...I'm working with a large Qt based project using CMake and Visual Studio 2017 (among other target platforms). We're trying to make our code work on the UWP/WinRT platform. Both Qt and CMake have functionality that allows us to look at a built artifact and determine a set of dependency files we need to distribute with it (windeployqt for Qt and the BundleUtilities for CMake). Unfortunately I can't find an easy way to use these in a CMake generated Visual Studio project.
The problem is that the generated VS project builds the executable in the standard location, but then when you try to run a UWP app, it deploys the executable to a new directory. While we've been successful in the past using post-build commands to populate the build directory with all the required DLLs, those don't get copied in the deployment step so they're missing when you try to run as a UWP app and the app fails to launch.
If I create a Qt project file for UWP and use it to export a Visual Studio project, it resolves it with these targets in the generated project:
```
<Target Name="WinDeployQt_Debug|x64" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Inputs="$(OutDir)\$(TargetName).exe" Outputs="$(TargetName).windeployqt.$(Platform).$(Configuration)">
<Message Text="C:\qt\5.9.1\winrt_x64_msvc2017\bin\windeployqt.exe -qmldir C:\Users\bdavi\git\hifi\tests\uwp -list relative -dir "$(MSBuildProjectDirectory)" "$(OutDir)\$(TargetName).exe" > "$(TargetName).windeployqt.$(Platform).$(Configuration)"" />
<Exec Command="C:\qt\5.9.1\winrt_x64_msvc2017\bin\windeployqt.exe -qmldir C:\Users\bdavi\git\hifi\tests\uwp -list relative -dir "$(MSBuildProjectDirectory)" "$(OutDir)\$(TargetName).exe" > "$(TargetName).windeployqt.$(Platform).$(Configuration)"" />
</Target>
<Target Name="PopulateWinDeployQtItems_Debug|x64" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" AfterTargets="Link" DependsOnTargets="WinDeployQt_Debug|x64">
<ReadLinesFromFile File="$(TargetName).windeployqt.$(Platform).$(Configuration)">
<Output TaskParameter="Lines" ItemName="DeploymentItems" />
</ReadLinesFromFile>
<ItemGroup>
<None Include="@(DeploymentItems)">
<DeploymentContent>true</DeploymentContent>
</None>
</ItemGroup>
</Target>
```
The first target uses windeployqt.exe to both copy a bunch of files to the project directory AND write a file in the project directory containing the names of all the copied files. I can replicate this functionality with `add_custom_command`. The second part is more interesting. It reads the contents of the file and says that the list of files contained therein are to be considered deployment items, so they will be copied over along with the exe.
If I add this to my CMake file
```
add_custom_command(
TARGET ${TARGET_NAME}
POST_BUILD
COMMAND CMD /C "${WINDEPLOYQT_COMMAND} ${EXTRA_DEPLOY_OPTIONS} --dir . --list relative \"$<TARGET_FILE:${TARGET_NAME}>\" \> ${TARGET_NAME}.windeployqt.$<CONFIG>"
)
```
and then after cmake generation I manually paste that second target into my generated Visual Studio project file, then I'm able to run my UWP build.
However, what I'd like is some CMake specific mechanism for doing the same thing... basically specify either a file or a command where the contents of the file or the output of the command will be treated as deployment items by visual studio. Most likely it will need to be done in a context where it can accept generator expressions as well to differentiate the different requirements of debug and release builds.
It feels like being able to manipulate the set of files that are treated as deployable content for a given project is a critical feature of being able to build UWP projects. I get that `VS_DEPLOYMENT_CONTENT` provides much of this functionality, but as far as I can tell that only works if you're able / willing to determine the exact set of dependencies at CMake generation time. If you need to determine the content as a post-build step, there doesn't seem to be a way to do it right now using CMake.https://gitlab.kitware.com/cmake/cmake/-/issues/17206file(REAL_PATH), get_filename_component REALPATH not resolving symlinks in Wi...2024-01-09T07:21:56-05:00Manuel Núñezfile(REAL_PATH), get_filename_component REALPATH not resolving symlinks in Windowsget_filename_component REALPATH is reaturning the symlink path instead of the pointed file/directory path. I have a patch to make it work but after reviewing the issue #16926, I need to change my fix to rely in libuv instead of WindowsAP...get_filename_component REALPATH is reaturning the symlink path instead of the pointed file/directory path. I have a patch to make it work but after reviewing the issue #16926, I need to change my fix to rely in libuv instead of WindowsAPI.
On the other hand, does it require a new policy? get_filename_component documentation says nothing about not working in Windows so it seems more a bug than a behaviour change to me.https://gitlab.kitware.com/cmake/cmake/-/issues/17166note: class type 'cmsys::SystemTools::Stat_t {aka cmsys::_stat64}' is incomplete2017-08-15T11:29:22-04:00chris hawleynote: class type 'cmsys::SystemTools::Stat_t {aka cmsys::_stat64}' is incompletenot sure if I missed a step or this is an issue but here are the steps I used to setup my environment and run the build. I could not find this issue already reported but i could have missed it trying to read through all 1452 issues in a ...not sure if I missed a step or this is an issue but here are the steps I used to setup my environment and run the build. I could not find this issue already reported but i could have missed it trying to read through all 1452 issues in a reasonable amount of time.
version: cmake 3.9.1
source: github .zip release file
compiler: mingw gcc
os: windows 10
mingw setup
1. goto https://sourceforge.net/projects/mingw/files/Installer/mingw-get/
2. download mingw-get-setup
3. run the install
4. check the dev tools
5. apply changes
steps to get error
1. click "C:\MinGW\msys\1.0\msys.bat"
2. navigate to the extracted cmake source files
3. run ./bootsrap
4. observe errorhttps://gitlab.kitware.com/cmake/cmake/-/issues/17163MinGW Makefiles parallel builds cause the entire terminal to get colored2022-05-13T09:55:30-04:00Jamie SmithMinGW Makefiles parallel builds cause the entire terminal to get coloredThere seems to be some sort of race condition in the colored output in mingw32-make.
I am using CMake 3.9.1, and generating `MinGW Makefiles`. I have a pretty large project that takes maybe 10-15 minutes to build on a fast machine. Whe...There seems to be some sort of race condition in the colored output in mingw32-make.
I am using CMake 3.9.1, and generating `MinGW Makefiles`. I have a pretty large project that takes maybe 10-15 minutes to build on a fast machine. Whenever I run a parallel build (`make -j2`), after a minute or two, color will seem to "leak out" of one line of the build output. All text that was supposed to be white will become green, and the terminal prompt will also change color. Here's a screenshot of the point where it happened:
![mingw-color-glitch](/uploads/38452820e6f0ecb122113df1f7329047/mingw-color-glitch.png)
The more processes I use in the parallel build, the lest time it takes for the glitch to happen, which is why I think it's a race condition. With `cmd`, you could reset the color back to normal by running the command `color` (with no arguments), but in Powershell there is no way except restarting the shell. Now that PowerShell has replaced CMD, this has become extremely annoying.
Here's what the prompt looks like after the glitch:
![glitch-colored_prompt](/uploads/fb1fc43afccab831d57669f1e61f4d47/glitch-colored_prompt.png)
Can you please look into this? Thanks.https://gitlab.kitware.com/cmake/cmake/-/issues/17156CMake upgrade from 3.8 to 3.9: a gcc can't handle new build.make's way of com...2017-08-11T09:09:20-04:00Julius HänschCMake upgrade from 3.8 to 3.9: a gcc can't handle new build.make's way of committing objects (objects1.rsp)Hey everybody,
Since the upgrade from CMake 3.8 to 3.9, the way of committing objects to gcc changed from:
`gcc.exe -some_options &(PROJECTS_NAME_OBJECTS) $(PROJECTS_NAME_EXTERNAL_OBJECTS) -far_more_options`
to
`gcc.exe -some_optio...Hey everybody,
Since the upgrade from CMake 3.8 to 3.9, the way of committing objects to gcc changed from:
`gcc.exe -some_options &(PROJECTS_NAME_OBJECTS) $(PROJECTS_NAME_EXTERNAL_OBJECTS) -far_more_options`
to
`gcc.exe -some_options @CMakeFiles/PROJECTS_NAME.dir/objects1.rsp -far_more_options`
Most of our gcc compilers can handle this, but one of the compilers does not and returns:
`cannot find CMakeFiles/PROJECTS_NAME.dir/path/to/last_object_in_list.c.o: Invalid argument`
Is there a possibility to switch back to the old behaviour in the project or do we have to stay with the old CMake version?
Thank you very much!https://gitlab.kitware.com/cmake/cmake/-/issues/17155fixup_bundle issue with msys2 because compiler test executables not deleted2017-08-10T09:30:59-04:00Clément Grégoirefixup_bundle issue with msys2 because compiler test executables not deletedI'm having an issue with a sample application and fixup_bundle using msys2 and the "MSYS Makefiles" generator.
When runnning fixup_bundle it seems to say that some dependencies were not copied, and somehow tries to fixup executables that...I'm having an issue with a sample application and fixup_bundle using msys2 and the "MSYS Makefiles" generator.
When runnning fixup_bundle it seems to say that some dependencies were not copied, and somehow tries to fixup executables that are not in my cmakelists.txt (nor in the fixup_bundle arguments)
From what I'm seeing in BundleUtilities.cmake, it tries to list all the executables of the bundle, and detects the compiler ID executables (which used to be removed after generation ? Not sure).
I'm using the fixup_bundle on an executable still in the build directory (mainly to fix the visual studio missing dlls when debugging).
If I delete CMakeFiles/3.9.0/CompilerIdC/a.exe a,d CMakeFiles/3.9.0/CompilerIdCXX/a.exe it works perfectly fine.
A quick fix would perhaps be to add "a.exe" to the IGNORE_ITEM parameter but I'm not sure if it's the proper way to do it
## The log :
-- fixup_bundle
-- app='D:/Perso/boilerplate/buildmsys/BoilerPlate.exe'
-- libs=''
-- dirs=''
-- ignoreItems=''
-- fixup_bundle: preparing...
-- fixup_bundle: copying...
-- 1/10: *NOT* copying 'D:/Perso/boilerplate/buildmsys/BoilerPlate.exe'
-- 2/10: copying 'D:/Perso/boilerplate/buildmsys/msys-2.0.dll'
-- warning: resolved_item == resolved_embedded_item - not copying...
-- 3/10: copying 'D:/Perso/boilerplate/buildmsys/msys-gcc_s-seh-1.dll'
-- warning: resolved_item == resolved_embedded_item - not copying...
-- 4/10: copying 'D:/Perso/boilerplate/buildmsys/msys-stdc++-6.dll'
-- warning: resolved_item == resolved_embedded_item - not copying...
-- 5/10: *NOT* copying 'D:/Perso/boilerplate/buildmsys/CMakeFiles/3.9.0/CompilerIdC/a.exe'
-- fixup_bundle: fixing...
-- 6/10: fix-up not required on this platform 'D:/Perso/boilerplate/buildmsys/BoilerPlate.exe'
-- 7/10: fix-up not required on this platform 'D:/Perso/boilerplate/buildmsys/msys-2.0.dll'
-- 8/10: fix-up not required on this platform 'D:/Perso/boilerplate/buildmsys/msys-gcc_s-seh-1.dll'
-- 9/10: fix-up not required on this platform 'D:/Perso/boilerplate/buildmsys/msys-stdc++-6.dll'
-- 10/10: fix-up not required on this platform 'D:/Perso/boilerplate/buildmsys/CMakeFiles/3.9.0/CompilerIdC/a.exe'
-- fixup_bundle: cleaning up...
-- fixup_bundle: verifying...
-- ===========================================================================
-- Analyzing app='D:/Perso/boilerplate/buildmsys/BoilerPlate.exe'
-- bundle='D:/Perso/boilerplate/buildmsys'
-- executable='D:/Perso/boilerplate/buildmsys/BoilerPlate.exe'
-- valid='1'
-- executable file 1: D:/Perso/boilerplate/buildmsys/BoilerPlate.exe
-- executable file 2: D:/Perso/boilerplate/buildmsys/CMakeFiles/3.9.0/CompilerIdC/a.exe
-- executable file 3: D:/Perso/boilerplate/buildmsys/CMakeFiles/3.9.0/CompilerIdCXX/a.exe
-- verified='0'
-- info='external prerequisites found:
f='D:/Perso/boilerplate/buildmsys/CMakeFiles/3.9.0/CompilerIdC/a.exe'
external_prereqs='msys-2.0.dll'
;external prerequisites found:
f='D:/Perso/boilerplate/buildmsys/CMakeFiles/3.9.0/CompilerIdCXX/a.exe'
external_prereqs='msys-2.0.dll'
'
--
CMake Error at C:/Program Files/CMake/share/cmake-3.9/Modules/BundleUtilities.cmake:1106 (message):
error: verify_app failed
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.9/Modules/BundleUtilities.cmake:964 (verify_app)
D:/Perso/boilerplate/cmake/RunFixupBundle.cmake:13 (fixup_bundle)
## Test project is available here :
https://github.com/Lectem/cpp-boilerplate
## Configured with :
cmake -G"MinGW Makefiles" -DENABLE_LTO=FALSE ..
## CMake version
cmake version 3.9.0
Thankshttps://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/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/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/16809Request: Update Visual Studio generators with Linux X-platform project genera...2022-03-30T15:30:37-04:00Robert BielikRequest: Update Visual Studio generators with Linux X-platform project generationhttps://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/https://gitlab.kitware.com/cmake/cmake/-/issues/16771cmake GNU makefile link too long commandline2017-08-15T09:20:47-04:00STAUB Juliencmake GNU makefile link too long commandlinecmake generated a makefile line that is about 8400 characters long for the link step. Too long for windows limit.
the file build.make contains :
```
XXXXX_EXTERNAL_OBJECTS =
XXXX_OBJECTS = \
"file.c.obj" \
"file.c.obj" \
"file.c.obj" \...cmake generated a makefile line that is about 8400 characters long for the link step. Too long for windows limit.
the file build.make contains :
```
XXXXX_EXTERNAL_OBJECTS =
XXXX_OBJECTS = \
"file.c.obj" \
"file.c.obj" \
"file.c.obj" \
"file.c.obj" \
C:/YYYY/GNU_Tools_ARM_Embedded/6-2016-q4-major/bin/arm-none-eabi-gcc.exe -mcpu=cortex-m4 -mthumb -DSTM32L496xx -mfloat-abi=softfp -DXXXX -O0 -g -Wfatal-errors -Wall -Wno-unused-function -std=c99 -fdata-sections -ffunction-sections -mcpu=cortex-m4 -march=armv7e-m -O0 -g --specs=nano.specs -mthumb -Wl,--gc-sections -nostartfiles -Wl,-Map=$@.map -TC:SSSSSSSSS/STM32L496RGTx_FLASH.ld $(XXXX_OBJECTS) $(XXXXX_EXTERNAL_OBJECTS) -o outHexFile_XXXX -LC:/YYYYYYYYYYYYYYYY/arm-nano-eabi/lib
```
XXXX_OBJECTS is about 7700 char and this leads to total 8400 char in command line making link fail.https://gitlab.kitware.com/cmake/cmake/-/issues/16762CMakeFindBinUtils: issue with GNU/Clang-like toolchain on a Visual Studio pla...2017-08-15T09:20:48-04:00Daniele E. DomenichelliCMakeFindBinUtils: issue with GNU/Clang-like toolchain on a Visual Studio platformin [Modules/CMakeFindBinUtils.cmake](https://gitlab.kitware.com/cmake/cmake/blob/v3.8.0-rc4/Modules/CMakeFindBinUtils.cmake#L22), it is impossible to detect automatically the `ar`, `ranlib`, ecc programs on a GNU/Clang-like toolchain on ...in [Modules/CMakeFindBinUtils.cmake](https://gitlab.kitware.com/cmake/cmake/blob/v3.8.0-rc4/Modules/CMakeFindBinUtils.cmake#L22), it is impossible to detect automatically the `ar`, `ranlib`, ecc programs on a GNU/Clang-like toolchain on a Visual Studio platform just using a toolchain (i.e. if I understand it correctly, something similar to the "Tegra-Android" platform.
```cmake
# if it's the MS C/CXX compiler, search for link
if("x${CMAKE_C_SIMULATE_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_CXX_SIMULATE_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_Fortran_SIMULATE_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_C_COMPILER_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_CXX_COMPILER_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_CUDA_SIMULATE_ID}" STREQUAL "xMSVC"
OR (CMAKE_GENERATOR MATCHES "Visual Studio"
AND NOT CMAKE_VS_PLATFORM_NAME STREQUAL "Tegra-Android"))
```
There is a way to force entering this `if` (using the `_SIMULATE_ID`, variables) but there is no way to skip this check and to jump to the search.https://gitlab.kitware.com/cmake/cmake/-/issues/16759VS2017: could not be found if installed in non-default location (Windows 7/8....2017-08-15T09:20:48-04:00HarpyWarVS2017: could not be found if installed in non-default location (Windows 7/8.1/2008)Just for note that the issue should be resolved.
The discussion was here https://cmake.org/pipermail/cmake/2017-March/065198.htmlJust for note that the issue should be resolved.
The discussion was here https://cmake.org/pipermail/cmake/2017-March/065198.htmlhttps://gitlab.kitware.com/cmake/cmake/-/issues/16714Using Intel Fortran on Windows with NMake generator fails to detect the linke...2017-10-13T13:17:55-04:00Javier MartínUsing Intel Fortran on Windows with NMake generator fails to detect the linker versionWhen using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS20...When using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS2008, so the linker used is able to generate and embed a manifest into binaries. However, since the activation of this feature depends on MSVC_VERSION and this variable gets a "wrong", low value, the manifest embedding is not enabled and instead, the linker generates both my out.exe and an out.exe.manifest file. By contrast, if the VS 2008 generator is used instead of the "NMake Makefiles" generator, the rules for manifest embedding are generated.
The problem can be reproduced as follows:
* Environment: Windows computer with Intel Fortran 12.0 with MS Visual Studio 2008 _shell_ - it has link.exe (9.0) but not the corresponding cl.exe (15.0)
* Project: any simple "hello world" Fortran project will do. I am just doing `project(out Fortran)` and then `add_executable(out hello.f90)`.
* Configuration: I configure and generate the project with two generators, "Visual Studio 9 2008" and "NMake Makefiles" (the latter from the command line created by the Intel Fortran-provided equivalent to vcvars.bat)
* Result: the VS project generates out.exe, which has an embedded manifest; while the makefile version generates out.exe _without_ an embedded manifest _and_ an out.exe.manifest alongside it. In order for the latter executable to be usable, the manifest file must either be copied alongside the binary, or manually embedded with a call to mt.exe.
* Expected result: both generators result in executable files with embedded manifests.
I traced the problem to the fact that `Modules/Platforms/Windows-MSVC.cmake` (which is included by `Windows-Intel.cmake`) tests the `MSVC_VERSION` variable (the version of *cl.exe*) and only enables the manifest embedding if it at least 1400, the version of cl that comes with VS 2005.
This variable is defined above in the same file; in this case it is set from the value of the `CMAKE_Fortran_SIMULATE_VERSION` variable, which comes from data extracted from the Intel Fortran compiler by building and running `CMakeFortranCompilerId.F.in`. The problem is that, while Intel Fortran in Windows does report the \_MSC_VER macro, it reports *the same version reported by cl.exe*. Since in my case there is no cl.exe to be found, ifort reports _MSC_VER=1020, which is so old that it is stored by CMake as 1300. Thus, the manifest embedding feature is not enabled.
Since having the Intel Fortran compiler without the MS _C compiler_ is a valid configuration, the condition for the manifest embedding feature should depend on detecting features from the linker itself, not the C compiler.https://gitlab.kitware.com/cmake/cmake/-/issues/16688Windows: Warn when TEMP directory is not writable2017-10-13T13:17:55-04:00Dan KegelWindows: Warn when TEMP directory is not writableA trivial C project configured fine on all my boxes but one, where cmake complained
```No CMAKE_C_COMPILER could be found``` and ```No CMAKE_CXX_COMPILER could be found```
CMakeError.log showed the compiler id check program failed to...A trivial C project configured fine on all my boxes but one, where cmake complained
```No CMAKE_C_COMPILER could be found``` and ```No CMAKE_CXX_COMPILER could be found```
CMakeError.log showed the compiler id check program failed to
compile; it was located in c:\windows\temp. I looked there, and found
I couldn't even read that directory. Executing
```cacls C:\Windows\Temp /E /G everyone:F```
as administrator made the pain go away.
IIRC CMakeError.log also contained the odd message
```error MSB4036: The "SetEnvironmentVariable" task was not found.```
which may be another telltale for this problem.
Suggestion: when issuing the error "No CMAKE_C_COMPILER could be found" on windows, consider hinting to the user that making c:\windows\temp writeable may help?
This was with Windows 10, Visual Studio 2015, and several versions of cmake (3.6.2 to the latest release). I think I've seen it before with older versions of Visual Studio in the past.