CMake issues
https://gitlab.kitware.com/cmake/cmake/-/issues
2021-09-13T11:56:06-04:00
https://gitlab.kitware.com/cmake/cmake/-/issues/22604
TIFF::CXX is assumed to be built into libtiff when MSVC is used
2021-09-13T11:56:06-04:00
ABDUL
TIFF::CXX is assumed to be built into libtiff when MSVC is used
In FindTIFF.cmake, TIFF::CXX, under MSVC, is assumed to be built into the main tiff library, libtiff, but in reality, it is not built there.
We made the module work by removing that logic.
The original merge is https://gitlab.kitware....
In FindTIFF.cmake, TIFF::CXX, under MSVC, is assumed to be built into the main tiff library, libtiff, but in reality, it is not built there.
We made the module work by removing that logic.
The original merge is https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4934
The original discussion is https://discourse.cmake.org/t/tiff-cxx-is-assumed-to-be-built-into-libtiff-when-msvc-is-used/3946
Error log:
```
[build] Microsoft (R) Incremental Linker Version 14.29.30040.0
[build] Copyright (C) Microsoft Corporation. All rights reserved.
[build]
[build] main.cpp.obj : error LNK2019: unresolved external symbol "struct tiff * __cdecl TIFFStreamOpen(char const *,class std::basic_ostream<char,struct std::char_traits<char> > *)" (?TIFFStreamOpen@@YAPEAUtiff@@PEBDPEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@@Z) referenced in function main
[build] main.exe : fatal error LNK1120: 1 unresolved externals
[build] ninja: build stopped: subcommand failed.
```
[CMakeLists.txt](/uploads/f15dbce7203148e035e2585a9fd996fd/CMakeLists.txt)
[main.cpp](/uploads/689ad9283b1f48da7e76920aba5e1491/main.cpp)
Cheers
https://gitlab.kitware.com/cmake/cmake/-/issues/22605
cmake + xcode data race: cmake.check_cache
2022-12-29T10:22:44-05:00
Evgeniy Dushistov
cmake + xcode data race: cmake.check_cache
I use 3.21.2 and XCode 12.4.
Steps to reproduce:
1. Create XCode project with `cmake -GXcode`
2. Open project with XCode and build it
3. Change something in project to cause `.xcodeproj` regeneration (for example edit CMakeLists.txt)
...
I use 3.21.2 and XCode 12.4.
Steps to reproduce:
1. Create XCode project with `cmake -GXcode`
2. Open project with XCode and build it
3. Change something in project to cause `.xcodeproj` regeneration (for example edit CMakeLists.txt)
and run build in XCode,
it run ZERO_CHECK target detects project change and build was cancelled
Sometimes on step (3) cycle happens, because of XCode detects project change before
`cmake` finish its job and so `path/to/build/dir/CMakeFiles/cmake.check_cache` was deleted, but not recreated,
so when XCode indicated that build is "Cancelled" and I re-run build in XCode,
it again re-run `cmake` via ZERO_CHECK, and again build cancelled before `cmake.check_cache` was
created and so on.
I am able to reproduce this problem in 1/4-1/3 cases when I rebuild project with CMakeFiles.txt changes.
So it would be nice at the end of `cmake`'s job, when it prints:
```
Configuring done
Generating done
```
if `cmake` write `cmake.check_cache` and sync it to disk before "Generating done".
I will try to create small example to reproduce problem.
https://gitlab.kitware.com/cmake/cmake/-/issues/22606
cmake 3.21.2 set(CMAKE_CXX_STANDARD 20) incorrectly sets -std:c++20 for msvc.
2021-09-11T08:42:57-04:00
Robert Russell
cmake 3.21.2 set(CMAKE_CXX_STANDARD 20) incorrectly sets -std:c++20 for msvc.
cmake version 3.21.2
`set(CMAKE_CXX_STANDARD 20)`
sets `-std:c++20`
The issue is on my CI it has a newer version of cmake and an older version of msvc. On my pc I have older versions of both.
Maybe related: https://gitlab.kitware.com...
cmake version 3.21.2
`set(CMAKE_CXX_STANDARD 20)`
sets `-std:c++20`
The issue is on my CI it has a newer version of cmake and an older version of msvc. On my pc I have older versions of both.
Maybe related: https://gitlab.kitware.com/cmake/cmake/-/issues/18837
https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-160
> In versions of Visual Studio 2019 before version 16.11, /std:c++latest is required to enable all the compiler and standard library features of C++20.
Maybe the current the version on my ci doesn't support `-std` maybe it needs `/std`
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warnings-by-compiler-version?view=msvc-160
Version of the MSVC compiler version 19.29.30133 which I guess is Visual Studio 2019 16.11.
Hmm the error message doesn't match the documentation on Microsoft's site...
> The contents of <ranges> are available only in c++latest mode with concepts support;
> see https://github.com/microsoft/STL/issues/1814 for details.
failed build log.
[log__1_.txt](/uploads/1b4f5d2105a332004d49a8dc12f60c87/log__1_.txt)
https://gitlab.kitware.com/cmake/cmake/-/issues/22607
ccmake cuts off the end of log output
2023-03-14T06:44:53-04:00
Craig Scott
ccmake cuts off the end of log output
While running ccmake on a project with a lot of output (a top level Qt6 build in my case), I'm noticing lately that the end of that output is sometimes truncated. I may be losing up to 20 lines or so, maybe less. It is possible that the ...
While running ccmake on a project with a lot of output (a top level Qt6 build in my case), I'm noticing lately that the end of that output is sometimes truncated. I may be losing up to 20 lines or so, maybe less. It is possible that the truncation only occurs when the configuration step succeeds but the generation step encounters an error. Perhaps there's a missed buffer flush before exit or something?
I'm on Linux using CMake 3.21.2
https://gitlab.kitware.com/cmake/cmake/-/issues/22608
CMAKE_SIZEOF_VOID_P automatic guess at Modules/CMakeFindPackageMode.cmake doe...
2021-09-14T09:34:00-04:00
Pablo Romero
CMAKE_SIZEOF_VOID_P automatic guess at Modules/CMakeFindPackageMode.cmake does not work when cross-compiling
CMAKE_SIZEOF_VOID_P automatic guess at Modules/CMakeFindPackageMode.cmake does not work when cross-compiling, because the path CMAKE_SYSROOT on host OS must be passed before checking for the existence of `/usr/lib64` with the full path o...
CMAKE_SIZEOF_VOID_P automatic guess at Modules/CMakeFindPackageMode.cmake does not work when cross-compiling, because the path CMAKE_SYSROOT on host OS must be passed before checking for the existence of `/usr/lib64` with the full path on host OS.
https://gitlab.kitware.com/cmake/cmake/-/issues/22609
Compile error on old clang versions
2021-09-25T14:37:09-04:00
degaart
Compile error on old clang versions
While compiling on `Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)`, bootstrapping stops on the following error:
```
clang++ -std=gnu++11 -DCMAKE_BOOTSTRAP -I/Users/cmake/Downloads/cmake-3.21.2/Bootstrap.cmk ...
While compiling on `Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)`, bootstrapping stops on the following error:
```
clang++ -std=gnu++11 -DCMAKE_BOOTSTRAP -I/Users/cmake/Downloads/cmake-3.21.2/Bootstrap.cmk -I/Users/cmake/Downloads/cmake-3.21.2/Source -I/Users/cmake/Downloads/cmake-3.21.2/Source/LexerParser -I/Users/cmake/Downloads/cmake-3.21.2/Utilities/std -I/Users/cmake/Downloads/cmake-3.21.2/Utilities -c /Users/cmake/Downloads/cmake-3.21.2/Source/cmInstallScriptGenerator.cxx -o cmInstallScriptGenerator.o
/Users/cmake/Downloads/cmake-3.21.2/Source/cmInstallRuntimeDependencySet.cxx:60:41: error: chosen constructor is explicit in copy-initialization
auto it = targetDepends.insert({ tgt, {} });
^~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/set:428:14: note: constructor declared here
explicit set(const value_compare& __comp = value_compare())
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:262:37: note: passing argument to parameter '__y' here
pair(const _T1& __x, const _T2& __y)
^
1 error generated.
```
The fix, in my case was to change `auto it = targetDepends.insert({ tgt, {} });` to `auto it = targetDepends.insert({ tgt, std::set<const cmGeneratorTarget*>() });`
https://gitlab.kitware.com/cmake/cmake/-/issues/22610
Cannot build ZSTD using CMAKE + NINJA on Windows
2024-02-14T09:18:58-05:00
Cartes
Cannot build ZSTD using CMAKE + NINJA on Windows
Cannot build ZSTD using `ninja` + `cmake` (versions below) on Windows.
```
cmake ..\build\cmake\ -G Ninja
...
-- Performing Test C_FLAG_WCAST_ALIGN
-- Performing Test C_FLAG_WCAST_ALIGN - Success
-- Performing Test CXX_FLAG_WCAST_ALIGN...
Cannot build ZSTD using `ninja` + `cmake` (versions below) on Windows.
```
cmake ..\build\cmake\ -G Ninja
...
-- Performing Test C_FLAG_WCAST_ALIGN
-- Performing Test C_FLAG_WCAST_ALIGN - Success
-- Performing Test CXX_FLAG_WCAST_ALIGN
-- Performing Test CXX_FLAG_WCAST_ALIGN - Success
-- Performing Test C_FLAG_WCAST_QUAL
-- Performing Test C_FLAG_WCAST_QUAL - Success
-- Performing Test CXX_FLAG_WCAST_QUAL
-- Performing Test CXX_FLAG_WCAST_QUAL - Success
-- Performing Test C_FLAG_WSTRICT_PROTOTYPES
-- Performing Test C_FLAG_WSTRICT_PROTOTYPES - Success
-- Performing Test C_FLAG_DDEBUGLEVEL_1
-- Performing Test C_FLAG_DDEBUGLEVEL_1 - Success
-- Performing Test CXX_FLAG_DDEBUGLEVEL_1
-- Performing Test CXX_FLAG_DDEBUGLEVEL_1 - Success
-- CMAKE_INSTALL_PREFIX: C:/Program Files (x86)/zstd
-- CMAKE_INSTALL_LIBDIR: lib
-- ZSTD_LEGACY_SUPPORT not defined!
-- ZSTD_MULTITHREAD_SUPPORT is enabled
-- Configuring done
-- Generating done
CMake Error:
Running
'C:/Users/james/scoop/shims/ninja.exe' '-C' 'C:/Users/james/src/alteryx-bootstrapper/third_party/zstd/b' '-t' 'recompact'
failed with:
ninja: error: build.ninja:767: multiple rules generate lib/zstd.lib [-w dupbuild=err]
```
Trying `-w dupbuild=warn` leads to errors as well.
**Versions**
- cmake version 3.21.2
- ninja 1.10.2
- zstd commit a488ba114ec17ea1054b9057c26a046fc122b3b6 (HEAD, tag: v1.5.0, origin/release)
https://gitlab.kitware.com/cmake/cmake/-/issues/22611
Clang: *.manifest files listed as sources are ignored by GNU-like front-end o...
2022-01-31T13:03:18-05:00
Nick Hutchinson
Clang: *.manifest files listed as sources are ignored by GNU-like front-end on Windows
When building with clang (not clang-cl) on Windows, *.manifest files listed as sources for an executable or dll target are not embedded into the executable or dll.
Ideally, CMake would add something like the following to the link line:
...
When building with clang (not clang-cl) on Windows, *.manifest files listed as sources for an executable or dll target are not embedded into the executable or dll.
Ideally, CMake would add something like the following to the link line:
-Xlinker /MANIFEST:EMBED -Xlinker /MANIFESTINPUT:manifest1.manifest -Xlinker /MANIFESTINPUT:manifest2.manifest ...
## To reproduce
Compare the link lines generated by the following project with CMAKE_CXX_COMPILER=clang-cl.exe vs CMAKE_CXX_COMPILER=clang++.exe. (I'm assuming a Ninja generator.)
With clang-cl, the manifest file is respected -- the link is performed via `cmake.exe -E vs_link_exe`, which appears to embed the manifests via mt.exe. With clang++, the manifest file is ignored.
**CMakeLists.txt**
```cmake
cmake_minimum_required(VERSION 3.21)
project(TestProj CXX)
add_executable(my_exe my_exe.cpp compatibility.manifest)
```
**my_exe.cpp**
```cpp
int main() { return 0; }
```
**compatibility.manifest**
```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</assembly>
```
Tested with CMake 3.21.2, LLVM 11.0.0, MSVC 19.29, Ninja 1.10.2
## Workaround
Add the linker args manually:
```cmake
if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND MSVC_VERSION AND NOT MSVC)
target_link_options(my_exe PRIVATE
"LINKER:/MANIFEST:EMBED"
"LINKER:/MANIFESTINPUT:${CMAKE_CURRENT_SOURCE_DIR}/compatibility.manifest"
)
endif ()
```
https://gitlab.kitware.com/cmake/cmake/-/issues/22612
"--config" not recognized (quoting issue)
2021-09-07T17:02:13-04:00
Kevin André
"--config" not recognized (quoting issue)
I have a Windows batch script containing this:
```
SET CMAKE_BIN_DIR=%programfiles%\CMake\bin
"%CMAKE_BIN_DIR%"\cmake.exe --build . --config Release
```
And this mysteriously fails with the error "CMake Error: Unknown argument --config...
I have a Windows batch script containing this:
```
SET CMAKE_BIN_DIR=%programfiles%\CMake\bin
"%CMAKE_BIN_DIR%"\cmake.exe --build . --config Release
```
And this mysteriously fails with the error "CMake Error: Unknown argument --config". When I type the same line into the command prompt with the variables expanded, it actually works as it should.
While trying to get a minimal testcase, I discovered that the error can also be triggered in the command prompt directly. It turns out that the position of the second quote character is significant:
![image](/uploads/334d684b52913d7aba081b9703b28660/image.png)
So this works:
```
"C:\Program Files\CMake\bin\cmake.exe" --build . --config Release
```
...but this does not:
```
"C:\Program Files"\CMake\bin\cmake.exe --build . --config Release
```
After that discovery I was able to fix my batch script by moving everything inside the quotes. The following works correctly:
```
SET CMAKE_BIN_DIR=%programfiles%\CMake\bin
"%CMAKE_BIN_DIR%\cmake.exe" --build . --config Release
```
But I am wondering if this could be a bug in how CMake processes command-line arguments.
Especially because my batch script also has another CMake line for doing the configure/generate step in the build process, and that line always worked perfectly, even with the second quote in the 'wrong'(?) place.
https://gitlab.kitware.com/cmake/cmake/-/issues/22613
ccmake OSX BigSur: dyld: Symbol not found: _iconv
2021-09-12T07:16:04-04:00
David Duke
ccmake OSX BigSur: dyld: Symbol not found: _iconv
I recently did some updates on my osx machine to 11.5.2 Band thereafter ccmake stopped working
with
dyld: Symbol not found: _iconv
Referenced from: /usr/lib/libarchive.2.dylib
Expected in: /usr/local/lib/libiconv.2.dylib
I tried rei...
I recently did some updates on my osx machine to 11.5.2 Band thereafter ccmake stopped working
with
dyld: Symbol not found: _iconv
Referenced from: /usr/lib/libarchive.2.dylib
Expected in: /usr/local/lib/libiconv.2.dylib
I tried reinstalling CMake using the dmg however that didn't work. Nor did macports help
I've also tried rebuilding source fro a fresh git clone
that is sstill having the same problem.
I know from othersystems that libiconv on OSX is a source of potential issues
as there are different versions. Maybe the psaths need repairing
unless someone has a better solution?
https://gitlab.kitware.com/cmake/cmake/-/issues/22614
install() does not allow passing full component string as variable
2021-09-09T10:03:50-04:00
Johan Seland
install() does not allow passing full component string as variable
I am developing some CMake functions where I optionally might pass the installation component as an argument to a CMake function.
Ideally, I would like to pass both the COMPONENT keyword and component name in a variable. This allows me ...
I am developing some CMake functions where I optionally might pass the installation component as an argument to a CMake function.
Ideally, I would like to pass both the COMPONENT keyword and component name in a variable. This allows me to use an empty string when I do not have a component. The following minimal example reproduces the issue.
```
cmake_minimum_required(VERSION 3.18)
project(installDirectoryWithVariableComponent)
set(_comp "COMPONENT sdk")
install(
DIRECTORY ${CMAKE_SOURCE_DIR}
DESTINATION ${CMAKE_BINARY_DIR}
#COMPONENT sdk # Uncomment to make configuration succeed
${_comp} # Comment to make configuration succeed
)
```
This yields the following error message:
```
c:\projects\CMakeInstallBug\build>cmake -GNinja ..
CMake Error at CMakeLists.txt:6 (install):
install DIRECTORY given unknown argument "COMPONENT sdk".
-- Configuring incomplete, errors occurred!
See also "C:/projects/CMakeInstallBug/build/CMakeFiles/CMakeOutput.log".
```
Since install() is implemented as a C++ function, I am assuming the argument isn't being split correctly in cmInstallCommand.cxx.
https://gitlab.kitware.com/cmake/cmake/-/issues/22615
iOS: Xcode: cmake --build . should automatically add -allowProvisioningUpdate...
2021-09-10T03:14:05-04:00
alcroito
iOS: Xcode: cmake --build . should automatically add -allowProvisioningUpdates option when the Xcode version supports it
With a free / personal Apple team account, trying to build a new iOS project (device, not simulator), with a new bundle id that was never used before, from the command line can fail because there is no available provisioning profile.
``...
With a free / personal Apple team account, trying to build a new iOS project (device, not simulator), with a new bundle id that was never used before, from the command line can fail because there is no available provisioning profile.
```cmake
cmake_minimum_required(VERSION 3.14)
set(CMAKE_OSX_ARCHITECTURES "arm64" CACHE STRING "")
set(CMAKE_OSX_SYSROOT iphoneos)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer")
set(CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM "xyz") <--------------- replace with your own Apple team id
set(CMAKE_OSX_DEPLOYMENT_TARGET "10" CACHE STRING "")
project(ios_app LANGUAGES CXX)
if(APPLE)
set(MACOSX_BUNDLE_GUI_IDENTIFIER "com.alroito.cmake-testapp-provision-v2")
set(MACOSX_BUNDLE_SHORT_VERSION_STRING "0.1")
set(MACOSX_BUNDLE_LONG_VERSION_STRING "0.1")
set(MACOSX_BUNDLE_BUNDLE_VERSION "0.1")
endif()
set(main_cpp "${CMAKE_CURRENT_BINARY_DIR}/main.cpp")
file(GENERATE OUTPUT "${main_cpp}" CONTENT "int main() { return 0; }")
add_executable(app "${main_cpp}")
```
```
$ cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS
-- The CXX compiler identification is AppleClang 12.0.0.12000032
....
-- Configuring done
-- Generating done
-- Build files have been written to: /Volumes/T3/Dev/projects/cmake/ios/minimal_ios_auto_provisioning/build
$ cmake --build .
....
error: No profiles for 'com.alroito.cmake-testapp-provision-v2' were found: Xcode couldn't find any iOS App Development provisioning profiles matching 'com.alroito.cmake-testapp-provision-v2'. Automatic signing is disabled and unable to generate a profile. To enable automatic signing, pass -allowProvisioningUpdates to xcodebuild. (in target 'app' from project 'ios_app')
** BUILD FAILED **
```
Following the advice of adding `-allowProvisioningUpdates`
```
$ cmake --build . -- -allowProvisioningUpdates
....
CodeSign /Volumes/T3/Dev/projects/cmake/ios/minimal_ios_auto_provisioning/build/Debug-iphoneos/app.app (in target 'app' from project 'ios_app')
Signing Identity: "Apple Development: xxxxx yyyyyy"
Provisioning Profile: "iOS Team Provisioning Profile: com.alroito.cmake-testapp-provision-v2"
(zzzzzzzzzzzzzzzzzzzzzzzzz)
...
** BUILD SUCCEEDED **
```
It would be nice if `cmake --build .` would automatically add that option if the Xcode version supports it. Perhaps it can be controlled by a new policy or global option?
The Xcode version that introduced the option is >=9.
Relevant qmake change
https://codereview.qt-project.org/c/qt/qtbase/+/370000/2/mkspecs/features/uikit/xcodebuild.mk
https://gitlab.kitware.com/cmake/cmake/-/issues/22616
install() DESTINATION is inconvenient and inconsistent
2021-11-18T09:55:41-05:00
ratijas
install() DESTINATION is inconvenient and inconsistent
### Inconsistent
The `install()` function handles its `DESTINATION` argument inconsistently:
- Not specifying it at all leads to a CMakeLists.txt processing error:
```txt
CMake Error at myproject/CMakeLists.txt:30 (install):
install...
### Inconsistent
The `install()` function handles its `DESTINATION` argument inconsistently:
- Not specifying it at all leads to a CMakeLists.txt processing error:
```txt
CMake Error at myproject/CMakeLists.txt:30 (install):
install DIRECTORY given no DESTINATION!
-- Configuring incomplete, errors occurred!
See also "/home/ratijas/projects/mycompany/myworkspace/build/Debug/CMakeFiles/CMakeOutput.log".
```
- Specifying an empty destination (something I tried to avoid dummy dot ".") fails at `cmake --install` time with different error:
```txt
-- Install configuration: "Debug"
CMake Error at build/Debug/models/cmake_install.cmake:46 (file):
file INSTALL given no DESTINATION
Call Stack (most recent call first):
build/Debug/cmake_install.cmake:52 (include)
```
### Inconvenient
Since it is not possible to specify neither an empty destination, nor omitting it at all, users are forces to write something like `install(mytarget DESTINATION .)` to install their target straight to `CMAKE_INSTALL_PREFIX` directory. But other `install()` invocations with actual directories like `install(myqmlmodule DESTINATION qml)` don't need leading dot, which makes it look weird and mis-aligned in terminal, like this:
```txt
-- Install configuration: "Debug"
-- Up-to-date: /myworkspace/deploy/Debug/./qml
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware/Models
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware/Models/qmldir
-- Up-to-date: /myworkspace/deploy/Debug/qml/MyCompany/Hardware/Models/libmodels.so
-- Up-to-date: /myworkspace/deploy/Debug/./qml
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware/Drivers
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware/Drivers/RS485
-- Up-to-date: /myworkspace/deploy/Debug/./qml/MyCompany/Hardware/Drivers/RS485/qmldir
-- Up-to-date: /myworkspace/deploy/Debug/qml/MyCompany/Hardware/Drivers/RS485/librs485qt.so
-- Up-to-date: /myworkspace/deploy/Debug/./app
-- Install configuration: "Debug"
-- Up-to-date: /myworkspace/deploy/Debug/./demo
-- Up-to-date: /myworkspace/deploy/Debug/./storybook
```
This dot just doesn't make sense.
https://gitlab.kitware.com/cmake/cmake/-/issues/22617
CTest: Hardcoded value of CDash File submission Time Limit
2023-11-20T22:32:08-05:00
anujchoudhury
CTest: Hardcoded value of CDash File submission Time Limit
It would be very helpful to make the submission timeout configurable when submitting coverage results. It is currently hardcoded to 120 seconds. This would especially be helpful in submitting large coverage files to the cdash server. Thi...
It would be very helpful to make the submission timeout configurable when submitting coverage results. It is currently hardcoded to 120 seconds. This would especially be helpful in submitting large coverage files to the cdash server. This is the error seen when large files are attempted to be submitted:
```
Error when uploading file: <code coverage xml file name>
Error message was: Operation too slow. Less than 1 bytes/sec transferred the last 120 seconds
Problem when submitting via HTTP
```
https://gitlab.kitware.com/cmake/cmake/-/issues/22618
FindPython3: Problem with result variables
2021-09-10T12:17:24-04:00
José-Marcio Martins da Cruz
FindPython3: Problem with result variables
I have a problem with FindPython3. It can be explained by the following code :
~~~
cmake_minimum_required(VERSION 3.16)
project(WhereIsPython NONE)
#SET(Python3_ROOT /home/anaconda3)
SET(Python3_ROOT_DIR /home/anaconda3/envs/smil)...
I have a problem with FindPython3. It can be explained by the following code :
~~~
cmake_minimum_required(VERSION 3.16)
project(WhereIsPython NONE)
#SET(Python3_ROOT /home/anaconda3)
SET(Python3_ROOT_DIR /home/anaconda3/envs/smil)
find_package(Python3 COMPONENTS Interpreter Development NumPy)
MESSAGE(STATUS "CMAKE_VERSION : " ${CMAKE_VERSION})
MESSAGE(STATUS "FOUND : " ${Python3_FOUND})
MESSAGE(STATUS "ID : " ${Python3_INTERPRETER_ID})
MESSAGE(STATUS "EXECUTABLE : " ${Python3_EXECUTABLE})
MESSAGE(STATUS "INCLUDE : " ${_Python3_INCLUDE_DIR})
MESSAGE(STATUS "LIBRARIES : " ${Python3_LIBRARIES})
MESSAGE(STATUS "NUMPY : " ${_Python3_NumPy_INCLUDE_DIR})
~~~
The main problem I have is that some variables can be accessed only if they're prefixed by an underscore while in the documentation no mention is made to underscore prefixed variables. For example, in the above code, the two `INCLUDE` variables.
The problem is the same if I set or not the `Python3_ROOT_DIR` hint variable.
Maybe this is related to issue #22084
Also, setting the CMAKE variable `Python3_ROOT_DIR` work as a hint, but not `Python3_ROOT` (as indicated in the find_package page).
https://gitlab.kitware.com/cmake/cmake/-/issues/22619
API for dependency providers (find_package() and FetchContent)
2022-05-25T07:24:51-04:00
Craig Scott
API for dependency providers (find_package() and FetchContent)
This is the previously mentioned complement to #21687. Apologies for the length, there's a number of things that come together in this proposal, so I wanted to be clear on different aspects to address discussion points I've already had w...
This is the previously mentioned complement to #21687. Apologies for the length, there's a number of things that come together in this proposal, so I wanted to be clear on different aspects to address discussion points I've already had with various people and stakeholders around this. I don't expect the actual implementation to be all that complex.
## Context
The `find_package()` and `FetchContent_MakeAvailable()` commands are two primary ways that projects bring dependencies into their build. The former generally expects the packages to be pre-built and provided externally, while the latter typically builds the dependencies as part of the project.
A significant proportion of CMake users would like to make use of package managers to provide these dependencies. Different package managers choose different strategies for how to provide this (some provide multiple methods), each with their own advantages and disadvantages. Very few support both `find_package()` and `FetchContent_MakeAvailable()` equally well, most tend to support only the former. Some require modifying the project to call specific commands or load certain files to set up the project for the package manager, others require the user to use a toolchain file that the package manager provides. It has been common for package managers to redefine `find_package()` to do their own logic first before potentially forwarding through to the built-in implementation, even though this has never been officially supported and relies on undocumented behavior. Methods continue to evolve.
A project should not have to hard-code a choice of dependency provider. If they do, they lock themselves out of being used with other projects that might choose a different provider, or people with constraints on providers may be prevented from using an otherwise suitable project. Users should be able to switch between dependency providers, as long as each provider does in fact provide the dependencies they need. In addition, projects might need a mix of dependency providers to satisfy internal constraints. This would be more common in organisations where some dependencies might be internal and have tight access restrictions (e.g. IP protection, legacy systems, export controls, and so on). They may have some things that need custom, in-house logic to provide them, but others can be provided by commercial off-the-shelf applications. For these scenarios, the ability to get some packages via one mechanism or provider and other packages from another could be a very important need.
An often missed or under-appreciated point is that it is quite common for projects to provide controls for turning on or off different parts of the build. This could be turning on/off things like tests, building examples, enabling or disabling specific features, selecting between different implementations of a particular interface, and so on. These can all impact the set of dependencies that are needed. The project will request that a dependency be provided only after determining that it is needed. This avoids having to pull down potentially many and/or huge dependencies that ultimately wouldn't be needed. For CI systems that frequently build from scratch, this could be a critical pain point.
## Proposed New Capabilities
### Dependency Request Interception
CMake lacks a well-defined, supported way for dependency providers to intercept calls to `find_package()` and `FetchContent_MakeAvailable()`. Both commands could relatively easily support an approach of "try satisfying this request using some list of providers, and if none provide it, continue on with the usual logic to provide it ourselves". Projects would need no changes, dependency providers would register themselves (see next item) and CMake would handle forwarding requests internally.
### Dedicated Provider Injection Point
Dependency providers need a way to register themselves with CMake, so that CMake knows where it can potentially forward on the dependency requests it receives from projects. This needs to happen early enough to support what some dependency providers may want to do, but not so early that some important things are not defined yet. Some providers want to control the toolchain details, potentially setting or overriding the `CMAKE_TOOLCHAIN_FILE`, which means they need a point before the first `project()` call starts doing things. Some may need to access the source or build directories, so things like `CMAKE_SOURCE_DIR` and `CMAKE_BINARY_DIR` need to be available. The value of existing cache variables should also be available.
The logical place for an injection point therefore seems to be the very first `project()` call. We currently have `CMAKE_PROJECT_INCLUDE_BEFORE` and `CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE`, but those are meant for users to implement arbitrary custom steps and we shouldn't take over those variables. The former also gets used for every `project()` call, not just the first. The second would require users to know the name of the top level project, which would be an annoyance as they move between projects and want to apply the same setup steps to each one. Instead of trying to (ab)use one of those existing variables, I propose we add a dedicated injection point which is the first thing a `project()` command does before pulling in any other file (a custom user include, toolchain, etc.).
## Proposed API Changes
**NOTE: See updated proposal in https://gitlab.kitware.com/cmake/cmake/-/issues/22619#note_1184153 which has some changes from the original description here.**
- Add a new variable accepting a list of files to be included by the first `project()` command. As a working name for discussion, I'll propose `CMAKE_PROJECT_SETUP` (also see _Observations_ section for context). We could also support an environment variable of the same name which is used if there is no CMake variable of that name defined (i.e. similar to how `CMAKE_TOOLCHAIN_FILE` works).
- Add a new `cmake_language()` subcommand for registering event handlers (see #22466 for a dedicated issue around this). In this proposal, we would be defining event types for dependency providers. For discussion, I propose the syntax `cmake_language(EVENT <type> <command-name>)`. Allowed values for `<type>` would be `FIND_PACKAGE` and `FETCHCONTENT_MAKEAVAILABLE`, with flexibility to add new types in the future if needed (examples of which are discussed in #22466). The `<command-name>` would be called with context-specific arguments for the associated event type (see below). I propose that we do NOT provide a public API for deregistering an event handler, querying the set of registered handlers or other handler-related manipulation in the initial implementation, to contain scope.
- Add a new command to `FetchContent` for retrieving the "winning" declared dependency details for a given dependency (there is already an internal command which does most of what is required). This allows a provider to retrieve the declared details when given only a dependency name by `FetchContent_MakeAvailable()`. Note that these details should omit any `OVERRIDE_FIND_PACKAGE` or `FIND_PACKAGE_ARGS` (both added in !5688 for #21687), since those relate to call re-routing that CMake itself manages (the providers will be given an opportunity to provide the dependency before that re-routing).
The command for a `FIND_PACKAGE` provider would receive the exact same arguments as was passed to the `find_package()` call. In order to communicate whether it found the requested dependency, we could require that it sets `${CMAKE_FIND_PACKAGE_NAME}_FOUND` to false if it does NOT provide it. This would be pretty close to how config packages already work and may ultimately be easy for both providers and CMake. Alternatively, we could make the first argument be the name of an output variable they must set to indicate whether they provided the dependency or not. In the absence of any other opinions, I'd probably go with the former approach rather than the latter.
The command for a `FETCHCONTENT_MAKEAVAILABLE` provider would receive a name of an output variable followed by a list of dependency names to be satisfied. The command would need to set the output variable to the list of dependencies it did NOT provide. This has the advantage that for both provider types, the provider has to set something to say "I did not provide this", so it is more consistent. Note also that by giving the provider a list of dependencies rather than one at a time, the provider is free to work in parallel if it knows it is safe to do so. This has the potential to provide significantly faster dependency handling compared to `find_package()`, which only accepts one dependency at a time. Note that we would only provide a list of dependencies if the project itself did so. The order of the dependencies in the list might be important, depending on how the provider works. Some of the dependencies may themselves depend on others in the list, so the provider must honour the ordering if it would make a difference to how dependencies get populated/built, etc.
## Example
_my_dep_providers.cmake_:
```cmake
function(my_find_package_provider)
# ${ARGN} is expected to be the full set of arguments given to the `find_package()` call
# ... Does its thing and only sets ${CMAKE_FIND_PACKAGE_NAME}_FOUND to false if not provided
endfunction()
function(my_FetchContent_provider out_var)
# ${ARGN} would be a list of dependency names
# ... Does its thing, then sets out_var in parent scope to the dependencies it did not provide
endfunction()
cmake_language(EVENT FIND_PACKAGE my_find_package_provider)
cmake_language(EVENT FETCHCONTENT_MAKEAVAILABLE my_FetchContent_provider)
```
User might invoke CMake like this:
```
cmake -DCMAKE_PROJECT_SETUP=/path/to/my_dep_providers.cmake ...
```
## Observations
Nothing in this proposal changes existing behavior if no dependency providers are set. Users can continue to use whatever dependency managers they are currently without impact.
Package providers have both an opportunity to shape the configuration environment (at setup injection time) and to query the environment at the point where any dependency is requested. Thus, for those package providers that want to control the build, they can do so. For those providers who want to adapt what they provide to the environment as set up by the user, they can also do so. The above doesn't dictate the choice, the providers themselves are the ones that will place restrictions on the user, so the user is free to decide if they accept any such restrictions or find a different package provider that better suits their needs.
CMake's responsibility in this proposal would be to give the provider the "what", but not the "how". CMake also doesn't need to check what is provided, only whether the provider said it provided it or not. It is the provider's responsibility to provide a suitable dependency to the project. Note that for some providers, this might mean they ignore some or all of the information about the dependency (git repo, commit hash, `find_package()` components, etc.). Some providers maintain a coherent set of packages and the user might be selecting the package set as part of the setup stage. It is the user's responsibility to understand how the provider uses or does not use the information about the dependencies and ensure that is compatible with their project's needs. This is no different to what users already must do when using any of the established package managers at the moment.
The `CMAKE_PROJECT_SETUP` injection point may well be useful for other scenarios. While it is used for registering dependency providers in this proposal, it may also be a logical place to register other providers or perform one-time setup injected from outside the project. The existing `CMAKE_PROJECT_INCLUDE_BEFORE` and `CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE` variables don't quite achieve that because they either get used for every `project()` call or they require the name of the top level project and therefore hinder re-using setup scripts across projects.
Adding a provider for `FindPkgConfig` may also be something people might want to see at some point. I didn't want to tackle that in this first iteration, as it is already big and I personally feel there's more value in tackling the two that I've chosen to focus on here. The current proposal is extensible and should be able to accomodate such a direction in the future if required.
This proposal does not restrict efforts related to [CPS (Common Package Specification)](https://mwoehlke.github.io/cps/). Should CPS gain traction, it could be incorporated as another provider type, or we might choose to translate its information into one of the existing types. We have the flexibility needed to consider different approaches.
Craig Scott
Craig Scott
https://gitlab.kitware.com/cmake/cmake/-/issues/22620
target_compile_features fails to set langage version with clang
2021-09-13T03:33:04-04:00
adal dev
target_compile_features fails to set langage version with clang
Hello,
target_compile_features(${TARGET_NAME} PUBLIC cxx_std_11) does add -std=c++11 with gcc (5.5 on ubuntu 16) but not with clang11 (still on ubuntu 16)
other compiler not tested (msvc ?)
sample files to reproduce are joined.
Regard...
Hello,
target_compile_features(${TARGET_NAME} PUBLIC cxx_std_11) does add -std=c++11 with gcc (5.5 on ubuntu 16) but not with clang11 (still on ubuntu 16)
other compiler not tested (msvc ?)
sample files to reproduce are joined.
Regard
A.[CompileFeatureDemo.7z](/uploads/529dcb69a78d08c5403ea78e7aed6109/CompileFeatureDemo.7z)
https://gitlab.kitware.com/cmake/cmake/-/issues/22621
install: add EXPORT mode to generate pkg-config files
2022-03-07T11:07:14-05:00
Brad King
install: add EXPORT mode to generate pkg-config files
The pkg-config (`.pc`) format is one option for #20106, and may enable better integration with non-CMake build systems.
We may be able to generate pkg-config files for CMake packages by extending `install(EXPORT)` with a mode to generat...
The pkg-config (`.pc`) format is one option for #20106, and may enable better integration with non-CMake build systems.
We may be able to generate pkg-config files for CMake packages by extending `install(EXPORT)` with a mode to generate `.pc` files.
https://gitlab.kitware.com/cmake/cmake/-/issues/22622
XL Fortran flags halt on warning
2021-09-13T11:28:48-04:00
Miroslav Stoyanov
XL Fortran flags halt on warning
In `Modules/Compiler/XL-Fortran.cmake` line 17, the Fortran flags are too restrictive. Please, do not modify the default compiler behavior and remove the `-qhalt=e` flag, i.e., modify the line to:
```
string(APPEND CMAKE_Fortran_FLAGS_IN...
In `Modules/Compiler/XL-Fortran.cmake` line 17, the Fortran flags are too restrictive. Please, do not modify the default compiler behavior and remove the `-qhalt=e` flag, i.e., modify the line to:
```
string(APPEND CMAKE_Fortran_FLAGS_INIT " -qthreaded")
```
The XL compiler blurs the distinction between "warning" and "error" by having three different levels of "error", "severe error" and "unrecoverable error". Much of what falls into the "error" category is considered a "warning" by other compilers. XL appropriately defaults to `-qhalt=s` and halts only on severe errors. Modifying the default behavior is roughly equivalent to adding `-Werror` to the default flags for other compilers, e.g., gcc and clang.
The problem is particularly frustrating when using automated tools to generate Fortran wrappings for C or C++ code where it is not always possible to directly intrude in the code and fix the issue. Sometimes the compiler messages are cryptic and/or point to incorrect lines of code. Bad XL messages are not an issue with CMake, but CMake should not break the build over a warning or an error that XL deems frivolous. See the following issue on GitHub related to Swig-Fortran wrapping and how this is affecting multiple projects:
https://github.com/xsdk-project/xsdk-issues/issues/94
https://gitlab.kitware.com/cmake/cmake/-/issues/22623
InstallRequiredSystemLibraries MSVCP140.dll is missing
2021-09-13T11:30:13-04:00
Arjan
InstallRequiredSystemLibraries MSVCP140.dll is missing
Heey i'm creating an installer (NSIS) with cmake and cpack.
Within it i defined to include `InstallRequiredSystemLibraries`
It does it jobs and after the install i'm left with an executable and a bin folder in where the msvcp140.dll is l...
Heey i'm creating an installer (NSIS) with cmake and cpack.
Within it i defined to include `InstallRequiredSystemLibraries`
It does it jobs and after the install i'm left with an executable and a bin folder in where the msvcp140.dll is located.
However upon starting the exe (on a non-developer pc, AKA where no visual studio is installed) i'm getting a message telling me that MSVCP140.dll is missing.
If i copy over the bin folder to %SYSTEM32% the exe works again. If i copy the dll's to the level where the exe lives it works too
I'm clearly doing something wrong here, question is what?
bin folder:
![image](/uploads/a5c3bbf04eeb2c74c9546fe2e5b03133/image.png)
dependencywalker:
![image](/uploads/c80e9f38a4d84b14145d9abc2ed547e1/image.png)