CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-10-13T13:17:55-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16642Partial support of permissions on Windows (read-only attribute)2017-10-13T13:17:55-04:00ValentynPartial support of permissions on Windows (read-only attribute)The following works fine on Linux:
```
install (FILES "${SOME_PATH}"
DESTINATION "${SOME_DIRECTORY}"
PERMISSIONS OWNER_READ GROUP_READ WORLD_READ
COMPONENT SomeComponent)
```
It does not work on Windows. I can manually set read-onl...The following works fine on Linux:
```
install (FILES "${SOME_PATH}"
DESTINATION "${SOME_DIRECTORY}"
PERMISSIONS OWNER_READ GROUP_READ WORLD_READ
COMPONENT SomeComponent)
```
It does not work on Windows. I can manually set read-only attribute for a file or folder on Windows, so it would be nice if CMake partially supported Windows in this regard too.
We use this technique to prevent case when some header file is opened in IDE from installation directory, developer modifies it (thinking it is in the repo) and then these modifications are overwritten by the install.https://gitlab.kitware.com/cmake/cmake/-/issues/16637SWIG is not found in MINGw32/64 MSYS2 Environment by FindSWIG.cmake2019-05-27T15:35:12-04:00Andreas SauerSWIG is not found in MINGw32/64 MSYS2 Environment by FindSWIG.cmakeOS: Windows 7 Pro 64bit
When i try to generate a makefile with "cmake -G "MSYS Makefiles" -DCMAKE_FIND_ROOT_PATH=c:/msys64" SWIG_DIR is not found:
```
$ cmake -G "MSYS Makefiles" -DCMAKE_FIND_ROOT_PATH=c:/msys64
CMake Error at C:...OS: Windows 7 Pro 64bit
When i try to generate a makefile with "cmake -G "MSYS Makefiles" -DCMAKE_FIND_ROOT_PATH=c:/msys64" SWIG_DIR is not found:
```
$ cmake -G "MSYS Makefiles" -DCMAKE_FIND_ROOT_PATH=c:/msys64
CMake Error at C:/msys64/mingw64/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find SWIG (missing: SWIG_DIR)
Call Stack (most recent call first):
C:/msys64/mingw64/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
C:/msys64/mingw64/share/cmake-3.7/Modules/FindSWIG.cmake:63 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:10 (find_package)
-- Configuring incomplete, errors occurred!
```
The output of "swig -swiglib is correct:
```
$ swig -swiglib
/usr/share/swig/3.0.10
```
The problem is that "FindSWIG.cmake" don't allow a CMAKE_FIND_ROOT_PATH (Line 7 in FindSWIG.cmake):
```
find_path(SWIG_DIR swig.swg PATHS ${SWIG_swiglib_output} NO_CMAKE_FIND_ROOT_PATH)
```
After removing "NO_CMAKE_FIND_ROOT_PATH" all work fine:
```
$ cmake -G "MSYS Makefiles" -DCMAKE_FIND_ROOT_PATH=c:/msys64
-- Found SWIG: C:/msys64/usr/bin/swig.exe (found version "3.0.10")
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe
-- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/msys64/home/asa/git/GalvoControl/GalvoControl
```https://gitlab.kitware.com/cmake/cmake/-/issues/16626Console output slows down build process2017-10-13T13:17:55-04:00Patrick StorzConsole output slows down build processI'm using cmake version 3.6.2 on Windows.
I recently noticed (while building two projects at the same time) that console output is drastically slowing down the build process (i.e. the output actually appeared character for character wit...I'm using cmake version 3.6.2 on Windows.
I recently noticed (while building two projects at the same time) that console output is drastically slowing down the build process (i.e. the output actually appeared character for character with a delay of ~ 100 milliseconds) effectively halting the build process.
Even under normal conditions it makes a huge difference:
As an example when building Inkscape in the end over 3000 files are installed via the `install()` command which takes a long time. I compared running
`cmake.exe -P cmake_install.cmake` vs. `cmake.exe -P cmake_install.cmake > install.log`. First command executes for ~15 seconds outputting a wall of text, second command finishes almost immediately.
I see two things that can be done here
* Speed up console output for cmake (the "real" fix)
* As a workaround; Implement an easy way to silence the informational output of `file(INSTALL ..)` commands as produced by `install()` commands (as this is probably the most text-intensive part of most compilation runs while usually not prone to errors, i.e. output would not be necessary). If something like that exists please point me kindly into the correct direction as I wasn't able to find a solution without suppressing console output completely.https://gitlab.kitware.com/cmake/cmake/-/issues/16621-DCMAKE_INSTALL_UCRT_LIBRARIES=ON silently fails if installed Windows 10 SDK ...2017-10-13T13:17:55-04:00Vadim Chugunov-DCMAKE_INSTALL_UCRT_LIBRARIES=ON silently fails if installed Windows 10 SDK does not contain UCRT DLLsLLVM now uses include(InstallRequiredSystemLibraries) with -DCMAKE_INSTALL_UCRT_LIBRARIES=ON to package UCRT DLLs for use on down-level platforms.
Unfortunately, if the build machine does not have a sufficiently recent Windows 10 SDK (w...LLVM now uses include(InstallRequiredSystemLibraries) with -DCMAKE_INSTALL_UCRT_LIBRARIES=ON to package UCRT DLLs for use on down-level platforms.
Unfortunately, if the build machine does not have a sufficiently recent Windows 10 SDK (which includes the /Redist/ucrt/DLLs folder), CMAKE build silently ignores this problem and "succeeds" without including the required files.
It should emit an error, or at least a warning.https://gitlab.kitware.com/cmake/cmake/-/issues/16614CMakeCompilerId.cmake (share/cmake-3.7/Modules) Fails when run in Jenkins build2017-10-13T13:17:55-04:00patrickCMakeCompilerId.cmake (share/cmake-3.7/Modules) Fails when run in Jenkins buildI use git-bash bash shell when compiling cmake projects in windows. When I run cmake from bash shell it works fine, however when I run the same cmake with bash shell as jenkins job it fails. Log below.
I discovered that the length of...I use git-bash bash shell when compiling cmake projects in windows. When I run cmake from bash shell it works fine, however when I run the same cmake with bash shell as jenkins job it fails. Log below.
I discovered that the length of data returned in the line
file(READ ${file} peoffsethex LIMIT 1 OFFSET 60 HEX)
is shorted than expected, poffsethex from license file is empty.
When building regularly from shell, it appears that the license file is not even checked.
```
c:\jenkins_workspace\VT_R0>cd project_mw\verification_test
09:28:53
09:28:53 c:\jenkins_workspace\VT_R0\project_mw\verification_test>cmake . -G"Unix Makefiles" -DTARGET_CORE=0 -DTARGET_BUILD=ROM
09:28:53 -- Found metaware at C:/Users/Patrick.fitzpatrick/Metaware.2016.09/MetaWare/arc
09:28:54 READING OFFSET 60 from this FILE: C:/jenkins_workspace/VT_R0/project_mw/verification_test/CMakeFiles/3.7.2/CompilerIdC/.license_HCAC
09:28:54 CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeDetermineCompilerId.cmake:509 (string):
09:28:54 string begin index: 1 is out of range 0 - 0
09:28:54 Call Stack (most recent call first):
09:28:54 C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeDetermineCompilerId.cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK)
09:28:54 C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
09:28:54 CMakeLists.txt:17 (project)
[.license_HCAC](/uploads/e4cec30ec2eb2fcde418bb3cb8300129/.license_HCAC)
```https://gitlab.kitware.com/cmake/cmake/-/issues/16567cmake with HPE NonStop c/c++ cross-compilers2021-06-23T09:11:59-04:00Twoflowercmake with HPE NonStop c/c++ cross-compilersHi, trying cmake with HPE NonStop c/c++ cross-compilers on Windows. Any help will be valued. (I'll also be a free tester/coder if we can check something into cmake so that this can be used in the std. cmake version.)
Windows cmd line ...Hi, trying cmake with HPE NonStop c/c++ cross-compilers on Windows. Any help will be valued. (I'll also be a free tester/coder if we can check something into cmake so that this can be used in the std. cmake version.)
Windows cmd line see errors in attached files:
CMakeOutput.log
CMakeError.log
[CMakeError.log](/uploads/d4a8d56308d4cca97c1bfbbee1e10b74/CMakeError.log)[CMakeOutput.log](/uploads/aa6120eb2bf9c4cf4ab79fef62c32e0c/CMakeOutput.log):https://gitlab.kitware.com/cmake/cmake/-/issues/16520Implement a generator for the embedded IDE uVision2019-05-23T13:22:32-04:00Sebastian BøeImplement a generator for the embedded IDE uVisionKeil uVision is a windows-only IDE that is popular among embedded developers.Keil uVision is a windows-only IDE that is popular among embedded developers.https://gitlab.kitware.com/cmake/cmake/-/issues/16485Check path length in Windows to be shorter than MAX_PATH2017-10-13T13:17:55-04:00alihaCheck path length in Windows to be shorter than MAX_PATH> In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. [[msdn](https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365247(...> In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. [[msdn](https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath)]
This can cause a problem in complex projects, as I recently experienced it (as a result of this problem, Visual Studio could not find a dependency simply because the path was more than 260 characters).
IMHO, in Windows, when a path longer than MAX_PATH is detected, CMake should at least log a warning if not an error.https://gitlab.kitware.com/cmake/cmake/-/issues/16484BROKEN BOOST support (dynamic setup link to static libs names in visual studio)2017-10-13T13:17:55-04:00Petar PetrovBROKEN BOOST support (dynamic setup link to static libs names in visual studio)In my CMakeLists.txt
```
IF(NOT Boost_SOURCE_DIR)
set(Boost_DEBUG ON)
#TODO set exactly where to take boost from
#set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
#set(BOOST_ROOT "../boost")
set(Boost_USE_STATIC_LIBS OFF)
...In my CMakeLists.txt
```
IF(NOT Boost_SOURCE_DIR)
set(Boost_DEBUG ON)
#TODO set exactly where to take boost from
#set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
#set(BOOST_ROOT "../boost")
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
set(BOOST_ALL_DYN_LINK ON) # force dynamic linking for all libraries
add_definitions(${Boost_LIB_DIAGNOSTIC_DEFINITIONS})
find_package(Boost COMPONENTS serialization REQUIRED)
IF(Boost_FOUND)
message(STATUS "** Boost Include: ${Boost_INCLUDE_DIR}")
message(STATUS "** Boost Libraries: ${Boost_LIBRARY_DIRS}")
message(STATUS "** Boost Link-Libs: ${Boost_LIBRARIES}")
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
ENDIF(Boost_FOUND)
ENDIF(NOT Boost_SOURCE_DIR)
```
Output:
```
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:983 ] _boost_TEST_VERSIONS = 1.62.0;1.62;1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:985 ] Boost_USE_MULTITHREADED = ON
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:987 ] Boost_USE_STATIC_LIBS = OFF
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:989 ] Boost_USE_STATIC_RUNTIME = OFF
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:991 ] Boost_ADDITIONAL_VERSIONS =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:993 ] Boost_NO_SYSTEM_PATHS =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1061 ] Declared as CMake or Environmental Variables:
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1063 ] BOOST_ROOT =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1065 ] BOOST_INCLUDEDIR =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1067 ] BOOST_LIBRARYDIR =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1069 ] _boost_TEST_VERSIONS = 1.62.0;1.62;1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1162 ] location of version.hpp: C:/Users/p/Documents/NENA/boost_1_59_0/boost/version.hpp
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1186 ] version.hpp reveals boost 1.59.0
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1272 ] guessed _boost_COMPILER = -vc140
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1282 ] _boost_MULTITHREADED = -mt
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1326 ] _boost_RELEASE_ABI_TAG = -
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1328 ] _boost_DEBUG_ABI_TAG = -gd
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1384 ] _boost_LIBRARY_SEARCH_DIRS_RELEASE = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH_boost_LIBRARY_SEARCH_DIRS_DEBUG = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1523 ] Searching for SERIALIZATION_LIBRARY_RELEASE: boost_serialization-vc140-mt-1_59;boost_serialization-vc140-mt;boost_serialization-mt-1_59;boost_serialization-mt;boost_serialization
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:362 ] Boost_LIBRARY_DIR_RELEASE = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib _boost_LIBRARY_SEARCH_DIRS_RELEASE = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1565 ] Searching for SERIALIZATION_LIBRARY_DEBUG: boost_serialization-vc140-mt-gd-1_59;boost_serialization-vc140-mt-gd;boost_serialization-mt-gd-1_59;boost_serialization-mt-gd;boost_serialization-mt;boost_serialization
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:362 ] Boost_LIBRARY_DIR_DEBUG = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib _boost_LIBRARY_SEARCH_DIRS_DEBUG = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1635 ] Boost_FOUND = 1
Boost version: 1.59.0
Found the following Boost libraries:
serialization
** Boost Include: C:/Users/p/Documents/NENA/boost_1_59_0
** Boost Libraries: C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib
** Boost Link-Libs: optimized;C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib/boost_serialization-vc140-mt-1_59.lib;debug;C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib/boost_serialization-vc140-mt-gd-1_59.lib
```
However in Visual Studio 2015:
>LINK : fatal error LNK1104: cannot open file 'libboost_serialization-vc140-mt-gd-1_59.lib'https://gitlab.kitware.com/cmake/cmake/-/issues/16479RC: non-preprocessor dependencies of windows resource files don’t trigger res...2023-03-21T11:20:05-04:00Norbert PfeilerRC: non-preprocessor dependencies of windows resource files don’t trigger resource recompilationI have a windows resource file, which contains an icon and a manifest.
Whenever one of them changes, I want the resources to be recompiled.
Trying to find an answer to
[this](https://cmake.org/pipermail/cmake/2010-March/035725.html) ...I have a windows resource file, which contains an icon and a manifest.
Whenever one of them changes, I want the resources to be recompiled.
Trying to find an answer to
[this](https://cmake.org/pipermail/cmake/2010-March/035725.html) question,
I stumbled upon [OBJECT_DEPENDS](https://cmake.org/cmake/help/v3.7/prop_sf/OBJECT_DEPENDS.html)
which allows me to fix the issue.
But as the documentation suggests, it shouldn’t be necessary to do this manually.
out-of-the-box it neither works automatically with the `MinGW Makefiles` nor `Ninja` generators.https://gitlab.kitware.com/cmake/cmake/-/issues/16451FindCURL does not search `C:\Program Files (x86)\CURL`2017-10-13T13:17:55-04:00EthanFindCURL does not search `C:\Program Files (x86)\CURL`I have tried to install a couple of libraries that depend on libcurl. So I downloaded curl 7.51 and build and ran INSTALL.vcxproj and it installed fine.
However, when I run a cmake file that uses `find_package` to get CURL, it fails c...I have tried to install a couple of libraries that depend on libcurl. So I downloaded curl 7.51 and build and ran INSTALL.vcxproj and it installed fine.
However, when I run a cmake file that uses `find_package` to get CURL, it fails complaining it cannot find curl. cURL is installed in C:\Program Files (x86)\CURL for me. shouldn't cmake be looking for CURL in this standard path?
Am I doing something wrong?https://gitlab.kitware.com/cmake/cmake/-/issues/16437FindPythonInterp does not find Python3 installed to user-local directory on W...2018-03-06T09:26:04-05:00Ben BoeckelFindPythonInterp does not find Python3 installed to user-local directory on WindowsIt goes into `%USERPROFILE%\AppData\Local\Programs\Python\Python35\python.exe`, but is not found by default. `FindPythonLibs` works fine though.It goes into `%USERPROFILE%\AppData\Local\Programs\Python\Python35\python.exe`, but is not found by default. `FindPythonLibs` works fine though.https://gitlab.kitware.com/cmake/cmake/-/issues/16345Error reporting under Windows fails in command mode2021-03-11T08:59:24-05:00schaapError reporting under Windows fails in command modeIn a Windows command line, try:
```
cmake -E rename this_file_does_not_exist something_else
```
Your error response will be:
```
Error renaming from "this_file_does_not_exist" to "something_else": No error
```
Obviously the correct e...In a Windows command line, try:
```
cmake -E rename this_file_does_not_exist something_else
```
Your error response will be:
```
Error renaming from "this_file_does_not_exist" to "something_else": No error
```
Obviously the correct error would be that the source file does not exist.
This behaviour seems to stem from the use of errno under Windows in the function cmSystemTools::GetLastSystemError. While errno exists, it is apparently not reliable in returning the actual error. GetLastError() should probably be checked instead/as well.https://gitlab.kitware.com/cmake/cmake/-/issues/16342Ninja generator breaks when creating archives with GNU 'ar' in Windows2017-10-13T13:17:56-04:00Hai NguyenNinja generator breaks when creating archives with GNU 'ar' in WindowsThis is related to these issues:
https://cmake.org/Bug/view.php?id=15278
and https://cmake.org/Bug/view.php?id=15439#c38728
The variation to the above mentioned issue is the usage of Clang and GNU 'ar' instead of of GCC and GNU 'ar'...This is related to these issues:
https://cmake.org/Bug/view.php?id=15278
and https://cmake.org/Bug/view.php?id=15439#c38728
The variation to the above mentioned issue is the usage of Clang and GNU 'ar' instead of of GCC and GNU 'ar'.
Based on what I can tell from the second issue, the fix was to detect if GCC was present and a forward slash was to be used instead. If the same thing can be applied to clang, it would be useful. Or maybe instead of it being compiler dependent, it should just see if it's GNU 'ar' since that's the common denominator.
I've tested this on cmd.exe and Git for Windows bash shell.https://gitlab.kitware.com/cmake/cmake/-/issues/16339Improve default generator selection and make it configurable2020-05-13T09:34:20-04:00Jason JuangImprove default generator selection and make it configurableNow whenever I build a visual studio project I have to type `cmake .. -G "Visual Studio 14 Win64"` which is kind of tedious when compare to linux a simple `cmake ..` would work. Is there any way that I can set this up in my CMakeLists so...Now whenever I build a visual studio project I have to type `cmake .. -G "Visual Studio 14 Win64"` which is kind of tedious when compare to linux a simple `cmake ..` would work. Is there any way that I can set this up in my CMakeLists so when I type `cmake ..` it will generate 64 bit build by default?
I am using the latest cmake 3.6.2.
Related but unanswered: http://stackoverflow.com/questions/6430251/what-is-the-default-generator-for-cmake-in-windows
Thanks,
Jasonhttps://gitlab.kitware.com/cmake/cmake/-/issues/16329NDEBUG is defined for debug build with clang toolset2017-10-13T13:17:56-04:00Sven JohannsenNDEBUG is defined for debug build with clang toolsetIf I create a new Visual Studio (2015, Update3) project for the **clang toolset**:
cmake .. -G "Visual Studio 14 2015 Win64" -Tv140_clang_c2
**NDEBUG** is defined. (Inherited value, see property window)
tested with cmake 3.6.2If I create a new Visual Studio (2015, Update3) project for the **clang toolset**:
cmake .. -G "Visual Studio 14 2015 Win64" -Tv140_clang_c2
**NDEBUG** is defined. (Inherited value, see property window)
tested with cmake 3.6.2https://gitlab.kitware.com/cmake/cmake/-/issues/16321execute_process: Add option to execute a raw command line on Windows2022-07-20T12:56:42-04:00Vyacheslav Napadovskyexecute_process: Add option to execute a raw command line on Windows`execute_process` is unable to pass a unescaped quote symbol `"` as a parameter on Windows.
The quote just get escaped, i. e. instead `"` I get `\"` passed to created process parameters. I need to pass a clear quote.
How to reproduce:
...`execute_process` is unable to pass a unescaped quote symbol `"` as a parameter on Windows.
The quote just get escaped, i. e. instead `"` I get `\"` passed to created process parameters. I need to pass a clear quote.
How to reproduce:
1. Download [Process Monitor] (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx), so you'll be able to monitor raw parameters passed to created processes.
2. Create an `sample.cmake` file with following contents:
`execute_process(COMMAND $ENV{COMSPEC} "/C" "echo\"\"")`
3. Run Process Monitor, start capturing system events (it will start automatically after you press OK in filters window, after you can toggle it with `File->Capture Events`)
4. Run `cmake -P sample.cmake` in command prompt.
5. Stop capturing events, go to `Tools->Process Tree`, locate launched `cmd.exe` process with short lifetime, check it `Command` column value.
6. Expected value
`C:\Windows\System32\cmd.exe /C echo""`
gathered value
`C:\Windows\System32\cmd.exe /C echo\"\"`https://gitlab.kitware.com/cmake/cmake/-/issues/16282"cmake.exe -E __create_def" is crashing when adding /GL flag to CMAKE_CXX_FLA...2022-10-28T17:42:18-04:00Tadeu Manoel"cmake.exe -E __create_def" is crashing when adding /GL flag to CMAKE_CXX_FLAGS, for MSVC 2015When running this command in the pre-link step (from inside MSVC, when building a project), cmake is crashing, and it gives an error like this:
```
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128...When running this command in the pre-link step (from inside MSVC, when building a project), cmake is crashing, and it gives an error like this:
```
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: The command "setlocal
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: cd D:\build14
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: D:\bin\cmake.exe -E __create_def D:/build14/source/.../RelWithDebInfo//exportall.def D:/build14/source/.../RelWithDebInfo//objects.txt
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :cmEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :cmErrorLevel
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: exit /b %1
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :cmDone
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :VCEnd" exited with code -1073741819.
```https://gitlab.kitware.com/cmake/cmake/-/issues/16274cmake-3.5.1-win32-x86 installer doesn't add CMake to PATH2017-10-13T13:17:55-04:00GeorgePostolakiycmake-3.5.1-win32-x86 installer doesn't add CMake to PATH**OS:** Windows 10 and 7
*tested on system where only one user created*
**SToR:**
1. Download cmake-3.5.1-win32-x86 (https://cmake.org/files/v3.5/cmake-3.5.1-win32-x86.msi)
1. During installation choose: "Add CMake to the system ...**OS:** Windows 10 and 7
*tested on system where only one user created*
**SToR:**
1. Download cmake-3.5.1-win32-x86 (https://cmake.org/files/v3.5/cmake-3.5.1-win32-x86.msi)
1. During installation choose: "Add CMake to the system PATH for all users"
**Actual result:** CMake doesn't add to the system PATH
*Pay attention if you will choose: "Add CMake to the system PATH for the current user" - all will work good)*https://gitlab.kitware.com/cmake/cmake/-/issues/16269Clang/C2 -fno-delayed-template-parsing error with windows.h2017-10-13T13:17:56-04:00Jørgen IbsenClang/C2 -fno-delayed-template-parsing error with windows.hCompiling a file that includes windows.h with the latest Clang/C2 and MSVC 2015 Update 3 results in an error. Some experimentation indicates it may be `-fno-delayed-template-parsing`, but I don't know if removing that could introduce oth...Compiling a file that includes windows.h with the latest Clang/C2 and MSVC 2015 Update 3 results in an error. Some experimentation indicates it may be `-fno-delayed-template-parsing`, but I don't know if removing that could introduce other problems.
Example CMakeLists.txt:
~~~.cmake
cmake_minimum_required(VERSION 3.6)
project(foo CXX)
add_executable(foo foo.cpp)
~~~
and foo.cpp:
~~~.cpp
#include <windows.h>
int main() {}
~~~
Built with:
~~~.cmd
cmake -G "Visual Studio 14 2015" -T v140_clang_c2
cmake --build . --config Debug
~~~
Results in:
~~~
D:\Microsoft Visual Studio 14.0\VC\ClangC2\bin\x86\clang.exe -c -fdiagnostics
-format=msvc -target "i686-pc-windows-msvc" -I "D:\Microsoft Visual Studio 14
.0\VC\ClangC2\include" -I "D:\Microsoft Visual Studio 14.0\VC\include" -I "D:
\Microsoft Visual Studio 14.0\VC\atlmfc\include" -I "C:\Program Files (x86)\W
indows Kits\10\Include\10.0.10240.0\ucrt" -I "C:\Program Files (x86)\Windows
Kits\8.1\Include\um" -I "C:\Program Files (x86)\Windows Kits\8.1\Include\shar
ed" -I "C:\Program Files (x86)\Windows Kits\8.1\Include\winrt" -o "foo.dir\De
bug\foo.obj" -Wall -O3 -fno-strict-aliasing -fomit-frame-pointer -ffunction-s
ections -fdata-sections -fstack-protector -fpic -fno-short-enums -fno-rtti -D
_DEBUG -D "CMAKE_INTDIR=\"Debug\"" -D NDEBUG -D _MBCS -x c++ -fms-extensions
-fno-ms-compatibility -fdelayed-template-parsing -gline-tables-only -fno-in
line -O0 -fno-delayed-template-parsing -D_DEBUG -D_MT -D_DLL -Xclang --depen
dent-lib=msvcrtd -Xclang --dependent-lib=oldnames D:\dump\squash2\squash\t\fo
o.cpp
foo.cpp
In file included from D:\dump\squash2\squash\t\foo.cpp:1:
In file included from C:\Program Files (x86)\Windows Kits\8.1\Include\um\wind
ows.h:210:
In file included from C:\Program Files (x86)\Windows Kits\8.1\Include\um\ole2
.h:32:
In file included from C:\Program Files (x86)\Windows Kits\8.1\Include\um\objb
ase.h:27:
C:\Program Files (x86)\Windows Kits\8.1\Include\um\combaseapi.h(229,21): error
: unknown type name 'IUnknown' [D:\dump\squash2\squash\t\foo.vcxproj]
static_cast<IUnknown*>(*pp); // make sure everyone derives from IU
nknown
^
1 error generated.
~~~
If I build foo.cpp from the command line it fails with the same error when I pass `-fno-delayed-template-parsing`:
~~~.cmd
> "%VCINSTALLDIR%\ClangC2\bin\amd64\clang.exe" -fno-delayed-template-parsing foo.cpp
In file included from foo.cpp:1:
In file included from C:\Program Files (x86)\Windows Kits\8.1\include\\um\windows.h:210:
In file included from C:\Program Files (x86)\Windows Kits\8.1\include\\um\ole2.h:32:
In file included from C:\Program Files (x86)\Windows Kits\8.1\include\\um\objbase.h:27:
C:\Program Files (x86)\Windows Kits\8.1\include\\um\combaseapi.h:229:21: error:
unknown type name 'IUnknown'
static_cast<IUnknown*>(*pp); // make sure everyone derives fr...
^
1 error generated.
~~~