CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-05-04T16:23:51-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16542CMAKE_INSTALL_UCRT_LIBRARIES should be aware of CMAKE_INSTALL_DEBUG_LIBRARIES...2017-05-04T16:23:51-04:00Bjoern ThielCMAKE_INSTALL_UCRT_LIBRARIES should be aware of CMAKE_INSTALL_DEBUG_LIBRARIES_ONLY and CMAKE_INSTALL_DEBUG_LIBRARIESTo achieve this I suggest to make the following change to InstallRequiredSystemLibraries.cmake:
```cmake
if(CMAKE_INSTALL_UCRT_LIBRARIES AND NOT v VERSION_LESS 14)
# Find the Windows Kits directory.
get_filename_compo...To achieve this I suggest to make the following change to InstallRequiredSystemLibraries.cmake:
```cmake
if(CMAKE_INSTALL_UCRT_LIBRARIES AND NOT v VERSION_LESS 14)
# Find the Windows Kits directory.
get_filename_component(windows_kits_dir
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots;KitsRoot10]" ABSOLUTE)
set(programfilesx86 "ProgramFiles(x86)")
find_path(WINDOWS_KITS_DIR NAMES Redist/ucrt/DLLs/${CMAKE_MSVC_ARCH}/ucrtbase.dll
PATHS
"${windows_kits_dir}"
"$ENV{ProgramFiles}/Windows Kits/10"
"$ENV{${programfilesx86}}/Windows Kits/10"
)
mark_as_advanced(WINDOWS_KITS_DIR)
# Glob the list of UCRT DLLs.
if(NOT CMAKE_INSTALL_DEBUG_LIBRARIES_ONLY)
file(GLOB __ucrt_dlls "${WINDOWS_KITS_DIR}/Redist/ucrt/DLLs/${CMAKE_MSVC_ARCH}/*.dll")
list(APPEND __install__libs ${__ucrt_dlls})
endif()
if(CMAKE_INSTALL_DEBUG_LIBRARIES)
file(GLOB __ucrt_dlls "${WINDOWS_KITS_DIR}/bin/${CMAKE_MSVC_ARCH}/ucrt/*.dll")
list(APPEND __install__libs ${__ucrt_dlls})
endif()
endif()
```https://gitlab.kitware.com/cmake/cmake/-/issues/16537Ninja generator adds "/DEF" linker flag for static libraries2017-05-04T16:23:51-04:00John SmithNinja generator adds "/DEF" linker flag for static librariesSome of my Windows code statically links against [FreeRDP](https://github.com/FreeRDP/FreeRDP). Previously I was using the "NMake Makefiles JOM" generator with [jom](https://wiki.qt.io/Jom) to build my code. The code built fine. In th...Some of my Windows code statically links against [FreeRDP](https://github.com/FreeRDP/FreeRDP). Previously I was using the "NMake Makefiles JOM" generator with [jom](https://wiki.qt.io/Jom) to build my code. The code built fine. In the past, I also used regular nmake without problems.
Recently I switched to using the "Ninja" generator with [ninja](https://ninja-build.org/). The code still compiled fine, but I ran into problems running my executable. Every time I ran the executable, Windows would complain that "freerdp-client.dll" was missing. That was odd because I explicitly told FreeRDP to be built as a static library by putting this in my CMakeLists.txt:
```
set(BUILD_SHARED_LIBS OFF)
```
I eventually tracked the problem down to this code from [client/common/CMakeLists.txt around line 42](https://github.com/FreeRDP/FreeRDP/blob/6fa36081112c46951096cddfacc0f760e4728b25/client/common/CMakeLists.txt#L42):
```
if(MSVC)
set(${MODULE_PREFIX}_SRCS ${${MODULE_PREFIX}_SRCS} module.def)
endif()
```
That line of code was causing the Ninja generator to add this linker flag to `LINK_FLAGS`:
```
/DEF:C:\path\to\FreeRDP\client\common\module.def
```
I think the `/DEF` linker flag was causing the linker to link freerdp-client.lib dynamically instead of statically to my code. The NMake and JOM generators did not add `/DEF`to `LINK_FLAGS` even though I was using the same `CMakeLists.txt`. This difference in behavior was introduced recently in 43ce4414c479af6b04e93decaf7f69938c92a323, which added this code to `cmNinjaNormalTargetGenerator::WriteDeviceLinkStatement` around line [660](https://gitlab.kitware.com/robertmaynard/cmake/commit/43ce4414c479af6b04e93decaf7f69938c92a323#e41573099084ba2bf39bf06a506af881f053382c_421_660):
```
this->AddModuleDefinitionFlag(linkLineComputer.get(), vars["LINK_FLAGS"]);
```
Inside `AddModuleDefinitionFlag`, the `/DEF` linker flag is added if a module definition file is in the list of sources. I don't see the Nmake or JOM generators calling `AddModuleDefinitionFlag` at all. Given that my code compiles and links correctly with JOM and NMake, I suspect this is a bug in the Ninja generator but I am not sure.
I confirmed that removing `module.def` from the list of sources removes `/DEF` from `LINK_FLAGS` when using the Ninja generator and that my executable now runs correctly without looking for `freerdp-client.dll`.
Coincidentally, the FreeRDP project recently modified their CMakeLists.txt files in [PR 3168](https://github.com/FreeRDP/FreeRDP/pull/3168) to [completely remove module.def from the list of sources](https://github.com/FreeRDP/FreeRDP/pull/3168/commits/c182be093dd909da953e87b3cdeb188e71e7bb73). Thus, this problem should fix itself when I eventually upgrade to the latest version of FreeRDP but it still doesn't explain the difference between the Nmake/JOM and Ninja generators.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16534FindHDF5 causes DLLs to appear on the link line on Windows2017-05-04T16:23:52-04:00Ben BoeckelFindHDF5 causes DLLs to appear on the link line on WindowsThe following line in the `FindHDF5` module causes the `.dll` file to be found rather than the `.lib` file:
```cmake
get_target_property(_lang_location ${HDF5_${_lang}_TARGET}${_suffix} LOCATION)
```
because the `IMPORTED_LOCATION_<CON...The following line in the `FindHDF5` module causes the `.dll` file to be found rather than the `.lib` file:
```cmake
get_target_property(_lang_location ${HDF5_${_lang}_TARGET}${_suffix} LOCATION)
```
because the `IMPORTED_LOCATION_<CONFIG>` property is the `.dll` while `IMPORTED_IMPLIB_<CONFIG>` is the `.lib` file.
Cc: @chuck.atkinshttps://gitlab.kitware.com/cmake/cmake/-/issues/16523Regression: Recursive get_prerequisites fails on cross-build for system DLLs2017-09-26T07:12:28-04:00e9925248Regression: Recursive get_prerequisites fails on cross-build for system DLLsafb674ab46a7d6ff3d1801315f3d852bdba79d0c introduced an regression:
Setup: Linux with mingw cross-toolchain:
Call get_prerequisites with on an exe file with recurse enabled.
The first part of get_prerequisites will gather all used DLLs...afb674ab46a7d6ff3d1801315f3d852bdba79d0c introduced an regression:
Setup: Linux with mingw cross-toolchain:
Call get_prerequisites with on an exe file with recurse enabled.
The first part of get_prerequisites will gather all used DLLs, which include system DLLs like KERNEL32.dll, USER32.dll, ...
A cross-build mingw system does not contain such system DLLs, so such DLLs resolve to other:
```
warning: cannot resolve item 'ADVAPI32.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
-- gp_resolved_file_type: 'ADVAPI32.dll' 'ADVAPI32.dll'
-- type: 'other'
-- warning: gp_resolved_file_type non-absolute file 'ADVAPI32.dll' returning type 'other' -- possibly incorrect
```
At the end of get_prerequisites, get_prerequisites is called for all dependencies (including those system DLLs). As they don't exist, calling objdump for these DLLs fails. The commit mentioned above causes get_prerequisites to abort - previous versions continued on such errors.3.8.0https://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/16513InstallRequiredSystemLibraries omits concrt140.dll from the VC 14.0 (VS 2015)...2017-05-04T16:23:52-04:00Taylor Braun-JonesInstallRequiredSystemLibraries omits concrt140.dll from the VC 14.0 (VS 2015) CRT DLLsThe starting with VC 14.0, the CRT includes an additional `concrt140.dll` file that the InstallRequiredSystemLibraries module does not seem to know about.
```
/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC/redist/x64/Microsof...The starting with VC 14.0, the CRT includes an additional `concrt140.dll` file that the InstallRequiredSystemLibraries module does not seem to know about.
```
/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC/redist/x64/Microsoft.VC110.CRT/
├── msvcp110.dll
├── msvcr110.dll
└── vccorlib110.dll
/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/redist/x64/Microsoft.VC120.CRT/
├── msvcp120.dll
├── msvcr120.dll
└── vccorlib120.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/x64/Microsoft.VC140.CRT/
├── concrt140.dll
├── msvcp140.dll
├── vccorlib140.dll
└── vcruntime140.dll
```
This may also be helpful:
```bash
$ find '/c/Program Files (x86)/Microsoft Visual Studio'* -iname 'concrt*.dll'
/c/Program Files (x86)/Microsoft Visual Studio 14.0/Common7/IDE/Remote Debugger/x64/concrt140.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/Common7/IDE/Remote Debugger/x86/concrt140.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/arm/Microsoft.VC140.CRT/concrt140.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/debug_nonredist/arm/Microsoft.VC140.DebugCRT/concrt140d.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/debug_nonredist/x64/Microsoft.VC140.DebugCRT/concrt140d.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/debug_nonredist/x86/Microsoft.VC140.DebugCRT/concrt140d.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/x64/Microsoft.VC140.CRT/concrt140.dll
/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/x86/Microsoft.VC140.CRT/concrt140.dll
```https://gitlab.kitware.com/cmake/cmake/-/issues/16490CMake GUI new install freezing upon 'Configure' as generator selection dialog...2017-05-04T16:23:53-04:00Eric PrechtlCMake GUI new install freezing upon 'Configure' as generator selection dialog comes upJust installed CMake 3.7.1 on a Windows 10, 64-bit system. I'm trying to use the CMake GUI on some GLFW source code. The first strange (but workable) issue I see is that as I click on 'Browse Source' button to add the paths, the path b...Just installed CMake 3.7.1 on a Windows 10, 64-bit system. I'm trying to use the CMake GUI on some GLFW source code. The first strange (but workable) issue I see is that as I click on 'Browse Source' button to add the paths, the path boxes don't respond at first. I have to adjust the size of the CMake window for the software to respond. That's weird - but, as I said, it's workable.
Big problem comes when I have both the source and build folders specified and hit Configure (and adjust the width of the window). The dialog for specifying the generator comes up - but it's completely unresponsive (all of CMake freezes). I can only 'end task' via the task manager to close the software.
So it's pretty catastrophic. I thought it might have been the GLFW source code I was using - but this happens on both the newest GLFW version 3.2.1 and an older version (3.1.2).
Btw, the CMake configure/generate process does work on this GLFW software on my personal laptop with the same o/s and system specs. This fail is happening on a new work computer I'm using which is behind a firewall, etc. Been working with the IT guy - but we can't seem to figure out what's going on. (This happens whether I run regular or as Administrator. And we've reinstalled the software multiple times as multiple people with different permission levels - but the result is the same.)
Any thoughts on what we might try next?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/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/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/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/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/16461MSB6003: The specified task executable "CL.exe" could not be run. Access is d...2017-05-04T16:23:53-04:00Egor PuginMSB6003: The specified task executable "CL.exe" could not be run. Access is deniedHi,
I see some occasional deadlocks when starting multiple cmake processes for checking symbols simultaneously.
I have a lot of stuff to check (include files, functions, symbols etc.).
I've written a dispatcher which generates CMakeLis...Hi,
I see some occasional deadlocks when starting multiple cmake processes for checking symbols simultaneously.
I have a lot of stuff to check (include files, functions, symbols etc.).
I've written a dispatcher which generates CMakeLists.txt files and starts cmake N processses. N - number of cores.
And 1-2 cmake processes (out of my 8 logical cores and therefore cmake processes) hangs.
Sometimes they work fine, sometimes not. One user reported that he has 100% repeatable deadlocks on his system.
On my system these deadlocks could unlock in 5-10 minutes while on the other systems could not.
I decided to catch the issue on my system. I've built cmake-3.7.0 rel with deb info build.
Once I was hit by deadlock I've attached to cmake process.
So, cmake is waiting for `msbuild.exe` to finish. I see main+4 threads. Background threads are hunting for stdout data and spinning somewhere in `Source\kwsys\ProcessWin32.c - kwsysProcessPipeThreadReadPipe()`. Main thread is waiting in `G:\dev\CMake\Source\cmSystemTools.cxx:614 - RunSingleCommand()` and line `614` - `while ((pipe = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR)) >`.
I've gathered `msbuild.exe` output vars.
Contents:
```
Change Dir: C:/Users/egor/AppData/Local/Temp/cppan/vars/UIow8Z2e/6/CMakeFiles/CMakeTmp
Run Build Command:"C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe" "cmTC_c91b8.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=14.0"
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 28.11.2016 16:28:08.
Project "C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "cmTC_c91b8.dir\Debug\".
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(400,5): warning MSB8029: The Intermediate directory or Output directory cannot reside under the Temporary directory as it could lead to issues with incremental build. [C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj]
Creating directory "C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\Debug\".
Creating directory "cmTC_c91b8.dir\Debug\cmTC_c91b8.tlog\".
InitializeBuildStatus:
Creating "cmTC_c91b8.dir\Debug\cmTC_c91b8.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_c91b8.dir\Debug\\" /Fd"cmTC_c91b8.dir\Debug\vc140.pdb" /Gd /TC /analyze- /errorReport:queue C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CheckTypeSize\HAVE_GID_T.c
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(356,5): error MSB6003: The specified task executable "CL.exe" could not be run. Access is denied [C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj]
Done Building Project "C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj" (default target) (1) ->
(PrepareForBuild target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(400,5): warning MSB8029: The Intermediate directory or Output directory cannot reside under the Temporary directory as it could lead to issues with incremental build. [C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj]
"C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj" (default target) (1) ->
(ClCompile target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(356,5): error MSB6003: The specified task executable "CL.exe" could not be run. Access is denied [C:\Users\egor\AppData\Local\Temp\cppan\vars\UIow8Z2e\6\CMakeFiles\CMakeTmp\cmTC_c91b8.vcxproj]
1 Warning(s)
1 Error(s)
Time Elapsed 00:02:00.71
```
Output says `C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(356,5): error MSB6003: The specified task executable "CL.exe" could not be run. Access is denied`.
So, what does it mean? Who is responsible for deadlocks? msbuild? cmake? (maybe issues in reading from pipes)
Maybe you know what this error means. I googled it but nothing concrete.
`Access is denied` probably means`ERROR_ACCESS_DENIED` returned from `GetLastError()` but I wonder what causes this error.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/16439Add support for Clang targeting MSVC ABI but with GNU-like command line2019-05-29T09:22:17-04:00Ernst MaurerAdd support for Clang targeting MSVC ABI but with GNU-like command linetried to replace MinGW compiler in the project by specifying clang ones:
> cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=C:/dev/tools/LLVM/bin/clang.exe -DCMAKE_CXX_COMPILER=C:/dev/tools/LLVM/bin/clang++.exe -G "CodeBlocks - M...tried to replace MinGW compiler in the project by specifying clang ones:
> cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=C:/dev/tools/LLVM/bin/clang.exe -DCMAKE_CXX_COMPILER=C:/dev/tools/LLVM/bin/clang++.exe -G "CodeBlocks - MinGW Makefiles" C:\Users\amigo421\ClionProjects\hr2
however , cmake tries to use incorrect flags for clang:
> clang.exe /nologo /DWIN32 /D_WINDOWS /W3 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /FoCMakeFiles\cmTC_f50b2.dir\testCCompiler.c.obj /FdCMakeFiles\cmTC_f50b2.dir/ -c C:\Users\amigo421\ClionProjects\hr2\cmake-build-debug\CMakeFiles\CMakeTmp\testCCompiler.c
you see - cmake uses compiler flags from VC toolchain instead of expected GCC one
is it a bug or can be solved by using some additional settings?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/16417RC files can be out of sync on Windows on all generators2017-05-04T16:23:54-04:00ArjanRC files can be out of sync on Windows on all generatorsI've run into an issue where the RC files are not always updated. At first I tought this was Ninja related, but it seems to be on most if not all windows generators.
To help illustrate the issue I've created a minimal reproduction, for...I've run into an issue where the RC files are not always updated. At first I tought this was Ninja related, but it seems to be on most if not all windows generators.
To help illustrate the issue I've created a minimal reproduction, for which you can use the files attached.
You may run the test as following:
```
cd <build_dir>
cmake <source_dir>
cmake --build . && cmake -P <source_dir>/run_actual_test.cmake
```
Note that this requires the sigcheck tool, available at: https://technet.microsoft.com/en-us/sysinternals/bb897441.aspx
This will start a (theoretically) endless loop of building and testing.
In practise this will end at some point as the checks verify the RC file being out of sync with the executable.
Note that it can take a while before the issue appears, it is most prevalent with multicore aware generators such as JOM and Ninja
[generate_version.cmake](/uploads/e65b9e7af5278279e672706bbe8d67a1/generate_version.cmake)
[CMakeLists.txt](/uploads/34042452602c0c915fd03ea5248936cd/CMakeLists.txt)
[run_actual_test.cmake](/uploads/86410231b4757b994c4a8d9e9ab85525/run_actual_test.cmake)https://gitlab.kitware.com/cmake/cmake/-/issues/16393Ninja generator fails on Windows when cross-compiling a sharedlib with version2017-05-04T16:23:55-04:00Martin OberhuberNinja generator fails on Windows when cross-compiling a sharedlib with versionWhen cross-compiling a sharedlibrary that has a "version" property with Ninja on Windows, it fails:
```
[5/12] Linking C shared library libhelloshared.so.1
FAILED: libhelloshared.so.1
cmd.exe /C "cd . && G:/WindRiver/vx7_CR0481/com...When cross-compiling a sharedlibrary that has a "version" property with Ninja on Windows, it fails:
```
[5/12] Linking C shared library libhelloshared.so.1
FAILED: libhelloshared.so.1
cmd.exe /C "cd . && G:/WindRiver/vx7_CR0481/compilers/gnu-4.8.1.7/x86-win32/bin/c++pentium.exe -fPIC -m32 -mfpmath=387 -fno-implicit-fp -fno-builtin -fno-omit-frame-pointer -mrtp -fno-strict-aliasing -D_C99 -D_HAS_C9X -std=c99 -fasm -Wall -gdwarf-3 -shared -Wl,-soname,libhelloshared.so.1 -o libhelloshared.so.1 CMakeFiles/helloshared.dir/src/shared/hello.o -LG:/WindRiver/vx7_CR0481/vxworks-7/samples/prebuilt_projects/vsb_vxsim_windows/usr/lib/common/PIC -Wl,-lstdc++ && :"
':' is not recognized as an internal or external command, operable program or batch file.
ninja: build stopped: subcommand failed.
```
The problem was observed with cmake-3.6.2 and Ninja-1.7.1 on Windows 7.
The culprit seems to be cmNinjaNormalTargetGenerator.cxx line 676:
```
if (!symlinkNeeded) {
vars["POST_BUILD"] = postBuildCmdLine;
} else {
vars["POST_BUILD"] = ":";
symlinkVars["POST_BUILD"] = postBuildCmdLine;
}
```
Generating ":" as an empty POST_BUILD command seems to be invalid on Windows outside batchfiles,
I would suggest generating an empty String instead, or "cd ." for example which works on both Windows and Unix.
Attached is a sample project to reproduce the problem.
[hello_cmake_sharedlib_cross.zip](/uploads/29aa97e0cf34b898a8bff7e92822b88d/hello_cmake_sharedlib_cross.zip)
The archive includes a generated "build-SIMNTgnu-Debug-ninja" folder to look at the ninja files for VxWorks.
To reproduce, you'll need some sort of toolchain file for crosscompiling:
```
mkdir bld
cd bld
cmake -DCMAKE_TOOLCHAIN_FILE=C:\mytoolchain.cmake -G"Eclipse CDT4 - Ninja" ..
cmake --build .
```3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16384Intel C++ Compiler 17.0 support2017-05-04T16:23:55-04:00Sergiu DeitschIntel C++ Compiler 17.0 supportUsing the Intel C++ Compiler 17.0 on Windows and `CMAKE_CXX_STANDARD` set to 11, CMake 3.7rc1 adds the `/Qstd=gnu++11` option, which is not supported on Windows. This results in warnings such as
```
warning #10159: invalid argument for...Using the Intel C++ Compiler 17.0 on Windows and `CMAKE_CXX_STANDARD` set to 11, CMake 3.7rc1 adds the `/Qstd=gnu++11` option, which is not supported on Windows. This results in warnings such as
```
warning #10159: invalid argument for option '/Qstd'
```
Also, `target_compile_features` fails to determine available features with the error
```
No known features for CXX compiler
"Intel"
version 17.0.0.20160721.
```
Visual Studio solutions are successfully generated, while ninja files are not.3.8.0