CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-10-13T13:17:55-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16688Windows: Warn when TEMP directory is not writable2017-10-13T13:17:55-04:00Dan KegelWindows: Warn when TEMP directory is not writableA trivial C project configured fine on all my boxes but one, where cmake complained
```No CMAKE_C_COMPILER could be found``` and ```No CMAKE_CXX_COMPILER could be found```
CMakeError.log showed the compiler id check program failed to...A trivial C project configured fine on all my boxes but one, where cmake complained
```No CMAKE_C_COMPILER could be found``` and ```No CMAKE_CXX_COMPILER could be found```
CMakeError.log showed the compiler id check program failed to
compile; it was located in c:\windows\temp. I looked there, and found
I couldn't even read that directory. Executing
```cacls C:\Windows\Temp /E /G everyone:F```
as administrator made the pain go away.
IIRC CMakeError.log also contained the odd message
```error MSB4036: The "SetEnvironmentVariable" task was not found.```
which may be another telltale for this problem.
Suggestion: when issuing the error "No CMAKE_C_COMPILER could be found" on windows, consider hinting to the user that making c:\windows\temp writeable may help?
This was with Windows 10, Visual Studio 2015, and several versions of cmake (3.6.2 to the latest release). I think I've seen it before with older versions of Visual Studio in the past.https://gitlab.kitware.com/cmake/cmake/-/issues/16670Syntax error in FindBoost.cmake with Windows paths with backslashes2022-04-01T13:05:06-04:00Mirco CaramoriSyntax error in FindBoost.cmake with Windows paths with backslashes```
CMake Error at C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903 (list):
Syntax error in cmake code at
C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903
when parsing string
C:\Dev\mongodb\src\boos...```
CMake Error at C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903 (list):
Syntax error in cmake code at
C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903
when parsing string
C:\Dev\mongodb\src\boost/lib${_arch_suffix}-msvc-15.0
Invalid character escape '\D'.
Call Stack (most recent call first):
C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:1379 (_Boost_UPDATE_WINDOWS_LIBRARY_SEARCH_DIRS_WITH_PREBUILT_PATHS)
src/bsoncxx/CMakeLists.txt:100 (find_package)
```https://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/16641Weird behavior of CMAKE_GENERATOR_TOOLSET2017-09-22T09:06:24-04:00Ghost UserWeird behavior of CMAKE_GENERATOR_TOOLSETAs it known, from version 11 2012 Visual Studio have two default toolsets on Windows:
* **v###**, which is default, supports new features and targets Windows versions above XP;
* **v###_xp**, which is for backward compatibili...As it known, from version 11 2012 Visual Studio have two default toolsets on Windows:
* **v###**, which is default, supports new features and targets Windows versions above XP;
* **v###_xp**, which is for backward compatibility, lacks new features and targets Windows XP.
where ### is a version of Visual Studio (*110* for *11-2012*, *120* for *12-2013* and *140* for *14-2015*/*15-2017*)
You can read more about differences here:
http://stackoverflow.com/questions/32580151/what-is-the-difference-between-v120-xp-and-v120-on-vs-2013
http://stackoverflow.com/questions/24240371/vs2013-v120-xp-as-platform-toolset-by-default
CMake was influenced by this functionality by introducing support for toolsets in 2.8.11:
https://cmake.org/Bug/view.php?id=10722
But there's problems with usage of `CMAKE_GENERATOR_TOOLSET`.
If I change it not inside `if` at all, project generation will fail on any other generator that doesn't support toolsets.
So, I must put it inside something like `if (MSVC)`. But then there's another problem:
* If I change `CMAKE_GENERATOR_TOOLSET` after `project()`, it has no effect - project will be generated with **v###** toolset, not **v###_xp**.
* If I change `CMAKE_GENERATOR_TOOLSET` before `project()`, it will take effect, but all variables with compiler info (e.g. `MSVC`, `CMAKE_<LANG>_COMPILER_ID` etc.) are still *undefined* here.
There's also a subproblem - it may be necessary to set needed WinXP compatible toolset accordingly to MSVC version, because project can support some of them. And you can't set, for example, **v120_xp** as one-stop solution - Visual Studio 14 2015 has **v140_xp**, but has no **v120_xp** by default.
Currently the only known for me way to resolve this problem is to parse `CMAKE_GENERATOR` with `MATCHES`. So it should be?
In the end, I note funny thing that `CMAKE_GENERATOR_TOOLSET`, being set after `project()`, *affects* generator if I use cmake-gui and press "Configure" button twice before pressing "Generate".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/16631FindBoost should find libraries from other VS versions.2017-05-04T16:23:49-04:00GonsoloFindBoost should find libraries from other VS versions.My simple project failed with cryptic messages about not able to find Boost's system library.
After hours I found out that I compiled for Visual Studio 2017RC but Boost was installed with VS2015.
FindBoost was looking only for libs with ...My simple project failed with cryptic messages about not able to find Boost's system library.
After hours I found out that I compiled for Visual Studio 2017RC but Boost was installed with VS2015.
FindBoost was looking only for libs with the string 140 in it so it couldn't find mine with 150.
These dlls work perfectly fine and I think finding the libraries should not depend on the version of the compiler.Roger LeighRoger Leighhttps://gitlab.kitware.com/cmake/cmake/-/issues/16630Fortran dyndep command line too long on Windows2018-02-20T16:28:55-05:00Bernhard BurgermeisterFortran dyndep command line too long on WindowsThe new cmake ninja Fortran support works very well for our project on Linux. We are using cmake-3.7.2 and ninja-1.7.2.git.kitware.dyndep-1.
Tests to use this on Windows (Windows 7 Enterprise) fail with an error message
ninja: ...The new cmake ninja Fortran support works very well for our project on Linux. We are using cmake-3.7.2 and ninja-1.7.2.git.kitware.dyndep-1.
Tests to use this on Windows (Windows 7 Enterprise) fail with an error message
ninja: fatal: CreateProcess: The filename or extension is too long.
Which is caused by the Fortran_DYNDEP__xxx rule
rule Fortran_DYNDEP__xxx
command = E:\users\cmake-3.7\bin\cmake.exe -E cmake_ninja_dyndep --tdi=xxx.dir\FortranDependInfo.json --dd=$out $in
description = Generating Fortran dyndep file $out
for a huge directory structure with many (about 1100) Fortran sources we'd like to compile into one library. The resulting command length is about 92000 characters. I tried to use a response file for this command:
rule Fortran_DYNDEP__xxx
command = E:\users\cmake-3.7\bin\cmake.exe -E cmake_ninja_dyndep --tdi=xxx.dir\FortranDependInfo.json --dd=$out @$out.rsp
description = Generating Fortran dyndep file $out
rspfile = $out.rsp
rspfile_content = $in
Which fails because it looks like cmake does not support response files:
CMake Error: -E cmake_ninja_dyndep unknown argument: @xxx.dir\Fortran.dd.rsp
So a solution might be to add response file support to cmake and use it in the Ninja generator on Windows. I'm not sure if response file support for cmake might break anything else or if it has this already with different syntax? If you aggree I might try to create a patch for this.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/16623Warning on Windows/Ninja2017-05-04T16:23:49-04:00Ben BoeckelWarning on Windows/NinjaSee [this CDash build](https://open.cdash.org/viewBuildError.php?type=1&buildid=4751115):
When compiling `testConsoleBuf.cxx` and `testConsoleBufChild.cxx`:
```
cl : Command line warning D9002 : ignoring unknown option '/utf-8'
```
It...See [this CDash build](https://open.cdash.org/viewBuildError.php?type=1&buildid=4751115):
When compiling `testConsoleBuf.cxx` and `testConsoleBufChild.cxx`:
```
cl : Command line warning D9002 : ignoring unknown option '/utf-8'
```
It's added manually, but the compiler does pass the version checks in the file. Are the version files insufficient?https://gitlab.kitware.com/cmake/cmake/-/issues/16622CMake behavior differs on two different Windows systems2017-05-04T16:23:49-04:00Dick AnnicchiaricoCMake behavior differs on two different Windows systemsLooking for advice on how to further troubleshoot this issue. Thanks for any pointers. Seems like an environmental issue of some sort rather than a CMake bug.
I am successfully using CMake to build aws-sdk-cpp on my Windows machine,...Looking for advice on how to further troubleshoot this issue. Thanks for any pointers. Seems like an environmental issue of some sort rather than a CMake bug.
I am successfully using CMake to build aws-sdk-cpp on my Windows machine, but a colleague gets errors when trying to do so using the same versions of aws-sdk-cpp and CMake. What happens is the cmake-generated .vcxproj files end up being "confused" in places, using Unix filespecs instead of Windows.
For example:
On "good" system, .vcxproj file TargetExt specifies .dll,
`<TargetName Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|Win32'">aws-cpp-sdk-core</TargetName>`
`<TargetExt Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|Win32'">.dll</TargetExt>`
but on "bad" system, it specifies .so.
`<TargetName Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|Win32'">libaws-cpp-sdk-core</TargetName>`
`<TargetExt Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|Win32'">.so</TargetExt>`
There are other differences as well, in `<AdditionalDependencies>`, `<ImportLibrary>`, and `<ProgramDataBaseFile>` tags.
Both systems are using the same version of aws-sdk-cpp sources and the same version of CMake. We also tried explicitly specifying `-DTARGET_ARCH="WINDOWS"` to cmake, but it didn't make a difference. Even though the output says it is building for Windows, it generates Unix filespecs for some things.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/16618CPack NSIS component is Unspecified2017-05-04T16:23:49-04:00TimCPack NSIS component is UnspecifiedSee [this question](http://stackoverflow.com/questions/41985057/cpack-nsis-component-is-unspecified). I'm starting to suspect it is a bug.See [this question](http://stackoverflow.com/questions/41985057/cpack-nsis-component-is-unspecified). I'm starting to suspect it is a bug.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/16574Starting with CMake 3.7.0, it cannot find root directory in specific conditions2017-05-04T16:23:50-04:00Steve TousignantStarting with CMake 3.7.0, it cannot find root directory in specific conditionsA recent update to cmake have shown that some of my scripts started failing with cmake reporting that it cannot find the CMAKE_ROOT while using the relocating package in Windows OS. The reason why cmake failed to find its root directory ...A recent update to cmake have shown that some of my scripts started failing with cmake reporting that it cannot find the CMAKE_ROOT while using the relocating package in Windows OS. The reason why cmake failed to find its root directory is because the script invoking cmake had a case change in the bin directory.
Here is an example of the failure.
```
cmd>%CMAKE_HOME%\BIN\CMake.exe -G "Visual Studio 11 2012" ..
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
CMake Error: Error executing cmake::LoadCache(). Aborting.
```
But here is an example with the same release version of cmake.
```
cmd>%CMAKE_HOME%\bin\CMake.exe -G "Visual Studio 11 2012" ..
-- The C compiler identification is MSVC 17.0.61030.0
-- The CXX compiler identification is MSVC 17.0.61030.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
```
Take notice on the failing version that the path used for execution is __BIN__\CMake.exe and the working version is __bin__\CMake.exeBen BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/16573Need to override ProgramFilesFolder in CPack WiX installer, to use CommonFile...2017-05-04T16:23:50-04:00Eric BackusNeed to override ProgramFilesFolder in CPack WiX installer, to use CommonFilesFolder insteadWhen using CPack to generate a WiX installer, normally the installer puts everything under ProgramFilesFolder (for 32-bit installers) or ProgramFiles64Folder (for 64-bit installers). And, normally this is good :)
I see that there is a n...When using CPack to generate a WiX installer, normally the installer puts everything under ProgramFilesFolder (for 32-bit installers) or ProgramFiles64Folder (for 64-bit installers). And, normally this is good :)
I see that there is a new option CPACK_WIX_SKIP_PROGRAM_FOLDER which lets me skip using ProgramFilesFolder or ProgramFiles64Folder. But this isn't quite what I need.
What I need is to allow the installer to put things under CommonFilesFolder (for 32-bit installer) or CommonFiles64Folder (for 64-bit installer). There's no good way to do that, at least as of version 3.7.1.
It seems like adding support for this would be easy. Here's a proposed patch which I believe would accomplish it:
```
*** cmake-3.7.1/Source/CPack/WiX/cmCPackWIXGenerator.cxx.orig Wed Nov 30 10:14:52 2016
--- cmake-3.7.1/Source/CPack/WiX/cmCPackWIXGenerator.cxx Sat Jan 14 09:20:16 2017
***************
*** 575,585 ****
if (cmSystemTools::IsOn(GetOption("CPACK_WIX_SKIP_PROGRAM_FOLDER"))) {
return "";
}
! if (GetArchitecture() == "x86") {
! return "ProgramFilesFolder";
! } else {
! return "ProgramFiles64Folder";
}
}
bool cmCPackWIXGenerator::GenerateMainSourceFileFromTemplate()
--- 575,603 ----
if (cmSystemTools::IsOn(GetOption("CPACK_WIX_SKIP_PROGRAM_FOLDER"))) {
return "";
}
!
! const char* programFolderSpecifier = GetOption("CPACK_WIX_PROGRAM_FOLDER");
! if (programFolderSpecifier == 0)
! // The default is architecture-specific Program Files folder
! programFolderSpecifier = "ArchProgramFilesFolder";
!
! // Normal case, the folder is architecture-specific
! if (strcmp(programFolderSpecifier, "ArchProgramFilesFolder") == 0) {
! if (GetArchitecture() == "x86") {
! return "ProgramFilesFolder";
! } else {
! return "ProgramFiles64Folder";
! }
! } if (strcmp(programFolderSpecifier, "ArchCommonFilesFolder") == 0) {
! if (GetArchitecture() == "x86") {
! return "CommonFilesFolder";
! } else {
! return "CommonFiles64Folder";
! }
}
+ // Otherwise, assume the folder has been specified directly and is
+ // independent of architecture
+ return programFolderSpecifier;
}
bool cmCPackWIXGenerator::GenerateMainSourceFileFromTemplate()
```Nils GladitzNils Gladitzhttps://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/16553try_run with Visual C++ Build Tools cause missing ucrtbased.dll2017-05-04T16:23:51-04:00Timtry_run with Visual C++ Build Tools cause missing ucrtbased.dllConsider the following CMakeLists.txt
```
cmake_minimum_required (VERSION 3.1)
project (Foo)
add_executable (Foo main.cpp)
include(CheckCXXSourceRuns)
check_cxx_source_runs( "int main() { return 0; }" ALL_GOOD )
if ( NOT ALL...Consider the following CMakeLists.txt
```
cmake_minimum_required (VERSION 3.1)
project (Foo)
add_executable (Foo main.cpp)
include(CheckCXXSourceRuns)
check_cxx_source_runs( "int main() { return 0; }" ALL_GOOD )
if ( NOT ALL_GOOD )
MESSAGE ( FATAL_ERROR "What." )
endif ()
```
When using the Visual C++ Build Tools, the check_cxx_source_runs() command fails! You get a dialog saying ucrtbased.dll is missing from my computer. In fact, ucrtbased.dll is not in c:\Windows\System32 or SysWOW64, although it is in c:\Program Files (x86)\Windows Kits\10\bin\*\ucrt and also c:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.UniversalCRT.Debug\....
The release version, ucrtbase.dll *is* in c:\Windows\System32 and SysWOW64, so the code does work in release mode. So at this point you might be thinking "Ok that is what I would expect."
Except! If you remove all the Check... stuff, main.cpp (which also contains "int main() { return 0; }") builds and runs fine. Checking in depends.exe it doesn't depend on ucrtbase.dll or ucrtbased.dll. I haven't been able to look at the binary built by check_cxx_source_runs() because it always immediately deletes everything.
Anyway something is clearly wrong here. If you simply copy the ucrtbased.dll files to c:\Windows\System32 you get the error "The application failed to start correctly." instead. https://gitlab.kitware.com/cmake/cmake/-/issues/16552Visual Studio Generator does not export CUDA object files with WINDOWS_EXPORT...2017-04-22T10:31:46-04:00Guillaume DumontVisual Studio Generator does not export CUDA object files with WINDOWS_EXPORT_ALL_SYMBOLSThere seems to be a bug with the WINDOWS_EXPORT_ALL_SYMBOLS feature, CUDA and the Visual Studio Generator.
I have setup a small project demonstrating the issue here:
https://github.com/willyd/cmake-windows-export-all-issue
If this pro...There seems to be a bug with the WINDOWS_EXPORT_ALL_SYMBOLS feature, CUDA and the Visual Studio Generator.
I have setup a small project demonstrating the issue here:
https://github.com/willyd/cmake-windows-export-all-issue
If this project is built with the Ninja generator everything is fine. However, if we build the same project with the same compiler but with the Visual Studio generator instead the symbols defined in the CUDA files are not exported. The generator object file list does not include the CUDA object files when using the Visual Studio generator whereas the Ninja generator correctly includes them.
Object Files with Visual Studio Generator:
[objects.txt](/uploads/160e8d8a8d0800688f3bacb2edfee1d2/objects.txt)
Object Files with Ninja Generator:
[lib.def.objs](/uploads/28f14f5373f04ffd2c282daed83d65e1/lib.def.objs)
To reproduce the issue (you need to install CUDA first):
```
$ git clone https://github.com/willyd/cmake-windows-export-all-issue
$ cd cmake-windows-export-all-issue
$ mkdir build_vs
$ cd build_vs
$ cmake -G"Visual Studio 14 2015 Win64" ..\
$ cmake --build .
```
This will result in an unresolved external symbol link error since the `sum_gpu` symbol is not exported correctly. If we build with Ninja the error goes away.
Can you please fix this or suggest where a patch should be applied in the CMake source code?https://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/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.atkins