CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-05-04T16:23:54-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16436CMake 3.7.0 build VS 14 when generator is VS152017-05-04T16:23:54-04:00David HunterCMake 3.7.0 build VS 14 when generator is VS15I just downloaded and installed VS 2017 RC and ran 'cmake -G "Visual Studio 15 Win64" ...'. The output showed
`-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for wo...I just downloaded and installed VS 2017 RC and ran 'cmake -G "Visual Studio 15 Win64" ...'. The output showed
`-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works`
So I guess one of two things. MS have change thing since VS 15 Preview 5 or more likely the uninstall of Preview 5 followed by
an install of VS 2917 RC has left stuff in a mess. I haven't been able to prove the later and it does seem odd that the command
would not simply fails rather than run an old compiler. Are there any logs or other places I can look to see what is going on?3.7.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16426BISON_TARGET always generates dependency in Ninja for output file2018-10-09T08:03:16-04:00Bruce StephensBISON_TARGET always generates dependency in Ninja for output fileI have several simple BISON_TARGET rules (some contain DEFINES_FILE, some not, but none using VERBOSE or REPORT_FILE). With 3.6.2 they worked fine, but with 3.7.0 the bison rule is always executed. Using "ninja -d explain" I can see it's...I have several simple BISON_TARGET rules (some contain DEFINES_FILE, some not, but none using VERBOSE or REPORT_FILE). With 3.6.2 they worked fine, but with 3.7.0 the bison rule is always executed. Using "ninja -d explain" I can see it's because the output file doesn't exist. If I add VERBOSE to the rules, things work as before (except that I get the output files, too).3.7.1https://gitlab.kitware.com/cmake/cmake/-/issues/16423Use-after-free in cmGlobalUnixMakefileGenerator3.cxx in cmake-server mode2017-05-04T16:23:54-04:00vector-of-boolUse-after-free in cmGlobalUnixMakefileGenerator3.cxx in cmake-server modeWhen configuring or computing/generating build information, `ProgressMap` in`cmGlobalUnixMakefleGenerator3` stores pointers to `cmGeneratorTarget` instances. With the new CMake server mode, a user is able to cause configuration/generatio...When configuring or computing/generating build information, `ProgressMap` in`cmGlobalUnixMakefleGenerator3` stores pointers to `cmGeneratorTarget` instances. With the new CMake server mode, a user is able to cause configuration/generation to happen a _more than once on a single `cmGlobalUnixMakefileGenerator3` instance_. All the `cmGeneratorTarget` instances from the previous configure process are destroyed once configuration starts again, but the pointers in `ProgressMap` live on. Any attempt to access elements inside `ProgressMap` will cause the old `cmGeneratorTarget` pointers to be reused. As such, requesting a configure/generate a second time when using `cmake -E server` will cause undefined behavior, and usually manifests as CMake crashing.3.7.1Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16422Crash in cmFileMonitor.cxx on directory change on Windows2017-05-04T16:23:54-04:00vector-of-boolCrash in cmFileMonitor.cxx on directory change on Windows`on_directory_change` is the callback passed to `uv_fs_event_start`, and `on_directory_change` will unconditionally construct a `std::string` from the `filename` arguments passed on from libuv. [The documentation](If a directory is being...`on_directory_change` is the callback passed to `uv_fs_event_start`, and `on_directory_change` will unconditionally construct a `std::string` from the `filename` arguments passed on from libuv. [The documentation](If a directory is being monitored, this is the file which was changed. Only non-null on Linux and Windows. May be null even on those platforms.) from libuv says that the `filename` argument may be `NULL`. Constructing a `std::string` from `NULL` is illegal. In debug mode, this results in a crash.
libuv doesn't seem to document _why_ `filename` would be null, but I investigated further.
The reason libuv passes `NULL` is because the `OVERLAPPED` structure does not receive filesystem information in `InternalHigh` which should say information about why libuv was notified about the filesystem change. `InternalHigh` is only `NULL` in the case of some error, where the error code is stored in the `Internal` field of the `OVERLAPPED` structure. In my test case, the `Internal` value of `OVERLAPPED` is `268`, which corresponds with the status `STATUS_NOTIFY_ENUM_DIR`. The appearance of this status message is not documented and seems to actually be a bug in Windows and it seems to correspond to `ERROR_NOTIFY_ENUM_DIR`, as discussed [here](http://stackoverflow.com/questions/14801950/getqueuedcompletionstatusex-readdirectorychangesw). This happens when the buffer allocated to store the notification information is too small.
In this case, the notification is regarding the `CMakeFiles` subdirectory of the build directory. My best guess is that there was a notification on too many files in the directory simultaneously to be stored properly. In this case, the directory watcher is not notified regarding a single file but is notified that the directory, in general, has multiple files changing within.
I'm not sure what the correct behavior might be. Perhaps drop the notification? Perhaps forward a notification for each file in the directory?3.7.1Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/163473.7.0-rc1 VS 15 generator2017-05-04T16:24:37-04:00David Hunter3.7.0-rc1 VS 15 generatorVS 15 preview 5 got released just after the release of 3.7.0-rc1. I think the following needs to be fixed
1. The PlatformToolset should be v141 not v140
2. MSBuild should now come from C:\Program Files (x86)\Microsoft Visual Studio...VS 15 preview 5 got released just after the release of 3.7.0-rc1. I think the following needs to be fixed
1. The PlatformToolset should be v141 not v140
2. MSBuild should now come from C:\Program Files (x86)\Microsoft Visual Studio\VS15Preview\MSBuild\15.0\Bin not C:\Program Files (x86)\MSBuild\15.0
I think the old location is now dead. Also I suspect they don't use the registry to locate MSBuild any more, I am trying to get confirmation from MS
3. The variable MSVC14 seems to be set rather than MSVC15
I worked around the above and my 300 odd project VS solution does seem to work with Preview 53.7.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16539Server Mode: CMake process crashes when running into INTERFACE_LIBRARY targets2017-05-04T16:23:51-04:00Janick Martinez EsturoServer Mode: CMake process crashes when running into INTERFACE_LIBRARY targetsIn a complex project the cmake server crashes with
```
cmake: /home/janickm/.local/pkg/cmake/Source/cmGeneratorTarget.cxx:954: void cmGeneratorTarget::GetSourceFiles(std::vector<std::__cxx11::basic_string<char> >&, const string&) con...In a complex project the cmake server crashes with
```
cmake: /home/janickm/.local/pkg/cmake/Source/cmGeneratorTarget.cxx:954: void cmGeneratorTarget::GetSourceFiles(std::vector<std::__cxx11::basic_string<char> >&, const string&) const: Assertion `this->GetType() != cmState::INTERFACE_LIBRARY' failed.
```
using
```
$ cmake --version
cmake version 3.7.1
```
for the `codemodel` message type.
The project makes heavy use of interface libraries, but works fine in non-server mode.
---
The following commands are used
```
$ cmake -E server --experimental --debug
```
```
[== "CMake Server" ==[
{
"buildDirectory": "/home/../<cmake-project>/build",
"cookie": "",
"generator": "Ninja",
"major": 1,
"protocolVersion": {
"major": 1
},
"sourceDirectory": "/home/../<cmake-project>",
"type": "handshake"
}
]== "CMake Server" ==]
```
```
[== "CMake Server" ==[
{
"cacheArguments": [],
"type": "configure"
}
]== "CMake Server" ==]
```
```
[== "CMake Server" ==[
{"type":"compute"}
]== "CMake Server" ==]
```
```
[== "CMake Server" ==[
{"type":"codemodel"}
]== "CMake Server" ==]
```
---
This was originally reported at https://bugreports.qt.io/browse/QTCREATORBUG-174963.7.2Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16531cmake -E server asserts on many projects2017-05-04T16:23:52-04:00Aleixcmake -E server asserts on many projectsWhile testing the server mode I found this crash to happen quite often, I'm not sure if I'm doing something wrong, though.
Here's the backtrace:
```
#0 0x00007ffff628604f in raise () from /usr/lib/libc.so.6
#1 0x00007ffff628747a in ab...While testing the server mode I found this crash to happen quite often, I'm not sure if I'm doing something wrong, though.
Here's the backtrace:
```
#0 0x00007ffff628604f in raise () from /usr/lib/libc.so.6
#1 0x00007ffff628747a in abort () from /usr/lib/libc.so.6
#2 0x00007ffff627eea7 in __assert_fail_base () from /usr/lib/libc.so.6
#3 0x00007ffff627ef52 in __assert_fail () from /usr/lib/libc.so.6
#4 0x0000000000bafb30 in cmRealDirectoryWatcher::cmRealDirectoryWatcher (this=0x1656b50, p=0x164c7c0, ps="") at /home/apol/devel/tools/cmake/Source/cmFileMonitor.cxx:154
#5 0x0000000000bade7a in cmDirectoryWatcher::cmDirectoryWatcher (this=0x1656b50, p=0x164c7c0, ps="") at /home/apol/devel/tools/cmake/Source/cmFileMonitor.cxx:222
#6 0x0000000000bad3bb in cmFileMonitor::MonitorPaths(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int)>) (
this=0x118ec30, paths=std::vector of length 115, capacity 128 = {...}, cb=...) at /home/apol/devel/tools/cmake/Source/cmFileMonitor.cxx:348
#7 0x0000000000b9bc00 in cmServerProtocol1_0::ProcessConfigure (this=0x118f090, request=...) at /home/apol/devel/tools/cmake/Source/cmServerProtocol.cxx:1003
#8 0x0000000000b98fb3 in cmServerProtocol1_0::Process (this=0x118f090, request=...) at /home/apol/devel/tools/cmake/Source/cmServerProtocol.cxx:434
#9 0x0000000000b8fd25 in cmServer::PopOne (this=0x7fffffffc7a8) at /home/apol/devel/tools/cmake/Source/cmServer.cxx:96
#10 0x0000000000b92184 in cmServer::QueueRequest (this=0x7fffffffc7a8, request="{\n \"cacheArguments\": [],\n \"type\": \"configure\"\n}\n")
at /home/apol/devel/tools/cmake/Source/cmServer.cxx:145
#11 0x0000000000b95229 in cmServerConnection::ReadData (this=0x118eff0, data="]== \"CMake Server\" ==]\n") at /home/apol/devel/tools/cmake/Source/cmServerConnection.cxx:194
#12 0x0000000000b95945 in (anonymous namespace)::on_read (stream=0x118f350, nread=23, buf=0x7fffffff8c88) at /home/apol/devel/tools/cmake/Source/cmServerConnection.cxx:31
#13 0x0000000000d47ebb in uv__read (stream=0x118f350) at /home/apol/devel/tools/cmake/Utilities/cmlibuv/src/unix/stream.c:1197
#14 0x0000000000d44f8c in uv__stream_io (loop=0x11777e0 <default_loop_struct>, w=0x118f3d8, events=1) at /home/apol/devel/tools/cmake/Utilities/cmlibuv/src/unix/stream.c:1264
#15 0x0000000000d4e134 in uv__io_poll (loop=0x11777e0 <default_loop_struct>, timeout=-1) at /home/apol/devel/tools/cmake/Utilities/cmlibuv/src/unix/linux-core.c:382
#16 0x0000000000d3c86f in uv_run (loop=0x11777e0 <default_loop_struct>, mode=UV_RUN_DEFAULT) at /home/apol/devel/tools/cmake/Utilities/cmlibuv/src/unix/core.c:352
#17 0x0000000000b94eb4 in cmServerConnection::ProcessEvents (this=0x118eff0, errorMessage=0x7fffffffc788) at /home/apol/devel/tools/cmake/Source/cmServerConnection.cxx:156
#18 0x0000000000b9235d in cmServer::Serve (this=0x7fffffffc7a8, errorMessage=0x7fffffffc788) at /home/apol/devel/tools/cmake/Source/cmServer.cxx:237
#19 0x000000000077c825 in cmcmd::ExecuteCMakeCommand (args=std::vector of length 4, capacity 4 = {...}) at /home/apol/devel/tools/cmake/Source/cmcmd.cxx:959
#20 0x000000000077283e in do_command (ac=5, av=0x118e970) at /home/apol/devel/tools/cmake/Source/cmakemain.cxx:95
#21 0x0000000000772015 in main (ac=5, av=0x118e970) at /home/apol/devel/tools/cmake/Source/cmakemain.cxx:168
```
Here's the input I send:
```
[== "CMake Server" ==[
{
"buildDirectory": "/home/apol/build-devel/frameworks/analitza",
"cookie": "",
"generator": "Ninja",
"major": 1,
"protocolVersion": {
"major": 1
},
"sourceDirectory": "/home/apol/devel/frameworks/analitza",
"type": "handshake"
}
]== "CMake Server" ==]
[== "CMake Server" ==[
{
"cacheArguments": [],
"type": "configure"
}
]== "CMake Server" ==]
```
Here's the full conversation log:
```
apol@oliver:~/build-devel/frameworks/analitza$ /home/apol/tmp/cmakeinstallprefix/bin/cmake -E server --debug --experimental
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"isExperimental":true,"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{
"buildDirectory": "/home/apol/build-devel/frameworks/analitza",
"cookie": "",
"generator": "Ninja",
"major": 1,
"protocolVersion": {
"major": 1
},
"sourceDirectory": "/home/apol/devel/frameworks/analitza",
"type": "handshake"
}
]== "CMake Server" ==]
[== "CMake Server" ==[
{
"cacheArguments": [],
"type": "configure"
}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":149,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":224,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":299,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":375,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":449,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":525,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":599,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":674,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":750,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":825,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":899,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","message":"\n-- The following OPTIONAL packages have been found:\n\n * OpenGL , <http://opengl.org>\n Support for 3D graphs in Analitza\n * Eigen3\n\n-- The following REQUIRED packages have been found:\n\n * ECM (required version >= 1.7.0)\n * Qt5Gui (required version >= 5.8.0)\n * Qt5Widgets\n * Qt5Xml\n * Qt5Svg\n * Qt5Test\n * Qt5Network (required version >= 5.8.0)\n * Qt5Qml\n * Qt5Quick\n * Qt5 (required version >= 5.2)\n * Qt5Core\n * Qt5OpenGL (required version >= 5.2)\n","type":"message"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":908,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":916,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":924,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":933,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":941,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":950,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":958,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":966,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":974,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":983,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":991,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","progressCurrent":1000,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","message":"Configuring done","type":"message"}
]== "CMake Server" ==]
cmake: /home/apol/devel/tools/cmake/Source/cmFileMonitor.cxx:154: cmRealDirectoryWatcher::cmRealDirectoryWatcher(cmVirtualDirectoryWatcher *, const std::string &): Assertion `!ps.empty()' failed.
Aborted (core dumped)
```3.7.2Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16506cmake-server doesn't call ResetErrorOccuredFlag2017-05-04T16:23:52-04:00vector-of-boolcmake-server doesn't call ResetErrorOccuredFlagThe Qt and Curses UIs both call `ResetErrorOccuredFlag` before executing configure, but `cmake-server` does not do so. This means that once an error has occurred during a configure execution, all subsequent configure attempts will fail i...The Qt and Curses UIs both call `ResetErrorOccuredFlag` before executing configure, but `cmake-server` does not do so. This means that once an error has occurred during a configure execution, all subsequent configure attempts will fail immediately. `cmake-server` must be restarted to configure successfully.3.7.2Tobias HungerTobias Hungerhttps://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/16770cmake source tarballs and zips contain Tests/Server/cmakelib.pyc2017-04-17T20:46:37-04:00Dan Kegelcmake source tarballs and zips contain Tests/Server/cmakelib.pycAffects 3.8.0-rc4.
Compiled python should never be included in a source tarball, as it's system-dependent.
Possible fix (completely untested and possibly mistaken):
```
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
...Affects 3.8.0-rc4.
Compiled python should never be included in a source tarball, as it's system-dependent.
Possible fix (completely untested and possibly mistaken):
```
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -214,6 +214,9 @@ if(CPACK_GENERATOR MATCHES "CygwinSource")
"/CVS/" "/\\.build/" "/\\.svn/" "\\.swp$" "\\.#" "/#" "~$")
endif()
+# Never include compile python (e.g. Tests/Server/cmakelib.pyc)
+LIST(APPEND CPACK_SOURCE_IGNORE_FILES "\\.pyc$")
+
if("${CPACK_GENERATOR}" STREQUAL "PackageMaker")
if(CMAKE_PACKAGE_QTGUI)
set(CPACK_PACKAGE_DEFAULT_LOCATION "/Applications")
```3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16763ExternalProject: regression in remote branch checkout2017-04-03T23:02:56-04:00Henry SchreinerExternalProject: regression in remote branch checkoutThe following MWE will work on 3.7 but not 3.8rc4:
```cmake
cmake_minimum_required(VERSION 3.7.0)
project(Foo)
include(ExternalProject)
ExternalProject_Add(gitTest
GIT_REPOSITORY https://github.com/githubtraining/hellogitw...The following MWE will work on 3.7 but not 3.8rc4:
```cmake
cmake_minimum_required(VERSION 3.7.0)
project(Foo)
include(ExternalProject)
ExternalProject_Add(gitTest
GIT_REPOSITORY https://github.com/githubtraining/hellogitworld.git
GIT_TAG bisect
CONFIGURE_COMMAND ""
BUILD_COMMAND echo "Built"
INSTALL_COMMAND ""
TEST_COMMAND ""
)
```
The problem is the addition of `--` after the branch name in the git checkout command in `gitTest-prefix/tmp/gitTest-gitclone.cmake` only in 3.8; this is trying to be smart and not clash with a file name, but it also changes the behavior of the git command when you are trying to get a branch that does not exist locally in your cloned repository (i.e., any branch other than master). In this case, `git checkout bisect` works as expected but `git checkout bisect --` fails miserably because `bisect` doesn't refer to a local branch.
(I don't like that git behavior personally, but that's the way it works)3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16746SDCC project generation seems to be broken2017-04-03T23:02:56-04:00bartoszSDCC project generation seems to be brokencalling:
`cmake -DCMAKE_TOOLCHAIN_FILE=sdcc-toolchain.cmake -G "MinGW Makefiles"`
result:
```
-- The C compiler identification is unknown
-- Check for working C compiler: x:/tools/sdcc/bin/sdcc.exe
-- Check for working C compile...calling:
`cmake -DCMAKE_TOOLCHAIN_FILE=sdcc-toolchain.cmake -G "MinGW Makefiles"`
result:
```
-- The C compiler identification is unknown
-- Check for working C compiler: x:/tools/sdcc/bin/sdcc.exe
-- Check for working C compiler: x:/tools/sdcc/bin/sdcc.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.8/Modules/CMakeTestCCompiler.cmake:51 (message):
The C compiler "x:/tools/sdcc/bin/sdcc.exe" is not able to compile a simple test program.
It fails with the following output:
Change Dir: X:/work/scratchpad/test/CMakeFiles/CMakeTmp
Run Build Command:"C:/msys64/mingw64/bin/mingw32-make.exe" "cmTC_1e390/fast"
C:/msys64/mingw64/bin/mingw32-make.exe -f CMakeFiles\cmTC_1e390.dir\build.make CMakeFiles/cmTC_1e390.dir/build
mingw32-make.exe[1]: Entering directory
'X:/work/scratchpad/test/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_1e390.dir/testCCompiler.c.obj
x:\tools\sdcc\bin\sdcc.exe -o CMakeFiles\cmTC_1e390.dir\testCCompiler.c.obj -c
X:\work\scratchpad\test\CMakeFiles\CMakeTmp\testCCompiler.c
Linking C executable cmTC_1e390
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_link_script
CMakeFiles\cmTC_1e390.dir\link.txt --verbose=1
x:\tools\sdcc\bin\sdcc.exe CMakeFiles/cmTC_1e390.dir/testCCompiler.c.obj -o
cmTC_1e390
at 1: error 119: don't know what to do with file
'CMakeFiles/cmTC_1e390.dir/testCCompiler.c.obj'. file extension
unsupported
```
sdcc is placed at: x:/tools/sdcc/bin/sdcc.exe
sdcc-toolchain.cmake:
```cmake
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER "x:/tools/sdcc/bin/sdcc.exe")
set(CMAKE_FIND_ROOT_PATH "x:/tools/sdcc")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
```
CMakeLists.txt:
```cmake
project (test LANGUAGES C)
add_executable (myTest main.c)
```
main.c:
```c
int main()
{
return 0;
}
```
copying: `c:\Program Files\CMake\share\cmake-3.8\Modules\Platform\Generic-SDCC-C.cmake`
to: `c:\Program Files\CMake\share\cmake-3.8\Modules\Platform\Generic-sdcc.cmake` resolves problem:
```
cmake -DCMAKE_TOOLCHAIN_FILE=sdcc-toolchain.cmake -G "MinGW Makefiles"
-- The C compiler identification is unknown
-- Check for working C compiler: x:/tools/sdcc/bin/sdcc.exe
-- Check for working C compiler: x:/tools/sdcc/bin/sdcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: X:/work/scratchpad/
```
of course i can always use:
```cmake
include (CMakeForceCompiler)
CMAKE_FORCE_C_COMPILER ("x:/tools/sdcc/bin/sdcc.exe" SDCC)
```
but it is extremity
3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16745MSVC: mising _DEBUG flag for RC compiler in debug configuration2019-05-16T09:40:08-04:00LuděkMSVC: mising _DEBUG flag for RC compiler in debug configurationAfter removing `_DEBUG` flag from CXX and C debug flags (Issue #16430) resource compiler now can't distinguish between release and debug configuration.
Is there a way other than putting `/D_DEBUG` back to debug C anc CXX flags so constr...After removing `_DEBUG` flag from CXX and C debug flags (Issue #16430) resource compiler now can't distinguish between release and debug configuration.
Is there a way other than putting `/D_DEBUG` back to debug C anc CXX flags so construct like this:
```c
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG
#else
FILEFLAGS 0
#endif
```
in .rc file will work again.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16742Swift compiler identification fails with Xcode 8.3 (and macOS 10.12.4)2017-07-12T11:33:23-04:00Guillaume EglesSwift compiler identification fails with Xcode 8.3 (and macOS 10.12.4)After upgrading to macOS 10.12.4 and Xcode 8.3, CMake is not able to properly detect the Swift compiler anymore...
Steps to repro:
Minimal CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.8)
set(CMAKE_Swift_LANGUAGE_VERSION ...After upgrading to macOS 10.12.4 and Xcode 8.3, CMake is not able to properly detect the Swift compiler anymore...
Steps to repro:
Minimal CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.8)
set(CMAKE_Swift_LANGUAGE_VERSION 3.0)
set(CMAKE_XCODE_ATTRIBUTE_SWIFT_VERSION "3.0")
enable_language(Swift)
```
Produces the following error:
```
➜ cmake -GXcode ..
-- The C compiler identification is AppleClang 8.1.0.8020038
-- The CXX compiler identification is AppleClang 8.1.0.8020038
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- 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: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The Swift compiler identification is unknown
CMake Error at CMakeLists.txt:6 (enable_language):
No CMAKE_Swift_COMPILER could be found.
```3.8.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16741Problem with archive_write_header(): Can't replace existing directory with no...2018-08-07T13:14:47-04:00MvdHurkProblem with archive_write_header(): Can't replace existing directory with non-directoryFrom CMake 3.6.3 until 3.8.0-RC3 unpacking a **Java archive data (JAR)** containing a directory reference it doesn't work:
> CMake Error: Problem with archive_write_header(): Can't replace existing directory with non-directory
> CMak...From CMake 3.6.3 until 3.8.0-RC3 unpacking a **Java archive data (JAR)** containing a directory reference it doesn't work:
> CMake Error: Problem with archive_write_header(): Can't replace existing directory with non-directory
> CMake Error: Current file: test/
> CMake Error: Problem extracting tar: ../test.zip
Where test.zip contains:
> Archive: test.zip
> Length Date Time Name
> --------- ---------- ----- ----
> 0 03-27-2017 20:21 test/
> 0 03-27-2017 20:21 test/test2/
> 0 03-27-2017 20:21 test/test2/testfile.txt
> 0 03-27-2017 20:19 test/testfile.txt
> --------- -------
This did work with 3.5.2 when executing before: *cmake -E tar xzf test.zip* and does work in CMake 3.6.3 and later when the file type is a **Zip archive data** instead.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16737InstallRequiredSystemLibraries does not find VS 2017 redist directory2017-11-15T08:56:54-05:00Brad KingInstallRequiredSystemLibraries does not find VS 2017 redist directoryThe `InstallRequiredSystemLibraries` module still uses registry entries to locate the VS redist directories. VS 2017 does not provide registry entries. Instead we need to somehow use `cmVSSetupHelper` (added by !337) to locate the redi...The `InstallRequiredSystemLibraries` module still uses registry entries to locate the VS redist directories. VS 2017 does not provide registry entries. Instead we need to somehow use `cmVSSetupHelper` (added by !337) to locate the redist directory, even when not using the `Visual Studio 15 2017` generator.
Furthermore, the redist directories sit under a version-numbered directory such as `VC/Redist/MSVC/14.10.25008`.
3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16736symlinked source directory trips up cmake server (CMAKE_HOME_DIRECTORY is set...2017-09-18T08:55:59-04:00Milian Wolffsymlinked source directory trips up cmake server (CMAKE_HOME_DIRECTORY is set but incompatible with configured source directory value)To reproduce:
```
cd /tmp
mkdir sources
touch sources/CMakeLists.txt
ln -s sources symlinked-sources
mkdir build
cd build
cmake /tmp/sources
cmake -E server --experimental --debug
[== "CMake Server" ==[
{"supportedProtocol...To reproduce:
```
cd /tmp
mkdir sources
touch sources/CMakeLists.txt
ln -s sources symlinked-sources
mkdir build
cd build
cmake /tmp/sources
cmake -E server --experimental --debug
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"isExperimental":true,"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"buildDirectory":"/tmp/build","cookie":null,"generator":"Unix Makefiles","major":1,"protocolVersion":{"major":1},"sourceDirectory":"/tmp/symlinked-sources","type":"handshake"}
]== "CMake Server" ==]
[== "CMake Server" ==[
{"cookie":"","errorMessage":"Failed to activate protocol version: \"CMAKE_HOME_DIRECTORY\" is set but incompatible with configured source directory value.","inReplyTo":"handshake","type":"error"}
]== "CMake Server" ==]
```
I suggest to only compare canonical paths3.8.0Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16735No Visual Studio 2017 support in Windows-MSVC.cmake, FindwxWidgets.cmake and ...2018-03-19T11:56:54-04:00Mikhail PilinNo Visual Studio 2017 support in Windows-MSVC.cmake, FindwxWidgets.cmake and InstallRequiredSystemLibraries.cmakeFollowing issues were found:
* `MSVC15` was not defined in `Windows-MSVC.cmake`. MS C++ compiler versions:
* VS2017 - 19.10
* VS2015 - 19.00
* Add `MSVC15` conditions in `FindwxWidgets.cmake`:
```
...
if(MSVC15)
set(_WX_TO...Following issues were found:
* `MSVC15` was not defined in `Windows-MSVC.cmake`. MS C++ compiler versions:
* VS2017 - 19.10
* VS2015 - 19.00
* Add `MSVC15` conditions in `FindwxWidgets.cmake`:
```
...
if(MSVC15)
set(_WX_TOOLVER 141)
elseif(MSVC14)
...
```
* Add `MSVC15` conditions in `InstallRequiredSystemLibraries.cmake`:
```
if(MSVC15)
MSVCRT_FILES_FOR_VERSION(15)
endif()
...
if(MSVC15)
MFC_FILES_FOR_VERSION(15)
endif()
...
if(MSVC15)
OPENMP_FILES_FOR_VERSION(15 141)
endif()
...
```3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16722Ninja Fortran dependencies missing generated include files2017-04-03T23:02:56-04:00Bernhard BurgermeisterNinja Fortran dependencies missing generated include filesWe are using cmake together with ninja for build a combined C/C++/Fortran project. Some rebuilds after a full build or broken builds could be tracked down to missing dependencies of Fortran files on generated Fortran include files (We ar...We are using cmake together with ninja for build a combined C/C++/Fortran project. Some rebuilds after a full build or broken builds could be tracked down to missing dependencies of Fortran files on generated Fortran include files (We are using perl to convert a C header file to a Fortran include file).
In the attached archive [cmake_ninja_dep_test.tgz](/uploads/341b76d30b2a65c596082f6b3268e863/cmake_ninja_dep_test.tgz) I created a small example project that shows this bug. To reproduce the bug please perform the steps:
* Generate a ninja build directory
* Run ninja build -> works fine
* Change the file "in.ins", e.g. change the number
* Run ninja -> only out.ins is updated, but not the Fortran source file including this generated file
* Run ninja again -> now the Fortran compiler is called for the Fortran source file because out.ins is newer
Expected behaviour would be that first ninja run after changing the input include file updates all dependent files.
Tested with cmake-3.7.2 and 3.8.20170317-g45851, ninja-1.7.2.git.kitware.dyndep-1.
With Unix Makefiles the dependencies are considered correctly.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16718Regression when building ParaView with an external HDF52017-04-03T23:02:56-04:00Ben BoeckelRegression when building ParaView with an external HDF5Bisecting now.Bisecting now.3.8.0Brad KingBrad King