CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-05-06T17:00:18-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16487find_package(Matlab) doesn't work with the MCR2018-05-06T17:00:18-04:00Patrik Huberfind_package(Matlab) doesn't work with the MCRHi,
There's this thing called the Matlab Compiler Runtime (MCR - https://www.mathworks.com/products/compiler/mcr.html). It's freely downloadable and includes the Matlab headers and libraries so that one can build Matlab mex-files, witho...Hi,
There's this thing called the Matlab Compiler Runtime (MCR - https://www.mathworks.com/products/compiler/mcr.html). It's freely downloadable and includes the Matlab headers and libraries so that one can build Matlab mex-files, without having to have the "full" Matlab program (and a license for it).
However, CMake's `find_package(Matlab)` seems to work only with a "full" Matlab installation and not with the MCR, even though the MCR is completely sufficient to for example build mex files.
If you have this in a CMakeLists.txt: `find_package(Matlab COMPONENTS MX_LIBRARY REQUIRED)`
And you do
`cmake -G "Visual Studio 14 Win64" ..\myproj_source -DMatlab_ROOT_DIR=C:\MCR_2016b\v91`, it gives an error:
```
CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/FindMatlab.cmake:575 (string):
string sub-command STRIP requires two arguments.
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.7/Modules/FindMatlab.cmake:1353 (matlab_get_mex_suffix)
matlab/CMakeLists.txt:5 (find_package)
CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find Matlab (missing: Matlab_MEX_EXTENSION)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.7/Modules/FindMatlab.cmake:1504 (find_package_handle_standard_args)
matlab/CMakeLists.txt:5 (find_package)
-- Configuring incomplete, errors occurred!
See also "C:/myproj/build/CMakeFiles/CMakeOutput.log".
```
You can make the error go away by additionally specifying `-DMatlab_MEX_EXTENSION=mexw64` but I believe this is an ugly hack because the CMake documentation itself says [here](https://cmake.org/cmake/help/v3.7/module/FindMatlab.html#cached-variables) that this should be determined by the installed Matlab.
I think this use case should definitely be made to work, since `FindMatlab` has actually awesome mex support: For example I think CMake 3.7 added `matlab_add_mex(...)`, which I must say is pretty awesome for generating Matlab bindings for C++ code :-)
And I think the FindMatlab script has already some support for the MCR or something like that, since for example `MAIN_PROGRAM` (which would be Matlab.exe) is only defined/returned if you explicitly request it (at least the CMake documentation says that).
Additionally, for example on travis/AppVeyor the only way to test mex bindings is with the MCR, since a full Matlab installation is not an option for licensing reasons.Raffi EnficiaudRaffi Enficiaudhttps://gitlab.kitware.com/cmake/cmake/-/issues/16486bug in cpack deb generator if "file" not available2017-05-04T16:23:53-04:00Henning Meyerbug in cpack deb generator if "file" not availablethe CPack DEB generator executes the file tool to determine whether a
file is executable
this is a snippet from CPackDeb.cmake from cmake gitlab master:
```
# get file info so t`hat we can determine if file is executable or not
unse...the CPack DEB generator executes the file tool to determine whether a
file is executable
this is a snippet from CPackDeb.cmake from cmake gitlab master:
```
# get file info so t`hat we can determine if file is executable or not
unset(CPACK_DEB_INSTALL_FILES)
foreach(FILE_ IN LISTS FILE_PATHS_)
execute_process(COMMAND file "./${FILE_}"
WORKING_DIRECTORY "${WDIR}"
OUTPUT_VARIABLE INSTALL_FILE_)
list(APPEND CPACK_DEB_INSTALL_FILES "${INSTALL_FILE_}")
endforeach()
# Only dynamically linked ELF files are included
# Extract only file name infront of ":"
foreach(_FILE IN LISTS CPACK_DEB_INSTALL_FILES)
if(_FILE MATCHES "ELF.*dynamically linked")
string(REGEX MATCH "(^.*):" _FILE_NAME "${_FILE}")
list(APPEND CPACK_DEB_BINARY_FILES "${CMAKE_MATCH_1}")
set(CONTAINS_EXECUTABLE_FILES_ TRUE)
endif()
if(_FILE MATCHES "ELF.*shared object")
string(REGEX MATCH "(^.*):" _FILE_NAME "${_FILE}")
list(APPEND CPACK_DEB_SHARED_OBJECT_FILES "${CMAKE_MATCH_1}")
endif()
endforeach()
```
The problem is that `execute_process(COMMAND file)` may fail, and if it
does, we do not add the dependencies of that executable to the generated
deb file. This issue happened to us because our continuous integration
system tried building inside a minimal docker image, where `/usr/bin/file`
was simply not available, but it might fail for other reasons too: for
example strange things in the user's path, open file limit exceeded or
out of memory conditions.
I would therefore much prefer if the above code:
1) uses a variable `${FILE_EXECUTABLE}` for the file tool defaulting to
`/usr/bin/file` similar to the way it uses the variable
`${READELF_EXECUTABLE}` for the `readelf` tool
2) checks the return code on every iteration of the `foreach()` loop, and
calls `message(FATAL_ERROR)` if it is non-zero.3.8.0Domen VrankarDomen Vrankarhttps://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/164833.7.1 broke support for Microsoft Windows SDK for Windows 72017-05-04T16:23:53-04:00Mohamed Hassan3.7.1 broke support for Microsoft Windows SDK for Windows 7I try to build simple project using version 3.7.1-win64-x64 in windows 7 64 bit with windows SDK 7.1 installed (no visual studio 2010 installed)
The demo project is available at: http://pastebin.com/EFfj4yX3, and the attach contain ...I try to build simple project using version 3.7.1-win64-x64 in windows 7 64 bit with windows SDK 7.1 installed (no visual studio 2010 installed)
The demo project is available at: http://pastebin.com/EFfj4yX3, and the attach contain all source and generated files.
In the shortcut "Windows SDK 7.1 Command Prompt", I run the command :
**cmake -G "Visual Studio 10 Win64" .**
I get error:
```
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "C:/tutor/lab1/CMakeFiles/CMakeOutput.log".
See also "C:/tutor/lab1/CMakeFiles/CMakeError.log".
```
----------------------------------------------------------------------------------------
**When using the version : cmake-3.6.3-win64-x64 , it success, with the result:**
```
-- The C compiler identification is MSVC 16.0.30319.1
-- The CXX compiler identification is MSVC 16.0.30319.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.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:/tutor/lab1
The error in CMakeError.log is dute to not finding WindowsSDKDir, as described in the following line:
```
```
"C:\tutor\lab1\CMakeFiles\3.7.1\CompilerIdC\CompilerIdC.vcxproj" (default target) (1) ->
(PrepareForBuild target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(297,5): warning MSB8003: Could not find WindowsSDKDir variable from the registry.
TargetFrameworkVersion or PlatformToolset may be set to an invalid version number. [C:\tutor\lab1\CMakeFiles\3.7.1\CompilerIdC\CompilerIdC.vcxproj]
```3.7.2Brad 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/16481CMake add_custom_target adds nonexistent file to ide2017-10-13T13:17:55-04:00DrPepperJoCMake add_custom_target adds nonexistent file to ideCMake adds a nonexistent file named "${CMAKE_BINARY_DIR}/CMakeFiles/testtarget" to (VS2015) if the following (stripped-down) script is run.
> cmake_minimum_required( VERSION 3.7.0 )
> project( test_sample VERSION 0.1 LANGUAGES CXX...CMake adds a nonexistent file named "${CMAKE_BINARY_DIR}/CMakeFiles/testtarget" to (VS2015) if the following (stripped-down) script is run.
> cmake_minimum_required( VERSION 3.7.0 )
> project( test_sample VERSION 0.1 LANGUAGES CXX )
> add_custom_target( testtarget COMMAND dir )https://gitlab.kitware.com/cmake/cmake/-/issues/16480file(LOCK GUARD FILE): Crashes in script mode2023-02-27T10:51:11-05:00Egor Puginfile(LOCK GUARD FILE): Crashes in script modeAssertion failed at `cmFileLockPool.cxx:63`.
Repro:
1. Create `my.cmake`.
2. Write:
```
file(
LOCK a
GUARD FILE
RESULT_VARIABLE lock_result
)
```
3. Run `cmake -P my.cmake`.
cmake 3.7.1, any configuration
debug calls abor...Assertion failed at `cmFileLockPool.cxx:63`.
Repro:
1. Create `my.cmake`.
2. Write:
```
file(
LOCK a
GUARD FILE
RESULT_VARIABLE lock_result
)
```
3. Run `cmake -P my.cmake`.
cmake 3.7.1, any configuration
debug calls abort()
release is crashed because container is emptyhttps://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/16478Target property VS_DEBUGGER_WORKING_DIRECTORY is too specific2023-09-03T15:43:48-04:00Raul Tambreraul@tambre.eeTarget property VS_DEBUGGER_WORKING_DIRECTORY is too specificMany IDEs have an option to set the debugger working directory. I don't think this option should be restricted only to Visual Studio, as the name would indicate.Many IDEs have an option to set the debugger working directory. I don't think this option should be restricted only to Visual Studio, as the name would indicate.https://gitlab.kitware.com/cmake/cmake/-/issues/16477Ninja: ninja clean doesn't trigger cmake generation when cmake file changes2017-05-04T16:23:53-04:00Kavi JivanNinja: ninja clean doesn't trigger cmake generation when cmake file changeshttps://gitlab.kitware.com/cmake/cmake/-/issues/16476Windows: Record CMake installation in a stable registry value2017-05-04T16:23:53-04:00Ken Phillis JrWindows: Record CMake installation in a stable registry valueCurrently it is incredibly difficult to automatically detect that cmake is installed using the windows registry due to the fact that the installer has changed once already, and the path used in-registry for cmake has varied. This suggest...Currently it is incredibly difficult to automatically detect that cmake is installed using the windows registry due to the fact that the installer has changed once already, and the path used in-registry for cmake has varied. This suggestion is to simply add a couple of registry keys to make it extremely easy to find out if CMake is installed on a system. This is meant to be used by scripts on windows to find CMake and then run the program. To my knowledge WiX supports [writing registry Keys during Install](http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/write_a_registry_entry.html).
For this bug to be resolved, the Installer needs to place the registry keys in the path defined by the [CMake Package Registry tutorial](https://cmake.org/Wiki/CMake/Tutorials/Package_Registry). This means the following is supposed to happen.
* Windows (System Install) needs to specify a key under the registry path ``` HKEY_LOCAL_MACHINE\Software\Kitware\CMake\ ```. A good key for this would be to have the key name be ```InstallLocation``` and the value of this key specify where CMake is installed. Most of the time this will be the default value ```C:\Program Files (x86)\CMake\```, however if the user changed the location during Install, the value of this key is where the program was installed.
* Windows ( User/Portable Install ) - This is the same as the the Windows System Install, but instead the key is located under the registry path ``` HKEY_LOCAL_MACHINE\Software\Kitware\CMake\```.
* Non-Windows (System Install) - This does not need to be addressed since most installs outside of windows makes it easy to find cmake since the install location is under the system paths by default.
* Non-Windows (User/Portable Install) - This is also not an issue since users outside of windows will rarely use this option.3.8.0Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/16475cmake-gui: misleading help string on toolset selection field2017-05-24T09:44:08-04:00Karaulovcmake-gui: misleading help string on toolset selection fieldError at search C/CPP compilers: "8.1 sdk not found" , but i have only v141_xp toolset and 7.0 sdk. How to "Configure" cmake for using v141_xp 7.0SDK VS 2017 RC?Error at search C/CPP compilers: "8.1 sdk not found" , but i have only v141_xp toolset and 7.0 sdk. How to "Configure" cmake for using v141_xp 7.0SDK VS 2017 RC?3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16474Endless recursive macros results in SEGFAULT2023-12-11T12:09:50-05:00Dennis GuseEndless recursive macros results in SEGFAULTI implemented a macro and, by accident, it called itself.
If this occurs, cmake segfaults.
I know it is more a programming mistake by me, but somehow unexpected behavior.
Tested with>
* cmake 3.5.2 (Ubuntu) [Generator Unix Makefiles]
* ...I implemented a macro and, by accident, it called itself.
If this occurs, cmake segfaults.
I know it is more a programming mistake by me, but somehow unexpected behavior.
Tested with>
* cmake 3.5.2 (Ubuntu) [Generator Unix Makefiles]
* cmake 3.7.0 (Windows) [Generator MinGW Makefiles]
```
macro(MY_MACRO _name)
MY_MACRO(${ARGV})
endmacro()
MY_MACRO(SOMETHING)
```
Output on Ubuntu using 3.5.2:
```
dennis@noname:~/hack/cmake$ cmake .
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- 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: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Segmentation fault (core dumped)
```https://gitlab.kitware.com/cmake/cmake/-/issues/16473Feature request: Exporting symbols from static libraries linked with executab...2020-02-06T13:26:10-05:00Bertrand BellenotFeature request: Exporting symbols from static libraries linked with executable/dllWe (cling/ROOT projects on Windows) would need to export symbols coming not only from object files, but also from static (e.g. system) libraries from our executable, and to do so, we would need to pass one (or more) .def files containing...We (cling/ROOT projects on Windows) would need to export symbols coming not only from object files, but also from static (e.g. system) libraries from our executable, and to do so, we would need to pass one (or more) .def files containing the list of symbols to export. Since the MS linker only support one single .def file, would it be possible for us to specify one (or more) extra .def file in a CMakeLists.txt and let CMake to somehow merge them into the final generated one (exportall.def)?
Something like this:
```
if(MSVC)
set_target_properties(cling PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS 1)
set_property(TARGET cling APPEND_STRING PROPERTY DEF_FILES " filename1.def filename2.def ... filenameN.def ")
endif(MSVC)
```
And this would somehow merge filename1.def, filename2.def ... filenameN.def into the exportall.def (generated by WINDOWS_EXPORT_ALL_SYMBOLS) and then passed to the linker...
That would be very useful. Thanks in advance!
Cheers, Bertrand.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16472clang-c2 and c++142017-05-04T16:23:53-04:00Clément Grégoireclang-c2 and c++14When using clang-c2 (-T v140_clang_c2) with VS2015 Update 3, CMake 3.7.1 :
` set(CMAKE_CXX_STANDARD 14)`
will not set the c++14 flags (-std=c++14) while the compiler is recognized as clang :
```
The C compiler identification is Cl...When using clang-c2 (-T v140_clang_c2) with VS2015 Update 3, CMake 3.7.1 :
` set(CMAKE_CXX_STANDARD 14)`
will not set the c++14 flags (-std=c++14) while the compiler is recognized as clang :
```
The C compiler identification is Clang 3.8.0
The CXX compiler identification is Clang 3.8.0
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/x86/clang.exe
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/x86/clang.exe -- works
```https://gitlab.kitware.com/cmake/cmake/-/issues/16471Add %ONLY alternative for configure_file command2021-10-08T10:47:54-04:00Konstantin PodsvirovAdd %ONLY alternative for configure_file commandUncomfortable now create templates for file which themselves use `@` (the dog) to separate the variables.
For example, this occurs in QtIFW scripts for components and installer (for example, see [QtSDK](http://code.qt.io/cgit/qtsdk/qtsd...Uncomfortable now create templates for file which themselves use `@` (the dog) to separate the variables.
For example, this occurs in QtIFW scripts for components and installer (for example, see [QtSDK](http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/configurations/pkg_templates) templates).
Now I have to set a variable to a value `set(VAR "@VAR@")` that would get the same result.
The alternative use of the `%` symbol and leave `@VAR@` variables as there.
Who is for and who is against?https://gitlab.kitware.com/cmake/cmake/-/issues/16470CMake 3.7.0 for Windows: CMAKE_STANDARD_LIBRARIES not defined2017-05-04T16:23:53-04:00Dennis GuseCMake 3.7.0 for Windows: CMAKE_STANDARD_LIBRARIES not defined`CMAKE_STANDARD_LIBRARIES` is not defined on Windows (CMake 3.7.0 x64).
It does not show in `cmake --help-variable-list` and if set information is not passed to the linker.
Using Cmake 3.5.2 on Ubuntu 16.10 at least shows the help.
`d...`CMAKE_STANDARD_LIBRARIES` is not defined on Windows (CMake 3.7.0 x64).
It does not show in `cmake --help-variable-list` and if set information is not passed to the linker.
Using Cmake 3.5.2 on Ubuntu 16.10 at least shows the help.
`dennis@noname:~$ cmake --help-variable CMAKE_STANDARD_LIBRARIES
CMAKE_STANDARD_LIBRARIES
------------------------
Libraries linked into every executable and shared library.
This is the list of libraries that are linked into all executables and
libraries.`
However, this variable is not described as platform specific: https://cmake.org/cmake/help/v3.0/variable/CMAKE_STANDARD_LIBRARIES.html
Is this an issue or did I miss something?https://gitlab.kitware.com/cmake/cmake/-/issues/16469Problem using NASM on Visual Studio target (CMake v3.7)2019-03-05T06:32:31-05:00Robert BielikProblem using NASM on Visual Studio target (CMake v3.7)I'm adding NASM assembly files with:
```
enable_language(ASM_NASM)
...
add_library(test STATIC rdrand-x86_64.asm)
```
The NASM assembler is found, but the target generates the following vcxproj entries:
```
<ItemGroup>
<None Incl...I'm adding NASM assembly files with:
```
enable_language(ASM_NASM)
...
add_library(test STATIC rdrand-x86_64.asm)
```
The NASM assembler is found, but the target generates the following vcxproj entries:
```
<ItemGroup>
<None Include="....\test\rdrand-x86_64.asm" />
</ItemGroup>
```
Note the **None** element, which just includes the asm file into the test target, but nothing is compiled.https://gitlab.kitware.com/cmake/cmake/-/issues/16468Add support c++17 (c++1z) for CMAKE_CXX_STANDARD2018-12-11T18:40:19-05:00anonymousAdd support c++17 (c++1z) for CMAKE_CXX_STANDARDI have a problem with new CMake. I try to compile project, and some library (Qt) require at least c++11. But my project require c++17.
So, cmake automatically add flag "-std=gnu++11".
I tried add flag "-std=c++1z" with add_compile_optio...I have a problem with new CMake. I try to compile project, and some library (Qt) require at least c++11. But my project require c++17.
So, cmake automatically add flag "-std=gnu++11".
I tried add flag "-std=c++1z" with add_compile_options(), but anyway gcc called with options
`-std=c++1z -g -fPIC -fPIC -std=gnu++11`
As you can see, cmake always add "-std=gnu++11" in the end, so add_compile_options() or modification CMAKE_CXX_FLAGS don't work.
Only one way that I found is setting CMAKE_CXX_STANDARD, but it doesn't support 17 or 1z, only 98, 11 and 14.
I think this is regression and make impossible build projects with custom flag "-std=".3.8.0Brad KingBrad King