CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-28T01:18:20-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25796add_dependencies: Document behavior under Ninja generators2024-03-28T01:18:20-04:00Brad Kingadd_dependencies: Document behavior under Ninja generatorsAs identified in discussion starting at https://gitlab.kitware.com/cmake/cmake/-/issues/25788#note_1497400, the documentation of `add_dependencies` needs clarification for the behavior of the Ninja generators introduced for #15555.As identified in discussion starting at https://gitlab.kitware.com/cmake/cmake/-/issues/25788#note_1497400, the documentation of `add_dependencies` needs clarification for the behavior of the Ninja generators introduced for #15555.Juan RamosJuan Ramoshttps://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/25435Ninja+MSVC: Broken dependencies on headers generated in source tree2023-11-22T08:32:05-05:00rconde01Ninja+MSVC: Broken dependencies on headers generated in source treeI have the following structure:
`<root>`
- CMakeLists.txt
- generator
- CMakeLists.txt
- main.cpp
- generated
- my_header.h
- client
- CMakeLists.txt
- f1.cpp
- f2.cpp
- main.cpp
`<root>/CMakeLists.txt`
```
cmake_minim...I have the following structure:
`<root>`
- CMakeLists.txt
- generator
- CMakeLists.txt
- main.cpp
- generated
- my_header.h
- client
- CMakeLists.txt
- f1.cpp
- f2.cpp
- main.cpp
`<root>/CMakeLists.txt`
```
cmake_minimum_required(VERSION 3.20)
project(test)
cmake_path(SET my-gen-file NORMALIZE "${CMAKE_SOURCE_DIR}/generated/my_header.h")
add_subdirectory(generator)
add_subdirectory(client)
```
`<root>/generator/CMakeLists.txt`
```
add_executable(my-file-generator main.cpp)
add_custom_command(
OUTPUT ${my-gen-file}
COMMAND "$<TARGET_FILE:my-file-generator>" ${my-gen-file}
DEPENDS my-file-generator
)
add_custom_target(generate-my-file DEPENDS "${my-gen-file}")
```
`<root>/generator/main.cpp`
```
#include <fstream>
#include <string>
int main(int argc, char**argv){
std::string path = argv[1];
std::ofstream file(path);
file << "#pragma once\n";
return 0;
}
```
`<root>/client/CMakeLists.txt`
```
add_executable(client main.cpp f1.cpp f2.cpp)
add_dependencies(client generate-my-file)
# Need to do this because GENERATED property doesn't propagate
set_source_files_properties("${my-gen-file}" PROPERTIES GENERATED TRUE)
target_include_directories(client PRIVATE "${CMAKE_SOURCE_DIR}")
```
`<root>/client/f1.cpp`
```
#include "generated/my_header.h"
```
`<root>/client/f2.cpp`
```
#include "generated/my_header.h"
```
`<root>/client/main.cpp`
```
#include <iostream>
#include "generated/my_header.h"
int main(){
std::cout << "hello\n";
return 0;
}
```
Using Visual Studio + Ninja, if I rebuild I get:
```
[1/7] Building CXX object generator\CMakeFiles\my-file-generator.dir\main.cpp.obj
[2/7] Linking CXX executable generator\my-file-generator.exe
[3/7] Generating D:/dev/cmake_gen_update_detection/generated/my_header.h
[4/7] Building CXX object client\CMakeFiles\client.dir\f1.cpp.obj
[5/7] Building CXX object client\CMakeFiles\client.dir\f2.cpp.obj
[6/7] Building CXX object client\CMakeFiles\client.dir\main.cpp.obj
[7/7] Linking CXX executable client\client.exe
Rebuild All succeeded.
```
If I then touch `<root>/generator/main.cpp` and build I get:
```
[1/3] Building CXX object generator\CMakeFiles\my-file-generator.dir\main.cpp.obj
[2/3] Linking CXX executable generator\my-file-generator.exe
[3/3] Generating D:/dev/cmake_gen_update_detection/generated/my_header.h
Build All succeeded.
```
and then if I build again I get:
```
[1/4] Building CXX object client\CMakeFiles\client.dir\f1.cpp.obj
[2/4] Building CXX object client\CMakeFiles\client.dir\f2.cpp.obj
[3/4] Building CXX object client\CMakeFiles\client.dir\main.cpp.obj
[4/4] Linking CXX executable client\client.exe
```
After touching `<root>/generator/main.cpp` I expect everything to be updated in a single build.https://gitlab.kitware.com/cmake/cmake/-/issues/25352Ninja/MSVC: Always rebuilds if project path contains non-ascii characters (um...2023-10-20T10:58:50-04:00NickNinja/MSVC: Always rebuilds if project path contains non-ascii characters (umlauts, etc.)I tested building the exact same project both inside a dir with and without an umlaut in the path. Without the umlaut in the path the project builds once and runs after the build has finished, as expected. With the umlaut in the path the...I tested building the exact same project both inside a dir with and without an umlaut in the path. Without the umlaut in the path the project builds once and runs after the build has finished, as expected. With the umlaut in the path the project builds every single time, even if there are no code changes.
Tested with CMake version 3.26.4https://gitlab.kitware.com/cmake/cmake/-/issues/25245Ninja: cmake_transform_depfile doesn't account for CMAKE_NINJA_OUTPUT_PATH_PR...2023-09-11T17:52:12-04:00FerronnNinja: cmake_transform_depfile doesn't account for CMAKE_NINJA_OUTPUT_PATH_PREFIXThe relative paths produced by `cmake_transform_depfile` are not prefixed by `CMAKE_NINJA_OUTPUT_PATH_PREFIX` when present, causing the outputs using that depfile to be rebuilt on every build.
The following is a (hopefully minimal) exam...The relative paths produced by `cmake_transform_depfile` are not prefixed by `CMAKE_NINJA_OUTPUT_PATH_PREFIX` when present, causing the outputs using that depfile to be rebuilt on every build.
The following is a (hopefully minimal) example of the behavior. Given this CMakeLists.txt file:
```cmake
cmake_minimum_required(VERSION 3.20)
project(hello LANGUAGES)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dep.txt "")
file(CONFIGURE OUTPUT hello.txt.d CONTENT [[
${CMAKE_CURRENT_BINARY_DIR}/hello.txt: ${CMAKE_CURRENT_BINARY_DIR}/dep.txt
]])
add_custom_command(
OUTPUT hello.txt
COMMAND ${CMAKE_COMMAND} -E touch hello.txt
COMMAND ${CMAKE_COMMAND} -E touch_nocreate hello.txt.d
DEPFILE hello.txt.d
)
add_custom_target(hello DEPENDS hello.txt)
```
and this build.ninja file:
```
subninja b/build.ninja
```
and a build system generated thusly:
```
cmake -B b -G Ninja -DCMAKE_NINJA_OUTPUT_PATH_PREFIX=b/
```
The first build works as expected:
```
$ ninja -d explain b/hello
ninja explain: depfile '/home/vscode/b/CMakeFiles/d/9191569e8267d24c4fff2748c58b94d12d14abdf677b16d74cfa2a0ce141b9ff.d' is missing
ninja explain: b/hello.txt is dirty
ninja explain: b/CMakeFiles/hello is dirty
ninja explain: b/hello.txt is dirty
[1/1] Generating hello.txt
```
Here are the contents of the transformed depfile:
```
hello.txt: \
dep.txt
```
These paths do not include `CMAKE_NINJA_OUTPUT_PATH_PREFIX` and thus ninja gets cranky on subsequent builds:
```
$ ninja -d explain b/hello
ninja explain: expected depfile '/home/vscode/b/CMakeFiles/d/9191569e8267d24c4fff2748c58b94d12d14abdf677b16d74cfa2a0ce141b9ff.d' to mention 'b/hello.txt', got 'hello.txt'
ninja explain: b/hello.txt is dirty
ninja explain: b/CMakeFiles/hello is dirty
ninja explain: b/hello.txt is dirty
[1/1] Generating hello.txt
```https://gitlab.kitware.com/cmake/cmake/-/issues/25152Ninja Multi-Config: Provide a way to exclude building a configuration for a t...2023-08-02T11:37:26-04:00alcroitoNinja Multi-Config: Provide a way to exclude building a configuration for a target when using cross config modeConsider the project
```cmake
cmake_minimum_required(VERSION 3.21.0)
set(CMAKE_CONFIGURATION_TYPES "Release;Debug" CACHE STRING "")
if(CMAKE_GENERATOR STREQUAL "Ninja Multi-Config")
set(CMAKE_DEFAULT_BUILD_TYPE "Release" CACHE STRING...Consider the project
```cmake
cmake_minimum_required(VERSION 3.21.0)
set(CMAKE_CONFIGURATION_TYPES "Release;Debug" CACHE STRING "")
if(CMAKE_GENERATOR STREQUAL "Ninja Multi-Config")
set(CMAKE_DEFAULT_BUILD_TYPE "Release" CACHE STRING "")
set(CMAKE_CROSS_CONFIGS "all" CACHE STRING "")
set(CMAKE_DEFAULT_CONFIGS "all" CACHE STRING "")
endif()
project(proj LANGUAGES CXX)
set(source_path "${CMAKE_CURRENT_BINARY_DIR}/source.cpp")
file(WRITE "${source_path}" "void foo() {}")
add_library(Core SHARED "${source_path}")
```
Configuring with `cmake .. -G"Ninja Multi-Config"` and running `ninja -v` will build the `Core` target for both `Release` and `Debug`.
There is currently no way to tell CMake not to generate build rules for a specific configuration of a target.
I propose introducing a new property called `CROSS_CONFIGS` which can be set to a subset of `CMAKE_CONFIGURATION_TYPES`.
E.g. with
```cmake
set_target_properties(Core PROPERTIES CROSS_CONFIGS "Debug")
```
calling either `ninja` or `ninja Core` will only build the `Core` library for 'Debug'.
Trying to call `ninja Core:Release` would be an error, because CMake would not generate any build rules for a `Release` library.
The property should also work for `add_custom_target` and any `add_custom_command`s that are driven by the target.
The proposed feature is different from https://gitlab.kitware.com/cmake/cmake/-/issues/20923 because it's not about excluding a configuration from the `all` target, but not generating build rules at all.https://gitlab.kitware.com/cmake/cmake/-/issues/25040add_custom_command(TARGET): USES_TERMINAL does not use console pool with Ninja2023-06-29T11:00:42-04:00William Jonesadd_custom_command(TARGET): USES_TERMINAL does not use console pool with Ninja_Mostly copied and pasted from [this stack overflow post](https://stackoverflow.com/questions/76576407/specifying-uses-terminal-for-custom-command-in-cmake-does-not-use-console-pool)_
If `add_custom_command` is called using the "build e..._Mostly copied and pasted from [this stack overflow post](https://stackoverflow.com/questions/76576407/specifying-uses-terminal-for-custom-command-in-cmake-does-not-use-console-pool)_
If `add_custom_command` is called using the "build events" signature with `USES_TERMINAL` in order to get a prompt for a user's password when running a command using `sudo`, as seen in the following CMakeLists.txt snippet:
```
add_executable(my-app main.c)
add_custom_command(
TARGET my-app
POST_BUILD
COMMAND sudo setcap cap_net_admin+eip $<TARGET_FILE:my-app>
USES_TERMINAL
)
```
And then configure and build using Ninja:
```
$ cmake -G Ninja -B build
$ cmake --build build
```
The prompt for the user's password does not appear, and the build hangs. Looking at the resulting `build.ninja` file, I would expect there to be a `pool = console` setting for building my-app, but it's not present:
```
build my-app: C_EXECUTABLE_LINKER__my-app_ CMakeFiles/my-app.dir/main.c.o
OBJECT_DIR = CMakeFiles/my-app.dir
POST_BUILD = cd /home/bob/test_cmake_uses_terminal/build && sudo setcap cap_net_admin+eip /home/bob/test_cmake_uses_terminal/build/my-app
PRE_LINK = :
TARGET_COMPILE_PDB = CMakeFiles/my-app.dir/
TARGET_FILE = my-app
TARGET_PDB = my-app.pdb
```
If `pool = console` is manually added to that list, it properly prompts for the user's password when runnning the command.
I was able to get this to work in a more kludgey way using `add_custom_target`, but I'd like to know why `USES_TERMINAL` is not working as I interpret the documentation.
Tested using cmake version 3.24.1, Ninja version 1.10.1, and running on Ubuntu 22.04.https://gitlab.kitware.com/cmake/cmake/-/issues/24984Ninja/ASM/Apple: Fat library fails to rebuild after assembly source file is u...2023-06-08T11:03:51-04:00Thomas A.Ninja/ASM/Apple: Fat library fails to rebuild after assembly source file is updated<!--
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/
-->
# Issue
When ninja tries to build a fat library that contains an assembly source, it will fail to build on a consecutive run when the assembly source has been updated.
```
[2/2] : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cr libdylib1_10_5.a CMakeFiles/dylib1_10_5.dir/dyld_glue.S.o && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libdylib1_10_5.a && :
FAILED: libdylib1_10_5.a
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cr libdylib1_10_5.a CMakeFiles/dylib1_10_5.dir/dyld_glue.S.o && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libdylib1_10_5.a && :
ar: libdylib1_10_5.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: libdylib1_10_5.a: Inappropriate file type or format
ninja: build stopped: subcommand failed.
```
From my testing, the following two conditions need to be met for this bug to occur:
* the object built must be universal binary (ex: `set(CMAKE_OSX_ARCHITECTURES "i386;x86_64")`).
* The source file needs to be an assembly file.
This issue does not occur when using `make`. This has been tested on macOS (this issue can also happen on Linux when cross-building macOS executables).
# How to reproduce
1. Clone `https://github.com/apple-oss-distributions/Csu.git`. Checkout `Csu-88`.
2. Add the following `CMakeLists.txt` file & rename `dyld_glue.s` to `dyld_glue.S`:
```cmake
cmake_minimum_required(VERSION 3.24.2)
project(csu)
enable_language(ASM)
set(CMAKE_OSX_ARCHITECTURES "i386;x86_64")
ADD_LIBRARY(dylib1_10_5 STATIC dyld_glue.S)
target_compile_options(dylib1_10_5
PRIVATE
-r
-Os
-mmacosx-version-min=10.5
-nostdlib
-keep_private_externs
-DCFM_GLUE
)
```
3. Create a `build` folder and build the library as you normally would:
```
mkdir build
cd build
cmake .. -GNinja
ninja -v
```
4. Use `touch` to simulate file being updated and do another `ninja` build:
```
touch ../dyld_glue.S
ninja -v
```
5. You should get a build failure.
# Version details
```
% sw_vers
ProductName: macOS
ProductVersion: 13.4
BuildVersion: 22F66
% cmake --version
cmake version 3.26.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```https://gitlab.kitware.com/cmake/cmake/-/issues/24964Ninja: Support unconditional object path shortening on Windows2023-06-07T00:15:55-04:00Tristan LabelleNinja: Support unconditional object path shortening on WindowsI am running into a `MAX_PATH` issue on Windows where CMake is able to write under a substituted drive without needing to shorten the path, but later (after CMake) the same path is used in its full expanded form and exceeds `MAX_PATH`. I...I am running into a `MAX_PATH` issue on Windows where CMake is able to write under a substituted drive without needing to shorten the path, but later (after CMake) the same path is used in its full expanded form and exceeds `MAX_PATH`. It would help to have CMake unconditionally use shortened object paths.
The relevant code is around `cmLocalGenerator::GetObjectFileNameWithoutTarget`.
Related to: https://gitlab.kitware.com/cmake/cmake/-/issues/15859https://gitlab.kitware.com/cmake/cmake/-/issues/24913Ninja: $ORIGIN not properly escaped in response files2023-06-06T10:16:28-04:00Bram MetschNinja: $ORIGIN not properly escaped in response filesIf the Ninja generator decides to use a response file, any `\$$ORIGIN` occurance from the build.ninja ends up as `\$ORIGIN` in the response file, causing also `\$ORIGIN` to occur in the resulting `.so` or executable.
Not sure whether it...If the Ninja generator decides to use a response file, any `\$$ORIGIN` occurance from the build.ninja ends up as `\$ORIGIN` in the response file, causing also `\$ORIGIN` to occur in the resulting `.so` or executable.
Not sure whether it is rather a Ninja or a CMake issue, but my suggestion would be to at least have the option to prevent the linking options being pushed to the response file.https://gitlab.kitware.com/cmake/cmake/-/issues/24802Ninja: broken build statements on empty custom commands2023-12-11T14:47:21-05:00Mario EmmenlauerNinja: broken build statements on empty custom commandsI have a problem running `ninja` on the target `all_qmllint` generated for a Qt 6.5.0 project. The build aborts with error `CreateProcess failed: The system cannot find the file specified`. I could patch ninja to show the failing command...I have a problem running `ninja` on the target `all_qmllint` generated for a Qt 6.5.0 project. The build aborts with error `CreateProcess failed: The system cannot find the file specified`. I could patch ninja to show the failing command, and it printed:
```
CreateProcess failed: The system cannot find the file 'cd /D C:\Src\MyQtGUIComponents\MyQtModels' specified.
```
In turn I could trace this in `build.ninja` to a block that reads:
```
# Custom command for MyQtModels\CMakeFiles\MyQtModelsForQml_qmllint
build MyQtModels\CMakeFiles\MyQtModelsForQml_qmllint | ${cmake_ninja_workdir}MyQtModels\CMakeFiles\MyQtModelsForQml_qmllint: CUSTOM_COMMAND C$:\data\usr-dst-C10Skc1935322161c1507\Debug\bin\qmllint.exe || MyQtModels\MyQtModelsForQml.dll MyQtModels\MyQtModelsForQml_autogen MyQtModels\MyQtModelsForQml_autogen_timestamp_deps MyQtModels\MyQtModelsForQml_qmltyperegistration MyQtModels\all_qmltyperegistrations MyQtQuick\MyQtQuick_autogen_timestamp_deps MyQtQuick\MyQtQuick_qmltyperegistration
COMMAND = cd /D C:\Src\MyQtGUIComponents\MyQtModels
```
I am under the impression that cmake has a bug there, because it adds a `cd` command, but nothing else. Looking at cmake sources in https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.3/Source/cmLocalNinjaGenerator.cxx#L553, the logic seems slightly flawed: If commands exist, but all of them are empty, then no commands are emitted, *except* the `cd`-command, which would be useless, and seems to break ninja.
I have changed the logic to:
```
diff --git a/Source/cmLocalNinjaGenerator.cxx b/Source/cmLocalNinjaGenerator.cxx
index 3443cd31b3..49287ae544 100644
--- a/Source/cmLocalNinjaGenerator.cxx
+++ b/Source/cmLocalNinjaGenerator.cxx
@@ -550,7 +550,16 @@ void cmLocalNinjaGenerator::AppendCustomCommandLines(
{
auto* gg = this->GetGlobalNinjaGenerator();
- if (ccg.GetNumberOfCommands() > 0) {
+ int numNonEmptyCommands = 0;
+ for (unsigned i = 0; i != ccg.GetNumberOfCommands(); ++i) {
+ if (!ccg.GetCommand(i).empty()) {
+ ++numNonEmptyCommands;
+ }
+ }
+
+ if (numNonEmptyCommands == 0) {
+ return;
+ } else {
std::string wd = ccg.GetWorkingDirectory();
if (wd.empty()) {
wd = this->GetCurrentBinaryDirectory();
```
Then the build works. The new generated block in `build.ninja` becomes:
```
# Phony custom command for MyQtModels\CMakeFiles\MyQtModelsForQml_qmllint
build MyQtModels\CMakeFiles\MyQtModelsForQml_qmllint | ${cmake_ninja_workdir}MyQtModels\CMakeFiles\MyQtModelsForQml_qmllint: phony C$:\data\usr-dst-C10Skc1935322161c1507\Debug\bin\qmllint.exe || MyQtModels\MyQtModelsForQml.dll MyQtModels\MyQtModelsForQml_autogen MyQtModels\MyQtModelsForQml_autogen_timestamp_deps MyQtModels\MyQtModelsForQml_qmltyperegistration MyQtModels\all_qmltyperegistrations MyQtQuick\MyQtQuick_autogen_timestamp_deps MyQtQuick\MyQtQuick_qmltyperegistration
```
I am not providing this as a PR because probably the same problem exists in other generators too?! Possibly this would be better fixed directly in `GetNumberOfCommands()`, but that may have wide implications, so I better not touch that myself.https://gitlab.kitware.com/cmake/cmake/-/issues/24629Ninja Multi-Config: Per-config inter-target dependencies2023-03-27T02:34:56-04:00letian chengNinja Multi-Config: Per-config inter-target dependencies<!--
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/
-->
Config related generator expression used in "target_link_libraries()" command seems not addressed correctly when the generator is "Ninja Multi-Config".
For example,
```
cmake_minimum_required(VERSION 3.20)
project("example")
add_library(libA STATIC a.cpp)
add_library(libB SHARED b.cpp)
target_link_libraries(
libB PRIVATE
$<$<CONFIG:Debug>:libA>
)
```
with the CMakePresets.json:
```
{
...
"name": "default",
"generator": "Ninja Multi-Config",
"cacheVariables": {
"CMAKE_CONFIGURATION_TYPES": "Debug;Release"
}
...
}
```
when build Release with command:
```
cmake --build <path/to/bindir> --target libB --config Release
```
libA is also built and linked to by libB, which should not happen.
However, if "Visual Studio 16 2019" is used as the generator, libA is not built as expeted.https://gitlab.kitware.com/cmake/cmake/-/issues/24571Ninja: Mixing Swift in ObjC: "fatal error: 'ObjcSwiftNinja-Swift.h' file not ...2023-04-20T09:26:32-04:00CœurNinja: Mixing Swift in ObjC: "fatal error: 'ObjcSwiftNinja-Swift.h' file not found"While it works fine with Xcode, I seem unable to use Ninja to build a mixed ObjC+Swift project. I get:
```
/Users/User/Developer/ObjcSwiftNinja/MyObjC.m:2:9: fatal error: 'ObjcSwiftNinja-Swift.h' file not found
#import "ObjcSwiftNinja-Sw...While it works fine with Xcode, I seem unable to use Ninja to build a mixed ObjC+Swift project. I get:
```
/Users/User/Developer/ObjcSwiftNinja/MyObjC.m:2:9: fatal error: 'ObjcSwiftNinja-Swift.h' file not found
#import "ObjcSwiftNinja-Swift.h"
^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```
Minimal sample project: https://github.com/Coeur/ObjcSwiftNinja
The CMakeList.txt is as minimal as possible to highlight the issue:
https://github.com/Coeur/ObjcSwiftNinja/blob/97d926d454a8210731b42ddcc92c3a7fbc72ff9a/CMakeLists.txt
The README gives what works and what fails.
Succeeds:
```
cmake -B build -G Xcode
xcodebuild -project build/ObjcSwiftNinja.xcodeproj -target ObjcSwiftNinja-app
```
Fails:
```
cmake -B build -G Ninja
ninja -C build ObjcSwiftNinja-app
```
I've opened an issue at ninja, but they closed it and said it was a cmake issue: https://github.com/ninja-build/ninja/issues/2261https://gitlab.kitware.com/cmake/cmake/-/issues/24345Ninja: Builds using cross-workspace Ccache are broken for coverage since 3.21.x2023-02-14T10:30:12-05:00Dávid Péter JánosaNinja: Builds using cross-workspace Ccache are broken for coverage since 3.21.x**Use case:**
CCache is a compiler caching tool for C++ builds that drastically reduces build time by caching compiler artifacts and making them reusable across builds.
CCache is frequently used in CI/CD environments as it essentially...**Use case:**
CCache is a compiler caching tool for C++ builds that drastically reduces build time by caching compiler artifacts and making them reusable across builds.
CCache is frequently used in CI/CD environments as it essentially turns from scratch builds to incremental, speeding up builds by a factor of 5 to 10.
A compiler output frequently embeds paths of files and directories for various reasons like debugging or profiling (e.g. DW_AT_comp_dir or source file paths in gcno files).
This is an issue if we'd like to share CCache across build workspaces which are located in different folders (e.g. on a CI worker), however, with proper fine tuning, cross-workspace CCache is fully functional for debug and profile builds as well.
**Issue:**
Starting in CMake 3.21, Ninja generator for gcc no longer uses relative paths for specifying source file location in the gcc command line.
This was an intentional architectural change, see the issue and the release notes below.
However, this breaks cross-workspace compiler CCache, as gcno files created during profile builds are embedding source location using the path provided to the compiler upon compiling source files.
This makes gcno files containing absolute paths to the sources, hence making them unusable across workspaces (e.g. when generating coverage reports using gcovr).
**Possible fix:**
There could be an option to allow relative source file paths in ninja generated compiler command lines to retain the original functionality while making the current behavior default to address the issues which have motivated the change to begin with.
Would this align with the CMake architectural vision and be a welcomed change?
**References:**
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6148#note_1304536
https://cmake.org/cmake/help/latest/release/3.21.html
https://ccache.dev/https://gitlab.kitware.com/cmake/cmake/-/issues/24181std::out_of_range exception when adding to CMAKE_CONFIGURATION_TYPES list in ...2024-01-29T15:21:57-05:00rumgot rumgotovstd::out_of_range exception when adding to CMAKE_CONFIGURATION_TYPES list in subdirectory on Linux (Ubuntu 20.04)# std::out_of_range exception when adding to CMAKE_CONFIGURATION_TYPES list in subdirectory on Linux (Ubuntu 20.04)
When trying to add a new value to the **CMAKE_CONFIGURATION_TYPES** variable in a CMake subdirectory, it crashes with the...# std::out_of_range exception when adding to CMAKE_CONFIGURATION_TYPES list in subdirectory on Linux (Ubuntu 20.04)
When trying to add a new value to the **CMAKE_CONFIGURATION_TYPES** variable in a CMake subdirectory, it crashes with the error:
```
terminate called after throwing an instance of 'std::out_of_range'
what(): map::at
```
CMake was installed from the repository
`https://apt.kitware.com/ubuntu/ focal main`
I checked for the error on versions:
- **3.20.5-0kitware1ubuntu20.04.1**
- **3.23.2-0kitware1ubuntu20.04.1**
- **3.25.0-0kitware1ubuntu20.04.1**
Possibly other versions are affected as well.
To reproduce, you need to create a project with the following **CMakeLists.txt** file:
```cmake
cmake_minimum_required(VERSION 3.20)
project(CMakeBugList)
add_subdirectory(dir0)
```
Let's create a **dir0** subdirectory containing the following **CMakeLists.txt** file:
```cmake
set(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} SomeValue)
# or
# list(APPEND CMAKE_CONFIGURATION_TYPES SomeValue)
```
Now let's create a build directory and try to configure the project using the **Ninja Multi-Config** generator:
```bash
cmake ../CMakeBugList -G "Ninja Multi-Config"
-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /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: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
terminate called after throwing an instance of 'std::out_of_range'
what(): map::at
Aborted (core dumped)
```https://gitlab.kitware.com/cmake/cmake/-/issues/24113Ninja: Generate step performance very slow on Windows2024-02-03T04:38:57-05:00Michael JonesNinja: Generate step performance very slow on WindowsMy cmake project takes over 60 seconds to perform the generate step on Windows 10 with the Ninja generator, as well as the Ninja Multi-Config generator.
The same project takes roughly 5 seconds on a Linux machine.
I have corroborating ...My cmake project takes over 60 seconds to perform the generate step on Windows 10 with the Ninja generator, as well as the Ninja Multi-Config generator.
The same project takes roughly 5 seconds on a Linux machine.
I have corroborating reports from > 5 other developers in my organization seeing roughly the same numbers on their windows and linux machines.
Using the Visual Studio 2022 Performance profiling features, i was able to get a report claiming that >50% of the whole cmake.exe execution is spent inside of `cmNinjaTargetGenerator::WriteObjectBuiildStatement(...)`. when generating with the Ninja Multi-Config generator.
I profiled this with cmake-3.25.0-rc3 (https://github.com/Kitware/CMake/releases/download/v3.25.0-rc3/cmake-3.25.0-rc3.zip) with the "x64-RelWithDebugInfo" settings in the Visual Studio 2022 CMake project mode.
I added
```
add_link_options(LINKER:/PROFILE)
```
On line 16 of CMakeLists.txt, between
```
unset(CMAKE_USER_MAKE_RULES_OVERRIDE_C)
```
and
```
# FIXME: This block should go away after a transition period.
if(MSVC AND NOT CMAKE_VERSION VERSION_LESS 3.15)
```
Here's an attempt at copying out of the profiler. Unfortunately, Microsoft removed the feature that could be used to export the profiler data in a complete form, so this is the best i can do.
```
|Function Name|Total CPU \[unit, %\]|Self CPU \[unit, %\]|Module|Category|
|-|-|-|-|-|
| + cmake \(PID: 19448\)|39755 \(100.00%\)|213 \(0.54%\)|Multiple modules||
|\| + \[External Call\]
ntdll.dll!0x00007ffeac3c26a1|39492 \(99.34%\)|0 \(0.00%\)|ntdll|UI \| IO \| Kernel \| Security \| Runtime|
|\|\| + static int \_\_scrt\_common\_main\_seh\(\)|39491 \(99.34%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\| + main|39491 \(99.34%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\|\| + static int do\_cmake\(int, const char \* \*\)|39488 \(99.33%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\|\|\| + public: int \_\_cdecl cmake::Run\(class std::vector\<...\> const &,bool\)|39256 \(98.74%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\|\|\|\| + public: int \_\_cdecl cmake::Generate\(void\)|37121 \(93.37%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\|\|\|\|\| + protected: virtual void \_\_cdecl cmGlobalNinjaGenerator::Generate\(void\)|32640 \(82.10%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\|\|\|\|\|\| + public: virtual void \_\_cdecl cmGlobalGenerator::Generate\(void\)|32426 \(81.56%\)|1 \(0.00%\)|cmake|IO \| Kernel \| Security \| Runtime|
|\|\|\|\|\|\|\|\|\| + public: virtual void \_\_cdecl cmLocalNinjaGenerator::Generate\(void\)|30313 \(76.25%\)|2 \(0.01%\)|cmake|IO \| Kernel \| Runtime|
|\|\|\|\|\|\|\|\|\|\| + public: virtual void \_\_cdecl cmNinjaNormalTargetGenerator::Generate\(class std::basic\_string\<...\> const &\)|29515 \(74.24%\)|0 \(0.00%\)|cmake|IO \| Kernel \| Runtime|
|\|\|\|\|\|\|\|\|\|\|\| + protected: void \_\_cdecl cmNinjaTargetGenerator::WriteObjectBuildStatements\(class std::basic\_string\<...\> const &,class std::basic\_string\<...\> const &,bool\)|22011 \(55.37%\)|1 \(0.00%\)|cmake|IO \| Kernel \| Runtime|
|\|\|\|\|\|\|\|\|\|\|\|\| + protected: void \_\_cdecl cmNinjaTargetGenerator::WriteObjectBuildStatement\(class cmSourceFile const \*,class std::basic\_string\<...\> const &,class std::basic\_string\<...\> const &,bool\)|21403 \(53.84%\)|17 \(0.04%\)|cmake|IO \| Kernel \| Runtime|
|\|\|\|\|\|\|\|\|\|\|\|\|\| - public: void \_\_cdecl cmGlobalNinjaGenerator::WriteBuild\(class std::basic\_ostream\<...\> &,class cmNinjaBuild const &,int,bool \*\)|10526 \(26.48%\)|16 \(0.04%\)|cmake|IO \| Kernel \| Runtime|
|\|\|\|\|\|\|\|\|\|\|\|\|\| - protected: class std::basic\_string\<...\> \_\_cdecl cmNinjaTargetGenerator::ComputeFlagsForObject\(class cmSourceFile const \*,class std::basic\_string\<...\> const &,class std::basic\_string\<...\> const &\)|5503 \(13.84%\)|6 \(0.02%\)|cmake|Runtime|
```
This seems like it must be a particularly pathological edge-case in std::fstream, if I'm assuming correctly what the issue is.
Note that my cmake project is producing >50MB CMakeFiles/impl-Release.ninja and CMakeFiles/impl-Debug.ninja, so even if there's something really terrible about std::fstream, CMake is trying to generate a huge amount of data, which could be greatly reduced by making more aggressive use of Ninja's variable substitution features.https://gitlab.kitware.com/cmake/cmake/-/issues/23988Ninja: UTF-8 response files without BOM lead to build errors2022-09-22T14:30:56-04:00Sjard Ole KrügerNinja: UTF-8 response files without BOM lead to build errorsThe attached [example](/uploads/aae1fab9f65a06ee5528d0094e9a402d/test.zip) fails with Cmake 3.24.0, Ninja 1.11.0 and MSVC 2019 on a Windows 10 machine (sorry for the cluttered file structure, long paths was the only way I found to force ...The attached [example](/uploads/aae1fab9f65a06ee5528d0094e9a402d/test.zip) fails with Cmake 3.24.0, Ninja 1.11.0 and MSVC 2019 on a Windows 10 machine (sorry for the cluttered file structure, long paths was the only way I found to force cmake/ninja to generate a linker response file).
`LINK : fatal error LNK1181: cannot open input file 'in order to2\force cmake to\generate an rsp file\we will need\a very long path in order\to exceed the cli\argument length limit and\add some umlauts like\äöü\CMakeFiles\object.dir\addition\add_char.cpp.obj'
ninja: build stopped: subcommand failed.`
The problem seems to be closely related to #21792. If I add the BOM manually to **@CMakeFiles\component.rsp**, the linker statement is successful.https://gitlab.kitware.com/cmake/cmake/-/issues/23984XCTest Framework imported in Swift when using Ninja as generator2024-02-03T18:56:26-05:00Lars SundströmXCTest Framework imported in Swift when using Ninja as generatorI'm working on a project where we build a shared framework in Objective C/ C / C++.
The project is setup using CMake and this toolchain file https://github.com/leetal/ios-cmake to create libraries for different Apple devices.
Everything ...I'm working on a project where we build a shared framework in Objective C/ C / C++.
The project is setup using CMake and this toolchain file https://github.com/leetal/ios-cmake to create libraries for different Apple devices.
Everything works well building the library when using Xcode or Ninja as generator.
The framework is built as a module to be imported in a Swift application.
As a reference we're implementing unit tests of the framework in Swift to show the App team how to utilise it.
In CMakeLists we setup XCTest according to your instructions and if using Xcode as generator it works properly. All good there, but when using Ninja as generator a problem arises when linking the Swift test target due to:
```
error: cannot find 'XCTAssert' in scope
^~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCTestAssertions.h:72:9: note: macro 'XCTAssert' not imported: function like macros not supported
#define XCTAssert(expression, ...) \
error: cannot find 'XCTAssertNotNil' in scope
^~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCTestAssertions.h:63:9: note: macro 'XCTAssertNotNil' not imported: function like macros not supported
```
and so on. To be able to run the unit tests on the host machine I'm compiling the framework using Mac Catalyst support (the framework has a dependency to UIKit).
As seen above it looks like the Swift target is trying to use the XCTest framework instead of the XCTestSwiftSupport library. I've done some reading on this and found https://forums.swift.org/t/missing-libxctestswiftsupport-dylib/35314/8
Now I don't know what the Xcode property "Enable Testing Search Paths" does but either way it doesn't matter when using Ninja.
So in some way I would like the linker to use the XCTestSwiftSupport library instead. I've tried to modify the linker properties but without any luck, the Framework seems to be checked first.
Thanks for your fantastic work.https://gitlab.kitware.com/cmake/cmake/-/issues/23978Ninja: Optionally use powershell scripts instead of batch files for long cust...2022-09-20T13:03:08-04:00Nicholas PatellaNinja: Optionally use powershell scripts instead of batch files for long custom commandsHi, I'm using the latest CMake and ninja on Windows.
I notice that when a custom command is longer than 8192 characters, rather than be written directly to the build.ninja file, it's written to a .bat file.
I'm experiencing an issue wi...Hi, I'm using the latest CMake and ninja on Windows.
I notice that when a custom command is longer than 8192 characters, rather than be written directly to the build.ninja file, it's written to a .bat file.
I'm experiencing an issue with .bat files on a particular version of Windows that I am not sure if Microsoft will fix expediently (see Motivation).
It would be nice to have an option to be able to change the behavior of long commands to write to a PS script instead of a .bat script.
Since my arguments have generator expressions, I can't use file(WRITE).
For now, my solution is to write a PS script incrementally using multiple COMMANDs, and then finally calling that PS script, but it isn't ideal.
If CMake could support alternate ways to invoke long commands out of the box, it would be helpful.
<details><summary>Motivation</summary>
When working with add_custom_command and add_custom_target, CMake writes commands that would exceed the command line limit to a .bat file.
However, on Windows Server 2016, when executing a .bat file that contains a command longer 8192, while no error is thrown, the 8192th character is deleted from the command arguments during .bat execution, and the invoked program receives corrupt arguments. In CMake + ninja builds, the consequence is that when passing a long list of files to a custom command, one of the arguments or file paths will become corrupt.
A simple way to see this is to write:
`powershell.exe -Command "& { echo 123456789123456789 }" > output.txt`
to a .bat file, and modify the string echoed ("123456789123456789") to be longer than 8192 characters.
If you run this, you will see that output.txt is missing a character from what should have been echoed.
This issue only happens on Windows Server 2016 (I haven't tried 2019) and does not happen on the latest Windows 10 Pro.
Issue tracking on Microsoft's Feedback Hub (upvote would be appreciated):
https://aka.ms/AAi2pi7
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/23953Ninja: Add prefix/suffix variable for internal target names2022-09-19T17:50:50-04:00Klaus NeuschwanderNinja: Add prefix/suffix variable for internal target namesWhen combining multiple builds using `CMAKE_NINJA_OUTPUT_PATH_PREFIX` and including them with `subninja`, it can happen that both sub-builds can contain targets with the same name. When internal targets are generated (e.g. `cmake_object_...When combining multiple builds using `CMAKE_NINJA_OUTPUT_PATH_PREFIX` and including them with `subninja`, it can happen that both sub-builds can contain targets with the same name. When internal targets are generated (e.g. `cmake_object_order_depends_target_{target}`), those target definitions collide and the build can fail.
Therefore, I propose a variable, e.g. `CMAKE_INTERNAL_TARGET_PREFIX` which is added to all internal targets. This variable can then be set to different values for different invocations of CMake.
It may also be possible to use `CMAKE_NINJA_OUTPUT_PATH_PREFIX` for these targets as well, but I am not sure how well this plays with potential slashes in non-file targets.
See also https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296