CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-12-13T10:23:37-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25495presets: CMAKE_BINARY_DIR not resolved in script mode2023-12-13T10:23:37-05:00Martin Blanchardpresets: CMAKE_BINARY_DIR not resolved in script modeTrying to workaround the current limitation described at #24827, I was thinking of using the `--preset` option in `-P` script mode to dump CMake state, hoping script execution would happened after internal preset resolving. It seems to s...Trying to workaround the current limitation described at #24827, I was thinking of using the `--preset` option in `-P` script mode to dump CMake state, hoping script execution would happened after internal preset resolving. It seems to somehow work but not completely, eg. for `CMAKE_BINARY_DIR `...
Given the following `CMakePresets.json` file:
```json
{
"version": 4,
"configurePresets": [
{
"name": "chantal",
"binaryDir": "${sourceDir}/build"
}
]
}
```
And the following simple `CMakeDumpPreset.cmake` script:
```
message("CMAKE_SOURCE_DIR=${CMAKE_SOURCE_DIR}")
message("CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR}")
```
CMake 3.26.3 gives:
```
$ cmake --preset=chantal -P CMakeDumpPreset.cmake
CMAKE_SOURCE_DIR=~/src/regis
CMAKE_BINARY_DIR=~/src/regis
```
Where I would have expected:
```
CMAKE_SOURCE_DIR=~/src/regis
CMAKE_BINARY_DIR=~/src/regis/build
```https://gitlab.kitware.com/cmake/cmake/-/issues/25494lld-linker not creating stripped pdb with MSVC toolchain2023-12-13T10:39:38-05:00isudfvlld-linker not creating stripped pdb with MSVC toolchainsteps to reproduce:
1. build a simple shared lib
2. target_link_options with [/PDBSTRIPPED:pdbname.pdb](https://learn.microsoft.com/en-us/cpp/build/reference/pdbstripped-strip-private-symbols?view=msvc-170)
3. switch to lld-link by [-DC...steps to reproduce:
1. build a simple shared lib
2. target_link_options with [/PDBSTRIPPED:pdbname.pdb](https://learn.microsoft.com/en-us/cpp/build/reference/pdbstripped-strip-private-symbols?view=msvc-170)
3. switch to lld-link by [-DCMAKE_LINKER_TYPE=LLD](https://cmake.org/cmake/help/git-stage/variable/CMAKE_LINKER_TYPE.html#cmake-linker-type)
4. lld-linker not creating stripped pdb file while MSVC linker does
the cmakelist.txt i'm using:
```plaintext
cmake_minimum_required(VERSION 3.25)
set(CMAKE_CXX_STANDARD 23)
add_library(safeguard
SHARED
safeguard.h
safeguard.cpp
)
target_link_options(safeguard
PRIVATE
"/PDBSTRIPPED:safeguard/safeguard_p.pdb"
)
```
the linking command:
```plaintext
C:\Windows\system32\cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=safeguard\CMakeFiles\safeguard.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests -- C:\PROGRA~1\LLVM\bin\lld-link.exe safeguard\CMakeFiles\safeguard.dir\safeguard.cpp.obj /out:safeguard\safeguard.dll /implib:safeguard\safeguard.lib /pdb:safeguard\safeguard.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /PDBSTRIPPED:safeguard/safeguard_p.pdb kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && C:\Windows\system32\cmd.exe /C "cd /D C:\Users\isudfv\Desktop\tmp\cxxtst\cmake-build-debug\safeguard && "C:\Program Files\PowerShell\7\pwsh.exe" -noprofile -executionpolicy Bypass -file "C:/Program Files/Vcpkg/scripts/buildsystems/msbuild/applocal.ps1" -targetBinary C:/Users/isudfv/Desktop/tmp/cxxtst/cmake-build-debug/safeguard/safeguard.dll -installedDir "C:/Program Files/Vcpkg/installed/x64-windows/debug/bin" -OutVariable out""
```
I'm using latest LLVM and latest nightly cmakehttps://gitlab.kitware.com/cmake/cmake/-/issues/25492Rust language support2023-12-12T10:51:30-05:00Mads MarquartRust language supportIt would be nice if CMake had built-in support for compiling plain Rust files with `rustc`.
This includes support for:
- Rust-built libraries, even if they may be built as an opaque `rlib` (which in turn naturally would only be linkable...It would be nice if CMake had built-in support for compiling plain Rust files with `rustc`.
This includes support for:
- Rust-built libraries, even if they may be built as an opaque `rlib` (which in turn naturally would only be linkable by other Rust files).
- Cross-compilation (choosing the correct Rust target).
- Translation of common CMake variables to the equivalent `rustc` flags. Examples include `POSITION_INDEPENDENT_CODE -> -Crelocation-model=...`, `CMAKE_BUILD_TYPE -> -Copt-level=... -Cdebuginfo=...` and `CMAKE_SYSTEM_PROCESSOR -> -Ctarget-cpu=...`.
- Some sort of capability to easily add `cfg`s.
[Discussed previously on Discourse](https://discourse.cmake.org/t/enable-language-option-for-rust-cargo/8514), I'm opening this issue to have somewhere to track this. Note that this is distinct from [integration with Cargo](https://gitlab.kitware.com/cmake/cmake/-/issues/23783), which is being worked on in the [Corrosion](https://github.com/corrosion-rs/corrosion) project.
---
Example of a minimal project I'd expect to work, if this feature existed:
```rust
// foo.rs
pub fn foo() {
println!("foo");
}
```
```rust
// bar.rs
fn main() {
foo::foo();
}
```
```cmake
# CMakeLists.txt
cmake_minimum_required(VERSION X.Y)
project(Foobar Rust)
# Roughly: `rustc --crate-type=rlib foo.rs -o $(CMAKE_LIBRARY_PATH)/libfoo.rlib`
add_library(foo foo.rs)
# Roughly: `rustc -L $(CMAKE_LIBRARY_PATH) bar.rs`
add_executable(bar bar.rs)
# Roughly: add `--extern=foo`, such that you do not need `extern crate foo;`
target_link_libraries(bar foo)
```
(There are a few more such examples in the linked Discourse post).https://gitlab.kitware.com/cmake/cmake/-/issues/25489Reading SUBDIRECTORIES property recursively can lead to an endless recursion ...2023-12-11T16:46:18-05:00alcroitoReading SUBDIRECTORIES property recursively can lead to an endless recursion when building in a non-intuitive in-source buildThe sample project.
```
$ tree sample
sample
├── CMakeLists.txt
├── README.md
└── subdir
└── CMakeLists.txt
2 directories, 3 files
```
`$ cat sample/CMakeLists.txt`
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj)
fun...The sample project.
```
$ tree sample
sample
├── CMakeLists.txt
├── README.md
└── subdir
└── CMakeLists.txt
2 directories, 3 files
```
`$ cat sample/CMakeLists.txt`
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj)
function(print_subdir_tree input_src_dir)
set(dir "${input_src_dir}")
get_property(subdirs DIRECTORY "${dir}" PROPERTY SUBDIRECTORIES)
message(">> current dir: ${dir} \n >> subdirs ${subdirs}")
foreach(subdir IN LISTS subdirs)
message(">> Calling print_subdir_tree(${subdir})")
print_subdir_tree("${subdir}")
endforeach()
endfunction()
add_subdirectory(subdir)
print_subdir_tree("${CMAKE_CURRENT_SOURCE_DIR}")
```
`$ cat sample/subdir/CMakeLists.txt`
```
# it's empty
```
When configuring the project in the following strange way cmake errors out after hitting its recursion limit
```bash
cd sample/subdir
cmake -S .. -B .
```
```
>> current dir: /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories
>> subdirs /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> Calling print_subdir_tree(/Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir)
>> current dir: /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> subdirs /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> Calling print_subdir_tree(/Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir)
>> current dir: /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> subdirs /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> Calling print_subdir_tree(/Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir)
>> current dir: /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> subdirs /Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir
>> Calling print_subdir_tree(/Volumes/T3/Dev/projects/cmake/general/nested_subdirectories/subdir)
..... repeats 1000 times
CMake Error at CMakeLists.txt:5 (set):
Maximum recursion depth of 1000 exceeded
Call Stack (most recent call first):
CMakeLists.txt:11 (print_subdir_tree)
CMakeLists.txt:11 (print_subdir_tree)
CMakeLists.txt:11 (print_subdir_tree)
....
-- Configuring incomplete, errors occurred!
```
To emphasise, this only happens if i configure in the `subdir` source dir, against the parent `CMakeLists.txt`.
For some reason the `SUBDIRECTORIES` property of that source dir always contains itself.
I wasn't able to find any documentation on this behavior, but i suspect perhaps there's some mismatch in source vs binary dir, or the presence of the `CMakeCache.txt`
Full project: [nested_subdirectories.zip](/uploads/0484e402c4c07c7eaad96fff9cdf58e5/nested_subdirectories.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/25487XCODE_EMBED_FRAMEWORKS does not support imported framework or xcframework tar...2023-12-15T00:32:26-05:00Craig ScottXCODE_EMBED_FRAMEWORKS does not support imported framework or xcframework targetsWhen using the Xcode generator, the `XCODE_EMBED_FRAMEWORKS` accepts targets or paths. You can create an imported target for a shared framework, and starting with CMake 3.28, an imported shared library target should be able to represent ...When using the Xcode generator, the `XCODE_EMBED_FRAMEWORKS` accepts targets or paths. You can create an imported target for a shared framework, and starting with CMake 3.28, an imported shared library target should be able to represent a XCFramework. One can successfully create such an imported target (framework or xcframework), but it generates an error if you set `XCODE_EMBED_FRAMEWORKS` to it. Here's a rough sketch of the problem:
```cmake
# An XCFramework I've built in a separate project. For this problem, this could be
# either a .framework or a .xcframework.
set(XPLATXCF_LIBRARY /path/to/xplatxcf.xcframework)
# Imported target to represent the XCFramework (should be valid starting with CMake 3.28)
add_library(xplatxcf SHARED IMPORTED GLOBAL)
set_target_properties(xplatxcf PROPERTIES
IMPORTED_LOCATION ${XPLATXCF_LIBRARY}
)
add_executable(XCApp ...)
set_target_properties(XCApp PROPERTIES
... # Many other properties
# Embedding by target fails
XCODE_EMBED_FRAMEWORKS xplatxcf
# Embedding by path works
#XCODE_EMBED_FRAMEWORKS ${XPLATXCF_LIBRARY}
XCODE_LINK_BUILD_PHASE_MODE "KNOWN_LOCATION"
)
target_link_libraries(XCApp PRIVATE xplatxcf)
```
If you set `XCODE_EMBED_FRAMEWORKS` to the `xplatxcf` target, CMake fails with the following error:
```
CMake Error: Can not find a target for xplatxcf
CMake Generate step failed. Build files cannot be regenerated correctly.
```
Setting it to the actual location of the framework or XCFramework and setting the `XCODE_LINK_BUILD_PHASE_MODE` to `KNOWN_LOCATION` generates no such error and I have an example iOS project which uses this successfully.https://gitlab.kitware.com/cmake/cmake/-/issues/25486Link Step: Determining id of effective linker during generation2024-03-08T08:25:48-05:00Brad KingLink Step: Determining id of effective linker during generation!8885 added a way to detect what linker the compiler uses by default.
!8861 added a way to tell the compiler what linker to use on a per-target basis.
!9086 improved linker detection and identification to work on more platforms.
Howev...!8885 added a way to detect what linker the compiler uses by default.
!8861 added a way to tell the compiler what linker to use on a per-target basis.
!9086 improved linker detection and identification to work on more platforms.
However, I don't see a way at generate time to know the identity of the linker that will be used for a target when the `LINKER_TYPE` property is set. In order to make generate-time decisions to account for linker-specific behavior, we need to determine the effective linker id for a target.https://gitlab.kitware.com/cmake/cmake/-/issues/25483cxxmodules: support `ifcMap` for module mappers2023-12-07T21:20:56-05:00Ben Boeckelcxxmodules: support `ifcMap` for module mappersThe `-ifcMap` flag for MSVC takes a TOML file describing modules. Further metadata may be specified in here for future enhancement (e.g., [P3041R0](https://isocpp.org/files/papers/P3041R0.pdf) proposes implementing importing STL headers ...The `-ifcMap` flag for MSVC takes a TOML file describing modules. Further metadata may be specified in here for future enhancement (e.g., [P3041R0](https://isocpp.org/files/papers/P3041R0.pdf) proposes implementing importing STL headers via the `std` IFC file directly rather than via header unit compilation).
https://learn.microsoft.com/en-us/cpp/build/reference/ifc-map
Cc: @brad.kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25482Generator time is reported too short2024-02-06T11:22:34-05:00Cristian AdamGenerator time is reported too shortI just tested the CMake Profiler on CMake 3.28.0 on Windows using Qt Creator 12 on Qt Creator 12 source code.
![cmake-3.28-tracing-qtcreator-12](/uploads/a79823749fc4ff6d96c08e4d9e03cb77/cmake-3.28-tracing-qtcreator-12.png)
The generati...I just tested the CMake Profiler on CMake 3.28.0 on Windows using Qt Creator 12 on Qt Creator 12 source code.
![cmake-3.28-tracing-qtcreator-12](/uploads/a79823749fc4ff6d96c08e4d9e03cb77/cmake-3.28-tracing-qtcreator-12.png)
The generating time is reported as `-- Generating done (4.5s)` which doesn't sum up with the configure time to have the total time.https://gitlab.kitware.com/cmake/cmake/-/issues/25476presets: Conditional workflow preset step execution2023-12-23T01:53:46-05:00Craig Scottpresets: Conditional workflow preset step executionCurrently, workflow presets provide a fairly rigid facility. They execute a defined set of steps, stopping at the first one that fails. While the hook script feature proposed in #25475 would be a nice improvement, that still doesn't allo...Currently, workflow presets provide a fairly rigid facility. They execute a defined set of steps, stopping at the first one that fails. While the hook script feature proposed in #25475 would be a nice improvement, that still doesn't allow a workflow step to react to the state of steps that came before it. Consider the scenario where a test step might fail, but you still want to perform some sort of cleanup or reporting afterwards (e.g. collecting and reporting coverage data).
I propose we allow steps to specify conditions that define whether they execute or not. Instead of stopping a workflow at the first step that fails, `cmake` would continue through the list of steps and for each one, check if it has conditions and whether those conditions still allow it to run. By default, a step with no conditions would not execute in this scenario, which would preserve existing behavior.
A few different types of conditions could be supported:
* The step always runs, even if there has been an error in any previous step.
* The step never runs, unless there has been an error in any previous step.
* The step only runs if a particular earlier step (or maybe a list of steps) completed successfully.
* The step only runs if a particular earlier step (or maybe a list of steps) failed.
For the last two, if a list of steps is given, you'd have to decide whether they specify an AND or OR relationship.
One of the problems with the above is that we don't currently have a way to uniquely refer to a workflow step other than a numerical counter or index for the step number. That would be fairly fragile, in my view. We could allow referring to a step by name if the name is unique, but in my experience, names are frequently not unique. Perhaps we would add support for a new field like `id` or `reference` which is required to be unique for each step when given, and conditions between steps must use these fields to refer to other steps. This would mean existing workflow presets continue to work as before, and you only need to add these extra fields if you want to add inter-step conditions.
When combined with the feature proposed in #25475, the above proposal would make workflow presets a very powerful and flexible way of defining CI workflows.https://gitlab.kitware.com/cmake/cmake/-/issues/25475Hooks for reporting progress and failures in workflow presets2023-12-23T01:53:45-05:00Craig ScottHooks for reporting progress and failures in workflow presetsSome CI systems support a form of tagging within the job output to indicate sections within the overall set of steps. For example, TeamCity allows you to embed start and end section codes, and these can be nested. When viewing the logs o...Some CI systems support a form of tagging within the job output to indicate sections within the overall set of steps. For example, TeamCity allows you to embed start and end section codes, and these can be nested. When viewing the logs of such jobs, sections can be expanded and collapsed, making it easier to navigate to a particular part of the build output. Gitlab supports a similar mechanism, and I suspect most other CI systems do as well. Some may also support embedding measurement or result values which can be tracked from one run to another.
When running a CMake workflow preset, there's no opportunity for the job to provide such tags in the output. CMake embeds its own rudimentary progress markers, but to my knowledge, these are not understood by any current CI system. This means the entire workflow is seen as one monolithic chunk in the output.
Related to the above, if any part of the workflow fails and the workflow halts, the process driving the workflow has no idea what stage the workflow was executing when it failed. At best, the driving process might employ some heuristics to try to guess where the failure occurred, but this is a poor way to capture something so fundamental to the job.
Both of the above problems could be solved by giving a workflow a way to call some sort of hook before and after executing each step. A CMake script would potentially fit this idea, with data being passed to it through clearly documented CMake variables. For example, a workflow preset could support a `progressScript` field, the value of which is a path to a CMake script to invoke via `cmake -P ...` at the start and end of each workflow step. The `cmake` command line might also support a `--progress-script` option to achieve the same thing. CMake variables named `WORKFLOW_NAME`, `STEP_NUMBER`, `STEP_NAME`, `STEP_TYPE` and `STEP_STATE` would be defined when running the script each time (these are just ideas to spur discussion). The script could then take arbitrary action based on these values. It might log the CI-specific section start/end markers, for example. The `STEP_STATE` could hold values like `START`, `COMPLETE`, `ERROR`, `CRASH`, `SKIPPED`, etc. Further state-specific details might be made available in other variables if that is appropriate, but even just having the state is already highly useful.
This doesn't seem like a particularly complicated thing to implement, at least in concept, but the value is potentially quite high. Maybe IDEs might even find it useful as a way to get reliable progress on workflows, should they implement support for workflow presets (I don't know if any do yet).https://gitlab.kitware.com/cmake/cmake/-/issues/25472CrayClang : Linker language issue when mixing Fortran and C++2023-12-08T09:58:13-05:00Alain MiniussiCrayClang : Linker language issue when mixing Fortran and C++Hi,
I installed CMake 3.28 rc5 on a HPE Cray HPC environment to test the newly recognized CrayClang compiler.
The compiler identification works, but I have the following specificity:
```
add_executable(test_symba7 test_symba7.f90)
...Hi,
I installed CMake 3.28 rc5 on a HPE Cray HPC environment to test the newly recognized CrayClang compiler.
The compiler identification works, but I have the following specificity:
```
add_executable(test_symba7 test_symba7.f90)
target_link_libraries(test_symba7 symba7seq fargoseqrt)
set_target_properties(test_symba7
PROPERTIES
INCLUDE_DIRECTORIES ${CMAKE_BINARY_DIR}/include/swift
)
if (CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
message(INFO " Cray compiler needs to link some mix of Fortran and C++ with C++ linker.")
set_target_properties(test_symba7
PROPERTIES
LINKER_LANGUAGE CXX)
endif()
```
Where `fargoseqrt` is a full C++ library and `symba7seq` a mix of C++ and Fortran.
I don't know if this is expected or if the "correct" linker language should be automatically detected but I though I'd tried to let you know before the release.Ryan Krattigerryan.krattiger@kitware.comRyan Krattigerryan.krattiger@kitware.comhttps://gitlab.kitware.com/cmake/cmake/-/issues/25471add_test: Update or remove classic signature with a policy2023-12-08T08:21:39-05:00Brad Kingadd_test: Update or remove classic signature with a policyThe [`add_test`](https://cmake.org/cmake/help/v3.28/command/add_test.html) command has two signatures:
```
add_test(NAME <name> COMMAND <command> ...)
add_test(<name> <command> ...)
```
The latter/classic signature does not support eve...The [`add_test`](https://cmake.org/cmake/help/v3.28/command/add_test.html) command has two signatures:
```
add_test(NAME <name> COMMAND <command> ...)
add_test(<name> <command> ...)
```
The latter/classic signature does not support everything the former signature does, and AFAIK there is no reason to use it besides brevity. We should consider updating the classic signature to support modern features, or removing it. Either approach requires a policy.https://gitlab.kitware.com/cmake/cmake/-/issues/25469`FetchContent` is unable to extract a downloaded GZ archive file2023-12-05T07:01:35-05:00Darshan Sen`FetchContent` is unable to extract a downloaded GZ archive file# Issue
When `FetchContent` is used to download and extract the `libv8_monolith-win-x64.lib.gz` file from https://github.com/just-js/v8/releases/tag/1.0.0, the extraction fails with the `Problem with archive_write_header()` CMake error....# Issue
When `FetchContent` is used to download and extract the `libv8_monolith-win-x64.lib.gz` file from https://github.com/just-js/v8/releases/tag/1.0.0, the extraction fails with the `Problem with archive_write_header()` CMake error.
However, I can confirm that the file can be extracted by `gzip.exe` without errors. Here are the Git Bash logs:
```cmd
$ dir
$ curl.exe -LO https://github.com/just-js/v8/releases/download/1.0.0/libv8_monolith-win-x64.lib.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 37.6M 100 37.6M 0 0 12.4M 0 0:00:03 0:00:03 --:--:-- 17.8M
$ file libv8_monolith-win-x64.lib.gz
libv8_monolith-win-x64.lib.gz: gzip compressed data, was "v8_monolith.lib", last modified: Tue Nov 28 02:39:01 2023, max compression, from Unix, original size modulo 2^32 182101188
$ sha256sum.exe libv8_monolith-win-x64.lib.gz
0dea59dc49e1a7a7d69620f9fbc1c37fa8a0b6b81d41021c2356eb43a45e0472 *libv8_monolith-win-x64.lib.gz
$ gzip.exe -d libv8_monolith-win-x64.lib.gz
$ dir
libv8_monolith-win-x64.lib
$ file libv8_monolith-win-x64.lib
libv8_monolith-win-x64.lib: current ar archive
$ sha256sum.exe libv8_monolith-win-x64.lib
3070fec5541eaca1833f8623d77854bebc74c8f35fc16565d18717e9d4ffa0cb *libv8_monolith-win-x64.lib
```
# Repro
**`CMakeLists.txt`**
```cmake
cmake_minimum_required(VERSION 3.26)
project(Demo)
include(FetchContent)
# The libv8_monolith-win-x64.lib.gz file from
# https://github.com/just-js/v8/releases/tag/1.0.0
FetchContent_Declare(
v8_lib
URL https://github.com/just-js/v8/releases/download/1.0.0/libv8_monolith-win-x64.lib.gz
URL_HASH SHA256=0dea59dc49e1a7a7d69620f9fbc1c37fa8a0b6b81d41021c2356eb43a45e0472
DOWNLOAD_EXTRACT_TIMESTAMP YES # To silence a CMake warning.
)
FetchContent_MakeAvailable(v8_lib)
```
# Output
## On Windows
```cmd
C:\Users\admin\Desktop\temp\project\demo>cmake -version
cmake version 3.26.4-msvc4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
C:\Users\admin\Desktop\temp\project\demo>cmake -B build
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.22635.
-- The C compiler identification is MSVC 19.37.32825.0
-- The CXX compiler identification is MSVC 19.37.32825.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
MSBuild version 17.7.2+d6990bcfa for .NET Framework
Checking Build System
Creating directories for 'v8_lib-populate'
Building Custom Rule C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/CMakeLists.txt
Performing download step (download, verify and extract) for 'v8_lib-populate'
-- Downloading...
dst='C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
timeout='none'
inactivity timeout='none'
-- Using src='https://github.com/just-js/v8/releases/download/1.0.0/libv8_monolith-win-x64.lib.gz'
-- [download 0% complete]
-- [download 1% complete]
...
-- [download 99% complete]
-- [download 100% complete]
-- verifying file...
file='C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
-- Downloading... done
-- extracting...
src='C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
dst='C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-src'
-- extracting... [tar xf]
CUSTOMBUILD : CMake error : Problem with archive_write_header(): Can't create '\\?\C:\' [C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\v8_lib-populate.vcxproj]
CUSTOMBUILD : CMake error : Current file: / [C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\v8_lib-populate.vcxproj]
CUSTOMBUILD : CMake error : Problem extracting tar: C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar [C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\v8_lib-populate.vcxproj]
-- extracting... [error clean up]
CMake Error at v8_lib-subbuild/v8_lib-populate-prefix/src/v8_lib-populate-stamp/extract-v8_lib-populate.cmake:40 (message):
Extract of
'C:/Users/admin/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
failed
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(249,5): error MSB8066: Custom build for 'C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-mkdir.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-download.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-update.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-patch.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-configure.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-build.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-install.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\7089584c56f262286fa410aaa7c98d28\v8_lib-populate-test.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\9b5337c7dc195c0cb939922b4182b245\v8_lib-populate-complete.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeFiles\fc34208ef54c4a271071de523cb4cab3\v8_lib-populate.rule;C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\CMakeLists.txt' exited with code 1. [C:\Users\admin\Desktop\temp\project\demo\build\_deps\v8_lib-subbuild\v8_lib-populate.vcxproj]
CMake Error at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1622 (message):
Build step for v8_lib failed: 1
Call Stack (most recent call first):
C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1762:EVAL:2 (__FetchContent_directPopulate)
C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1762 (cmake_language)
C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1976 (FetchContent_Populate)
CMakeLists.txt:16 (FetchContent_MakeAvailable)
-- Configuring incomplete, errors occurred!
```
## On macOS (slightly different error message)
```sh
❯ cmake -version
cmake version 3.26.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
❯ cmake -B build
-- The C compiler identification is AppleClang 15.0.0.15000040
-- The CXX compiler identification is AppleClang 15.0.0.15000040
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
[ 11%] Creating directories for 'v8_lib-populate'
[ 22%] Performing download step (download, verify and extract) for 'v8_lib-populate'
-- Downloading...
dst='/Users/raisinten/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
timeout='none'
inactivity timeout='none'
-- Using src='https://github.com/just-js/v8/releases/download/1.0.0/libv8_monolith-win-x64.lib.gz'
-- [download 0% complete]
-- [download 1% complete]
...
-- [download 99% complete]
-- [download 100% complete]
-- verifying file...
file='/Users/raisinten/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
-- Downloading... done
-- extracting...
src='/Users/raisinten/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
dst='/Users/raisinten/Desktop/temp/project/demo/build/_deps/v8_lib-src'
-- extracting... [tar xf]
CMake Error: Problem with archive_write_header(): Can't replace existing directory with non-directory
CMake Error: Current file: /
CMake Error: Problem extracting tar: /Users/raisinten/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar
-- extracting... [error clean up]
CMake Error at v8_lib-subbuild/v8_lib-populate-prefix/src/v8_lib-populate-stamp/extract-v8_lib-populate.cmake:40 (message):
Extract of
'/Users/raisinten/Desktop/temp/project/demo/build/_deps/v8_lib-subbuild/v8_lib-populate-prefix/src/archive.tar'
failed
make[2]: *** [v8_lib-populate-prefix/src/v8_lib-populate-stamp/v8_lib-populate-download] Error 1
make[1]: *** [CMakeFiles/v8_lib-populate.dir/all] Error 2
make: *** [all] Error 2
CMake Error at /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/FetchContent.cmake:1622 (message):
Build step for v8_lib failed: 2
Call Stack (most recent call first):
/usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/FetchContent.cmake:1762:EVAL:2 (__FetchContent_directPopulate)
/usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/FetchContent.cmake:1762 (cmake_language)
/usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/FetchContent.cmake:1976 (FetchContent_Populate)
CMakeLists.txt:16 (FetchContent_MakeAvailable)
-- Configuring incomplete, errors occurred!
```https://gitlab.kitware.com/cmake/cmake/-/issues/25468FetchContent: Integration with cmake --fresh2023-12-04T16:16:56-05:00Craig ScottFetchContent: Integration with cmake --freshIf you use the `--fresh` option on the `cmake` command line, it should discard the `CMakeCache.txt` and other things. But if you run that in a build directory that was previously executed with a different CMake generator to what you want...If you use the `--fresh` option on the `cmake` command line, it should discard the `CMakeCache.txt` and other things. But if you run that in a build directory that was previously executed with a different CMake generator to what you want to use now, CMake will complain about the different generator when it tries to re-use the sub-build directory for any FetchContent-provided dependency.https://gitlab.kitware.com/cmake/cmake/-/issues/25467Why separate Windows (CRLF) and Linux (LF) sources needed in https://cmake.or...2023-12-06T16:38:29-05:00gitartpianoWhy separate Windows (CRLF) and Linux (LF) sources needed in https://cmake.org/download/ ? Could we just have LF only?Assuming that every editor and tool chain supports the Unix line ending (LF only) of the source files why Windows edition of the source package is needed at https://cmake.org/download/? It does not solve any problems, but adds to the con...Assuming that every editor and tool chain supports the Unix line ending (LF only) of the source files why Windows edition of the source package is needed at https://cmake.org/download/? It does not solve any problems, but adds to the confusion.
If the above assumption is wrong please provide the reason, I (maybe other software developers too) would really like to learn why every other open source package can get away with a single type of source release, but not `cmake`.https://gitlab.kitware.com/cmake/cmake/-/issues/25461bash completions have undocumented dependency for _filedir etc, produce "comm...2024-02-26T10:16:38-05:00Clarence "Sparr" Risherbash completions have undocumented dependency for _filedir etc, produce "command not found" otherwise<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
All three completion files in https://gitlab.kitware.com/cmake/cmake/-/tree/v3.27.8/Auxiliary/bash-completion depend on the presence of shell helper functions such as _filedir, __split_longopt, _ncpus, and _parse_help. These are not built-in bash functions, but could be provided by various completion libraries. None of the documentation or packaging metadata, or even comments in these files, mentions this dependency.
At the very least, it should be mentioned, including naming a specific completion library which provides the necessary functions with behavior compatible with these scripts.
Ideally, this dependency would not exist, and the completions would function on their own.https://gitlab.kitware.com/cmake/cmake/-/issues/25460ctest bash completion syntax error without extglob option2023-11-30T15:06:47-05:00Clarence "Sparr" Risherctest bash completion syntax error without extglob optionI am encountering this problem with completions installed via Homebrew, but the problem is not specific to brew.
```plaintext
$ bash
bash: /opt/homebrew/etc/bash_completion.d/ctest: line 43: syntax error in conditional expression: unexp...I am encountering this problem with completions installed via Homebrew, but the problem is not specific to brew.
```plaintext
$ bash
bash: /opt/homebrew/etc/bash_completion.d/ctest: line 43: syntax error in conditional expression: unexpected token `('
bash: /opt/homebrew/etc/bash_completion.d/ctest: line 43: syntax error near `@(E'
bash: /opt/homebrew/etc/bash_completion.d/ctest: line 43: ` if [[ $cur == @(Experimental|Nightly|Continuous)* ]]; then'
```
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.27.8/Auxiliary/bash-completion/ctest?ref_type=tags#L44
The `@()` syntax requires extglob pattern matching. If `shopt extglob` is `off` then this error is encountered. Adding `shopt -s extglob` to the top of the file avoids the failure, but is not a desirable solution because this file is `source`d which will result in the option being changed in the calling shell.
One possible solution is to avoid extglob syntax here. This would be the simplest.
Another possible solution is to use `shopt -p extglob` to get a command to restore the current option setting, then `shopt -s extglob` to enable the option for the necessary duration, then run the command from `-p` to restore the original setting. This would need to be done at the top of the file so that the script is correctly handled during bash loading. Setting the option may also be required within the function, including avoiding affecting the calling shell.https://gitlab.kitware.com/cmake/cmake/-/issues/25459Ninja: Parallel Installation Option2023-11-30T15:04:58-05:00Martin DuffyNinja: Parallel Installation OptionCurrently, there is no way to run the install step for a CMake project in parallel. This can result in long install times for some projects.
The Ninja generator creates `sub/dir/install/local` targets which install a particular director...Currently, there is no way to run the install step for a CMake project in parallel. This can result in long install times for some projects.
The Ninja generator creates `sub/dir/install/local` targets which install a particular directory without installing its subdirectories. For a project that does not rely on a global state modified by the install code, these targets can be executed simultaneously to fully parallelize the installation.
There are two things needed to make this possible:
1. Create an additional target (`install/local/all`?) which depends all other `../install/local` targets.
2. Add an option (`CMAKE_INSTALL_LOCAL_PARALLEL`?) to remove the console pool from the `../install/local` targets so that they can run in parallel.https://gitlab.kitware.com/cmake/cmake/-/issues/25457-std flag missing for CMAKE_CXX_STANDARD=26 CMAKE_CXX_EXTENSIONS=OFF2023-12-01T09:14:17-05:00huangqinjin-std flag missing for CMAKE_CXX_STANDARD=26 CMAKE_CXX_EXTENSIONS=OFFTested with CMake 3.27.8.
| OPTIONS | GCC 13 | Clang 16 |
|---------|--------------|--------------|
| 23/ON | -std=gnu++23 | -std=gnu++2b |
| 23/OFF | -std=c++23 | -std=c++2b |
| 26/ON | -std=gnu++23 | -std=gnu++2b |
...Tested with CMake 3.27.8.
| OPTIONS | GCC 13 | Clang 16 |
|---------|--------------|--------------|
| 23/ON | -std=gnu++23 | -std=gnu++2b |
| 23/OFF | -std=c++23 | -std=c++2b |
| 26/ON | -std=gnu++23 | -std=gnu++2b |
| 26/OFF | | |
Quote from https://cmake.org/cmake/help/v3.27/prop_tgt/CXX_STANDARD.html#prop_tgt:CXX_STANDARD
> If the value requested does not result in a compile flag being added for the compiler in use, a previous standard flag will be added instead.Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/25451try_run: Add option to specify how test binary is launched2023-11-29T08:24:34-05:00Matthew Thompsontry_run: Add option to specify how test binary is launchedPer a [thread on the Discourse](https://discourse.cmake.org/t/how-to-try-run-mpi-code/9516/1), I have a case where it would be useful to use `try_run` but with an MPI application. As far as I know, there is no way to do this (or perhaps ...Per a [thread on the Discourse](https://discourse.cmake.org/t/how-to-try-run-mpi-code/9516/1), I have a case where it would be useful to use `try_run` but with an MPI application. As far as I know, there is no way to do this (or perhaps no *easy* way). @ben.boeckel thought having a `LAUNCHER` option might be one way to do so. Probably better than something MPI-specific since I suppose some systems rely on other launchers. Perhaps we'd need a `LAUNCHER` and `LAUNCHER_ARGS` a la `ARGS` so we can pass specific flags to the launcher?
(Note: Per that thread, I still think I might be using `try_run` incorrectly as it just...never seemed to run anything, but had it worked and without `mpirun -np 1`, it should have been a success.)