CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-12-14T11:54:19-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/17213Support Windows ARM64 Target2017-12-14T11:54:19-05:00Force.Charlie-ISupport Windows ARM64 Target`Visual Studio 15.4 Preview 1` has been released recently, `15.4 Preview 1` added `Visual C + + compilers and libraries for ARM64`. Hope CMake Timely support
Current Visual Studio Preview version: **15.4.26823.1**
![image](/uploads/2d2...`Visual Studio 15.4 Preview 1` has been released recently, `15.4 Preview 1` added `Visual C + + compilers and libraries for ARM64`. Hope CMake Timely support
Current Visual Studio Preview version: **15.4.26823.1**
![image](/uploads/2d2f34b329a04358ce18e50b5e4d8ef2/image.png)
Users can also choose EWDK to support ARM64, Download URL:
https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewWDK3.10.0https://gitlab.kitware.com/cmake/cmake/-/issues/17198ExternalProject: Additional command specified by COMMAND stop working2017-09-05T09:31:07-04:00Ruslan Baratovx@ruslo.devExternalProject: Additional command specified by COMMAND stop workingProject:
```cmake
cmake_minimum_required(VERSION 3.0)
project(foo)
include(ExternalProject)
ExternalProject_Add(
Foo
DOWNLOAD_COMMAND
""
CONFIGURE_COMMAND
"${CMAKE_COMMAND}" -E echo "part 1"
COMMAND
"${CMAKE...Project:
```cmake
cmake_minimum_required(VERSION 3.0)
project(foo)
include(ExternalProject)
ExternalProject_Add(
Foo
DOWNLOAD_COMMAND
""
CONFIGURE_COMMAND
"${CMAKE_COMMAND}" -E echo "part 1"
COMMAND
"${CMAKE_COMMAND}" -E echo "part 2" ### <<<<<< Command lost!
BUILD_COMMAND
""
INSTALL_COMMAND
""
)
```
Works with CMake 3.9.1:
```
> cmake --version
cmake version 3.9.1
> rm -rf _builds
> cmake -H. -B_builds
> cmake --build _builds
...
[ 62%] Performing configure step for 'Foo'
part 1
part 2
[ 75%] No build step for 'Foo'
...
```
Current version from branch `master`:
```
> cmake --version
cmake version 3.9.20170823
> rm -rf _builds
> cmake -H. -B_builds
> cmake --build _builds
...
[ 62%] Performing configure step for 'Foo'
part 1
[ 75%] No build step for 'Foo'
...
```3.10.0Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/17171VS: Need flag table entries for `-std:`2017-09-01T10:26:45-04:00Brad KingVS: Need flag table entries for `-std:`Follow-up discussion in #16482 pointed out that the MSVC `-std:` flags are not properly transformed to `.vcxproj` elements and are instead left in `AdditionalOptions`.Follow-up discussion in #16482 pointed out that the MSVC `-std:` flags are not properly transformed to `.vcxproj` elements and are instead left in `AdditionalOptions`.3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17125CPackIFW doesn't work properly on OSX2017-09-27T17:54:19-04:00Michele CainiCPackIFW doesn't work properly on OSXAccording to the [documentation](http://doc.qt.io/qtinstallerframework/ifw-tools.html#binarycreator) for `binarycreator`, to create an offline installer the command line is:
<location-of-ifw>/binarycreator -t <location-of-ifw>/insta...According to the [documentation](http://doc.qt.io/qtinstallerframework/ifw-tools.html#binarycreator) for `binarycreator`, to create an offline installer the command line is:
<location-of-ifw>/binarycreator -t <location-of-ifw>/installerbase -p <package_directory> -c <config_directory>/<config_file> <installer_name>
In particular:
>On Mac, the target is created as an application bundle with the extension .app, which is automatically added, if not supplied. Additionally, you can specify the .dmg extension, which creates a DMG disk image that contains an .app bundle.
There are a few problems with that:
* We cannot set `CPACK_PACKAGE_FILE_NAME` to something like `<name>.dmg`, for `CPack` considers it as a package file name without extension. Therefore it keeps adding `.app` at the end of the string and creating a bundle. In other terms, there is no way to create a `.dmg` by means of `CPackIFW` on OSX. On the other side, that's one of the most interesting feature of IFW, so I would consider it a bug of the module.
[This](https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Source/CPack/IFW/cmCPackIFWGenerator.cxx#L163) should be the offending code. At least, This is where the `<installer_name>` is appended to the command line to run `binarycreator`. I'm not sure where and how `.app` postfix is appended to `packageFileNames[0]` and I'm a bit busy to look over the whole code base of `CMake`, I'm sorry.
* The bundle isn't a file, it's a directory. Therefore, when `CPack` [tries to copy it over to the proper location](https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Source/CPack/cmCPackGenerator.cxx#L1007), it simply creates an empty directory and doesn't copy anything. On Linux it copies the `.sh` file, on Windows it copies the `.exe` file, on OSX it creates an empty directory and that's all. It could be due to how `cmSystemTools::CopyFileIfDifferent` works, but it's just a guess.
Of course, the bundle is present within the `_CPack_Packages` tree, but we must run custom scripts to move it out of it somehow and create a `.dmg`.3.10.0Konstantin PodsvirovKonstantin Podsvirovhttps://gitlab.kitware.com/cmake/cmake/-/issues/17101macOS: Check for utimensat and futimens does not consider deployment target2021-05-24T16:48:15-04:00Harry MallonmacOS: Check for utimensat and futimens does not consider deployment targetBuilding CMake using the macOS 10.13 SDK finds `utimensat` and `futimens` even if the deployment target is less than 10.13, and older versions do not provide the symbols.
Minimal example with cmake 3.9.0. Using gtest (from our normal bu...Building CMake using the macOS 10.13 SDK finds `utimensat` and `futimens` even if the deployment target is less than 10.13, and older versions do not provide the symbols.
Minimal example with cmake 3.9.0. Using gtest (from our normal build) and a temporary zip file I made with "Compress..." in Finder.
```
$ cmake -E tar xfz /Developer/SDKs/gtest/gtest-1.7.0.zip
dyld: lazy symbol binding failed: Symbol not found: _futimens
Referenced from: /usr/local/bin/cmake
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _futimens
Referenced from: /usr/local/bin/cmake
Expected in: /usr/lib/libSystem.B.dylib
Abort trap: 6
$ cmake -E tar xfz temp.zip
dyld: lazy symbol binding failed: Symbol not found: _utimensat
Referenced from: /usr/local/bin/cmake
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _utimensat
Referenced from: /usr/local/bin/cmake
Expected in: /usr/lib/libSystem.B.dylib
Abort trap: 6
```3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17082CMake can no longer bootstrap repeatedly in-source2017-09-24T20:35:07-04:00Lilian MoraruCMake can no longer bootstrap repeatedly in-sourceI've compiled CMake inside Habitat until now(in the link, in `do_build` you can see the steps used to build CMake): https://bldr.habitat.sh/#/pkgs/lilian/cmake/3.8.2/20170611011856
Note, compiler: GCC 7.1
Same build process switched fr...I've compiled CMake inside Habitat until now(in the link, in `do_build` you can see the steps used to build CMake): https://bldr.habitat.sh/#/pkgs/lilian/cmake/3.8.2/20170611011856
Note, compiler: GCC 7.1
Same build process switched from CMake 3.8.2 archive to 3.9.0 archive, results in these errors:
```
/hab/cache/src/cmake-3.9.0/Source/cmSystemTools.cxx: In static member function 'static void cmSystemTools::FindCMakeResources(const char*)':
/hab/cache/src/cmake-3.9.0/Source/cmSystemTools.cxx:2061:13: error: 'CMAKE_BOOTSTRAP_BINARY_DIR' was not declared in this scope
exe_dir = CMAKE_BOOTSTRAP_BINARY_DIR "/bin";
^~~~~~~~~~~~~~~~~~~~~~~~~~
/hab/cache/src/cmake-3.9.0/Source/cmSystemTools.cxx:2061:13: note: suggested alternative: 'CMAKE_BIN_DIR'
exe_dir = CMAKE_BOOTSTRAP_BINARY_DIR "/bin";
^~~~~~~~~~~~~~~~~~~~~~~~~~
CMAKE_BIN_DIR
/hab/cache/src/cmake-3.9.0/Source/cmSystemTools.cxx:2121:28: error: 'CMAKE_BOOTSTRAP_SOURCE_DIR' was not declared in this scope
cmSystemToolsCMakeRoot = CMAKE_BOOTSTRAP_SOURCE_DIR;
^~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:300: cmSystemTools.o] Error 1
---------------------------------------------
Error when bootstrapping CMake:
Problem while running make
---------------------------------------------
Log of errors: /hab/cache/src/cmake-3.9.0/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------
```
I also attached `cmake_bootstrap.log`.
[cmake_bootstrap.log](/uploads/6125a2507e5872630ce582554d0d4e56/cmake_bootstrap.log)3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16953Request for "CUDA_COMPILER_LAUNCHER"2019-08-07T17:34:34-04:00Luke YeagerRequest for "CUDA_COMPILER_LAUNCHER"ccache support for nvcc is coming (https://github.com/ccache/ccache/pull/145). It works great - not sure yet when/if it will be merged.
If I try to set the `CUDA_NVCC_EXECUTABLE` variable to use ccache like this:
```
cmake .. -DCUDA_NVC...ccache support for nvcc is coming (https://github.com/ccache/ccache/pull/145). It works great - not sure yet when/if it will be merged.
If I try to set the `CUDA_NVCC_EXECUTABLE` variable to use ccache like this:
```
cmake .. -DCUDA_NVCC_EXECUTABLE='/usr/local/bin/ccache /usr/local/cuda/bin/nvcc'
```
then I get a very unhelpful error:
```
CMake Error at /usr/local/share/cmake-3.8/Modules/FindCUDA.cmake:702 (string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.
Call Stack (most recent call first):
cmake/Cuda.cmake:172 (find_package)
cmake/Dependencies.cmake:285 (include)
CMakeLists.txt:72 (include)
CMake Error at /usr/local/share/cmake-3.8/Modules/FindCUDA.cmake:703 (string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.
Call Stack (most recent call first):
cmake/Cuda.cmake:172 (find_package)
cmake/Dependencies.cmake:285 (include)
CMakeLists.txt:72 (include)
-- Could NOT find CUDA: Found unsuitable version ".", but required is at least "7.0" (found /usr/local/cuda)
```
Turns out this command fails when `CUDA_NVCC_EXECUTABLE` is not a simple path to an executable:
https://gitlab.kitware.com/cmake/cmake/blob/v3.8.2/Modules/FindCUDA.cmake#L701
Either of these flags solves the issue:
```
-DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda-8.0
-DCUDA_VERSION=8.0
```
Alternatively, I can create a symlink named `nvcc` which points to the `ccache` binary, and use THAT as my `CUDA_NVCC_EXECUTABLE`, but then I have to make sure `nvcc` is on my path (which is not usually necessary when building with CMake).
The more complete approach would be to add support for something like `CUDA_COMPILER_LAUNCHER`, in the spirit of https://gitlab.kitware.com/cmake/cmake/commit/698f75971bee336133d21260db069bb139bd3d76.3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16950FindHTMLHelp does not find hhc when using VisualStudio 2017 native tools prompt2017-06-12T10:20:25-04:00Anders BromanFindHTMLHelp does not find hhc when using VisualStudio 2017 native tools promptFindHTMLHelp needs to look in more locations, Program Files (x86). If PATH is not set.[FindHTMLHelp.cmake](/uploads/7040454a74a92970ca45a17472a00531/FindHTMLHelp.cmake)FindHTMLHelp needs to look in more locations, Program Files (x86). If PATH is not set.[FindHTMLHelp.cmake](/uploads/7040454a74a92970ca45a17472a00531/FindHTMLHelp.cmake)3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16892file(GENERATE): Issue when resolving relative path of a file which contains ...2017-06-09T11:04:04-04:00Aregnaz Harutyunyanfile(GENERATE): Issue when resolving relative path of a file which contains more than one slash in a row.When generating files with full path containing more than one "/"(slashes} in a row in the path, it causes re-configuration of the project upon each build phase, despite the fact that build tree/sources have not been updated.
The issu...When generating files with full path containing more than one "/"(slashes} in a row in the path, it causes re-configuration of the project upon each build phase, despite the fact that build tree/sources have not been updated.
The issue is caused by the fact that the generated file is listed in the CMAKE_MAKEFILE_PRODUCTS with the wrong path.
Which is due to the fact that the relative path of the file is resolved incorrectly.
***Step to reproduce:***
1. Create a CMakeLists.txt with the following content:
```
set(file_path ${CMAKE_BINARY_DIR}//a_file.txt)
file(GENERATE OUTPUT ${file_path} CONTENT "Generating file with 2 times in a row slashes to check
relative path resolution for this file when build byproducts are generated")
```
2. Configure a build directory referring to the above created cmake list file.
```
> mkdir build
> cd build
> cmake _path_to/CMakeLists.txt
```
3. Now build the project
```
> make
```
***Actual result:***
The project is configured one more time before build, as "/a_file.txt" byproduct dependency/existence is never satisfied.
***Expected result:***
The project should not be configured upon build, unless anything is changed in the build tree or in the sources.
***Details:***
When cmake makefile products list is generated, all byproducts are resolved relative to CMAKE_BINARY_DIR.
AND if byproduct path contains double slashes, the relative path is resolved incorrectly.
When the path is split into components and later joined to construct final relative path, empty components are not skipped which causes the issue.
E.g.
- Input directory is `/A/B/C`
- File path to be resolved relatively - `/A/B/C//D/E/F`
- Returned relative path - `/D/E/F`
The issue can be fixed by applying the following patch:
```
--- a/Source/kwsys/SystemTools.cxx 2017-05-16 16:32:37.662429395 +0200
+++ b/Source/kwsys/SystemTools.cxx 2017-05-16 15:29:26.882429395 +0200
@@ -4225,13 +4225,16 @@
if(*last == '/' || *last == '\\')
{
// End of a component. Save it.
- components.push_back(std::string(first, last));
+ if(first != last)
+ {
+ components.push_back(std::string(first, last));
+ }
first = last+1;
}
}
// Save the last component unless there were no components.
- if(last != c)
+ if(last != c && first != last)
{
components.push_back(std::string(first, last));
}
```
[kwsys_SystemTools.cxx.patch](/uploads/f2e4d77f25bcefe74a369c812f879eac/kwsys_SystemTools.cxx.patch)3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16803Opt-in to new Win32 API that allows paths longer than 260 characters2017-10-18T10:23:30-04:00Taylor Braun-JonesOpt-in to new Win32 API that allows paths longer than 260 charactersCPack fails when packaging files in a deeply nested tree with total path length greater than 260 characters:
```
CPack Error: ERROR while packaging files: Error opening "some/long/filepath...": No such file or directory
```
Globally op...CPack fails when packaging files in a deeply nested tree with total path length greater than 260 characters:
```
CPack Error: ERROR while packaging files: Error opening "some/long/filepath...": No such file or directory
```
Globally opting in to the new Win32 API for the entire system fixes the problem (by enabling registry key `HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled` on Windows 10 build 1607 or newer) but CMake binaries should opt-in so this registry change is not necessary by enabling the `ws2:longPathAware` option in the manifest:
```xml
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
```
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
Note that this is somewhat counter to the proposal in #164853.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16786file(GENERATE) reads and writes relative to CMAKE_BINARY_DIR2017-06-12T10:15:52-04:00Craig Scottfile(GENERATE) reads and writes relative to CMAKE_BINARY_DIRWhen a relative path is given for the `OUTPUT` of `file(GENERATE)`, the path is interpreted as being relative to `CMAKE_BINARY_DIR`. This seems inconsistent with most other CMake commands which are generally interpreted as being relativ...When a relative path is given for the `OUTPUT` of `file(GENERATE)`, the path is interpreted as being relative to `CMAKE_BINARY_DIR`. This seems inconsistent with most other CMake commands which are generally interpreted as being relative to `CMAKE_CURRENT_BINARY_DIR`. Similarly, a relative path for `INPUT` also seems to be interpreted as being relative to `CMAKE_SOURCE_DIR` rather than `CMAKE_CURRENT_SOURCE_DIR`. Presumably, this is a consequence of the file writing being delayed to the generation phase rather than being performed immediately at the point of the call during the configure phase, but the difference in behaviour compared to most other commands makes this unexpected. The docs make no mention of the different relative path behaviour either, so I'm wondering if this is deliberate and simply omitted from the docs or whether it is indeed a bug in the `file(GENERATE)` behaviour.3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16482MSVC standard version switches2018-03-31T07:42:05-04:00Nils GladitzMSVC standard version switchesVisual Studio C++ 2015 Update 3 introduced standard version switches [1].
They seem to only make sense for >= C++14 which I assume becomes relevant with the changes in !299 (#16468).
Specifically for C++17 features `/std:c++latest`...Visual Studio C++ 2015 Update 3 introduced standard version switches [1].
They seem to only make sense for >= C++14 which I assume becomes relevant with the changes in !299 (#16468).
Specifically for C++17 features `/std:c++latest` (and later `/std:c++17`) might be required.
<br/>
[1] https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16266Ninja generator passes -std option to clang-cl2018-02-20T16:28:55-05:00Jørgen IbsenNinja generator passes -std option to clang-clWhen Ninja is targeting Clang's MSVC compatible tools (clang-cl), and you require a certain C++ version, it passes the `-std` option, which Clang 3.8.1 does not accept.
For this example:
~~~.cmake
cmake_minimum_required(VERSION 3.6)...When Ninja is targeting Clang's MSVC compatible tools (clang-cl), and you require a certain C++ version, it passes the `-std` option, which Clang 3.8.1 does not accept.
For this example:
~~~.cmake
cmake_minimum_required(VERSION 3.6)
project(foo CXX)
add_executable(foo foo.cpp)
set_property(TARGET foo PROPERTY CXX_STANDARD "11")
set_property(TARGET foo PROPERTY CXX_STANDARD_REQUIRED TRUE)
~~~
~~~.cpp
int main() { auto i = 5; }
~~~
I get:
~~~
[1/2] Building CXX object CMakeFiles\foo.dir\foo.cpp.obj
FAILED: CMakeFiles/foo.dir/foo.cpp.obj
D:\LLVM\msbuild-bin\cl.exe /nologo /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -std=gnu++11 /showIncludes /FoCMakeFiles\foo.dir\foo.cpp.obj /FdCMakeFiles\foo.dir\ -c foo.cpp
clang-cl.exe: error: unknown argument: '-std=gnu++11'
ninja: build stopped: subcommand failed.
~~~
3.10.0https://gitlab.kitware.com/cmake/cmake/-/issues/17526CMake 3.10.0: Clang 5 with -std=gnu++1z problem2017-12-05T14:44:55-05:00AdamCMake 3.10.0: Clang 5 with -std=gnu++1z problemIt seems like some versions of clang 5 (with libc++) have problem with `#include <unordered_map>` when `-std=gnu++1z` option has been given. In such case, compiler fails with:
```
/usr/include/c++/__hash_table:1134:43: error: conflicting...It seems like some versions of clang 5 (with libc++) have problem with `#include <unordered_map>` when `-std=gnu++1z` option has been given. In such case, compiler fails with:
```
/usr/include/c++/__hash_table:1134:43: error: conflicting types for '__hash_table<_Tp, _Hash, _Equal, _Alloc>'
```
To fix it, fall back to older C++ standards. The following patch fixes the problem:
```
--- bootstrap.orig
+++ bootstrap
@@ -1056,6 +1056,7 @@ TMPFILE=`cmake_tmp_file`
echo '
#include <iostream>
#include <memory>
+#include <unordered_map>
#if __cplusplus < 201103L
#error "Compiler is not in a mode aware of C++11."
```
I incorporated the fix in `cmake` package for PkgSrc.org: [http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/devel/cmake/patches/patch-bootstrap?rev=1.1&content-type=text/plain&only_with_tag=MAIN]3.10.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17518ToT Clang on Windows does not work2019-02-18T07:55:06-05:00Loo Rong JieToT Clang on Windows does not workIn October, CMake added a check to test if `--version` flag is available in clang [1]. If the flag is available, it should mean it is `clang.exe` or `clang++.exe` instead of `clang-cl.exe`.
However, `--version` was added into `clang-cl....In October, CMake added a check to test if `--version` flag is available in clang [1]. If the flag is available, it should mean it is `clang.exe` or `clang++.exe` instead of `clang-cl.exe`.
However, `--version` was added into `clang-cl.exe` as well in the same month [2]!
Please revert [1].
- [1]: https://gitlab.kitware.com/cmake/cmake/commit/b6d3a1c09a796ec0c29074c387953fb88ebfe874
- [2]: https://github.com/llvm-mirror/clang/commit/c5924addeeea29249ddbf048d3860c9e2198d2893.10.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17512CMAKE_CUDA_IMPLICIT_INCLUDE_DIRECTORIES not set2017-11-29T08:20:47-05:00Attila SzabóCMAKE_CUDA_IMPLICIT_INCLUDE_DIRECTORIES not set`/usr/share/cmake/Modules/Platform/UnixPaths.cmake`:
```
CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
```
This file should also specify `CMAKE_CUDA_IMPLICIT_INCLUDE_DIRECTORIES`, as CUDA is a supported lang...`/usr/share/cmake/Modules/Platform/UnixPaths.cmake`:
```
CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
```
This file should also specify `CMAKE_CUDA_IMPLICIT_INCLUDE_DIRECTORIES`, as CUDA is a supported language.
As a workaround, we specify `list(APPEND CMAKE_CUDA_IMPLICIT_INCLUDE_DIRECTORIES "${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES}")` in our root CMakeLists.txt.
This is a problem with CUDA 9 - GCC 6 combo. (GCC 6 uses include_next, and the non excluded -isystem paths mixes up its resolution)3.10.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17502Server: CMake memory footprint regressed significantly in CMake 3.10.02017-12-07T08:09:01-05:00Felix KälbererServer: CMake memory footprint regressed significantly in CMake 3.10.0CMake's memory consumption regressed significantly in CMake 3.10 when configuring our project in QtCreator:
CMake 3.9.6: 220MB / 200MB (max/final)
CMake 3.10-rc1: 1400MB / 250MB (max/final)
Memory rises from 200MB to 1400MB after the ...CMake's memory consumption regressed significantly in CMake 3.10 when configuring our project in QtCreator:
CMake 3.9.6: 220MB / 200MB (max/final)
CMake 3.10-rc1: 1400MB / 250MB (max/final)
Memory rises from 200MB to 1400MB after the "generating done" message appears.
This is when unit tests are not built. If I enable unit tests in our project, the configuration will fail at 2.8GB mem usage.
Our project is structured similarly to the attached sample project.
[CMakeTest.zip](/uploads/82653a46f68a4b6d4c82e26da0cf4d25/CMakeTest.zip)
This is a duplicate of https://bugreports.qt.io/browse/QTCREATORBUG-193423.10.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17278On macOS with Ninja generator, AUTOMOC fails with framework target dependency...2017-12-23T03:57:25-05:00Larry ShafferOn macOS with Ninja generator, AUTOMOC fails with framework target dependency under CMake 3.9Single project setup (see attached sample project [cmake_macos_fw_test.zip](/uploads/2374cd20ffdb6e8b0c8c6c463d96d611/cmake_macos_fw_test.zip)):
* Homebrew toolchain/dependencies CMake 3.9.2 (and 3.8.2), Ninja 1.7.2, Qt 5.9.1
* On macOS...Single project setup (see attached sample project [cmake_macos_fw_test.zip](/uploads/2374cd20ffdb6e8b0c8c6c463d96d611/cmake_macos_fw_test.zip)):
* Homebrew toolchain/dependencies CMake 3.9.2 (and 3.8.2), Ninja 1.7.2, Qt 5.9.1
* On macOS 10.11.6, with Xcode 8.2.1
* Building a library as a macOS framework, e.g. `my_lib.framework`, with a target name of `my_lib`
* Building test executables, using AUTOMOC, that link to the framework, adding its dependency as `my_lib`
Under CMake 3.8.2, no issues with `_autogen` targets and Ninja.
Under CMake 3.9.2, errors with the following during generation:
```
ninja: error: 'output/lib/my_lib.framework/my_lib', needed by 'test/CMakeFiles/mylibtest_autogen', missing and no known rule to make it
```
I can work around the issue by adding the framework dependency using the `$<TARGET_FILE:my_lib>` generator expression instead, which appears to overcome the now-missing rule for the `my_lib.framework/<my_lib symlink>` byproduct of the framework build, but this seems unnecessary.
Another (quite clumsy) workaround is to add the `my_lib.framework/<my_lib symlink>` byproduct to the framework's target using something like this:
```cmake
if(CMAKE_GENERATOR MATCHES "Ninja" AND NOT "${CMAKE_VERSION}" VERSION_LESS "3.2")
# generate phony target for <binary output>/my_lib*.framework/<my_lib* symlink>
# (referenced by automoc _autogen targets)
add_custom_command(TARGET my_lib
PRE_LINK
COMMAND echo ""
BYPRODUCTS "output/lib/my_lib.framework/my_lib"
)
endif()
```
Seems to me this is a regression in 3.9.x (over 3.8.x), but I am unsure if it is with the framework's build generation (missing rule for the `my_lib.framework/<my_lib symlink>`) or in the new AUTOMOC changes, where the `my_lib` framework target is treated as if it was an IMPORT LOCATION (base symlink), instead of its versioned framework path.3.10.1Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17589CMake 3.10 introduces Qt-related configure error on OS X 10.13 for Paraview-d...2018-01-11T10:30:00-05:00T.J. CoronaCMake 3.10 introduces Qt-related configure error on OS X 10.13 for Paraview-derived appMoving from CMake 3.9 to 3.10, the configure phase of [CMB](https://gitlab.kitware.com/cmb/cmb)'s build results in several errors of the following type:
```
CMake Error in Source/Applications/MeshViewer/CMakeLists.txt:
Cannot find sourc...Moving from CMake 3.9 to 3.10, the configure phase of [CMB](https://gitlab.kitware.com/cmb/cmb)'s build results in several errors of the following type:
```
CMake Error in Source/Applications/MeshViewer/CMakeLists.txt:
Cannot find source file:
/Resources/qt_menu.nib/classes.nib
```3.10.2Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17573Changed behaviour of get_property( ... SOURCE ...) in CMake 3.10 breaks my code.2018-01-11T10:30:00-05:00KnitschiChanged behaviour of get_property( ... SOURCE ...) in CMake 3.10 breaks my code.Hi,
I have a custom target that copies .dll files of depended on shared library targets to my executable in the build-tree when using Visual Studio, so I can run the executables with F5. The custom target has the .dll file as `OUTPUT`.
...Hi,
I have a custom target that copies .dll files of depended on shared library targets to my executable in the build-tree when using Visual Studio, so I can run the executables with F5. The custom target has the .dll file as `OUTPUT`.
In the case that multiple executables share the same build-tree directory, I can only create one copy-target. Otherwise I will get the cmake error that there already is a rule for the copied dll-file. In order to not add another copy-target for the second executable, I used to call `get_property( isGenerated SOURCE ${copied_dll_file} PROPERTY GENERATED)` to see if another target is already deploying that required dll-file.
After the update to CMake 3.10 this call of `get_property()` yields the error
````
CMake Error in libStlUtilities/CMakeLists.txt:
Cannot find source file:
C:/CppLibraries/BuildCppCodeBaseAssistant/Generated/VS2015/BuildStage/Debug/libStlUtilities/libStlUtilities-debug.dll
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
````
So am I missusing `get_property(SOURCE)` or should it be considered a bad CMake behavior?
If the problem is on my side, how can I check if there is already a rule for generating a certain file?
Cheers Knitschi3.10.2Sebastian HoltermannSebastian Holtermann