CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-25T13:00:39-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25308Ninja: Swift: Remodeling Swift with separate object build and link steps2024-03-25T13:00:39-04:00Evan WildeNinja: Swift: Remodeling Swift with separate object build and link stepsI've started looking at re-doing how CMake models Swift compilations in the Ninja generator to match how CMake models other languages.
CMake usually breaks the build into two parts, the build that produces object files, and the link whic...I've started looking at re-doing how CMake models Swift compilations in the Ninja generator to match how CMake models other languages.
CMake usually breaks the build into two parts, the build that produces object files, and the link which builds the executable, shared library, or static archive.
```
┌───────────┐┌───────────┐
│ foo.c ││ bar.c │
└───────────┘└───────────┘
build │ │
▼ ▼
┌───────────┐┌───────────┐
│ foo.c.o ││ bar.c.o │
└───────────┘└───────────┘
│ │
link └──────┬─────┘
▼
┌────────────────────────┐
│ liblib.a │
└────────────────────────┘
```
Swift builds and links in one step. Swift source files are passed to the swift driver as though they were object files, along with any other object files in the target.
```
┌───────────┐ ┌───────────┐
│ foo.c │ │ foo.swift │
└───────────┘ └───────────┘
build │ │
▼ │
┌───────────┐ │
│ foo.c.o │ │ build/link
│ clang -c │ │
└───────────┘ │
│ │
└────────┬──────┘
▼
┌─────────────────────────────────┐
│ liblib.a │
│ swiftc -emit-library -static │
└─────────────────────────────────┘
```
While this works, it has several disadvantages. First, we can't get Swift object libraries because there are no object targets created.
Second, adding rules to `compile_commands.json` is done during the `WriteObjectStatement` step for the source file, so we don't get LSP support for Swift in CMake projects. The other issue figuring out where to generate headers for interop with other languages. Swift can generate C and C++ headers, but there isn't a place to tell the compiler to emit that header in this build graph, so projects have to explicitly add a separate call to the Swift compiler in a custom command to generate that header if they want to transparently mix C++ and Swift sources in a single library.
https://github.com/apple/swift-cmake-examples/blob/c5f6cfaf03d597c488a2efec0aa3b78e956c0d02/3_bidirectional_cxx_interop/cmake/modules/AddSwift.cmake#L12
The fix is to split the Swift model, from "linking" the Swift files to building the Swift files into objects, and then linking those into a library. We can emit swiftmodules, swift interface, and bridging headers (waiting on driver flags and not just frontend flags to emit the C++ bridging header before we can do that) during the Swift object build time. C and C++ libraries in the same target can then depend on those headers to use the exposed Swift functions.
```
┌───────────┐ ┌───────────┐ ┌───────────┐
│ foo.c │ │ foo.swift │ │ bar.swift │
└───────────┘ └───────────┘ └───────────┘
build │ │ │
│ └──────┬──────┘
▼ build ▼
┌───────────┐ ┌───────────────────────────┐
│ foo.c.o │ │┌───────────┐ ┌───────────┐│
│ clang -c │ ││foo.swift.o│ │bar.swift.o││
└───────────┘ │└───────────┘ └───────────┘│
│ │ swiftc -c │
│ └───────────────────────────┘
│ │
└──────────────┬───────┘
│ link
▼
┌────────────────────────────────────────────┐
│ liblib.a │
│ swiftc -emit-library -static │
└────────────────────────────────────────────┘
```
This is how Swift Package Manager and Xcode model Swift compilation as well. The whole-module-optimization [bug in the old driver](https://gitlab.kitware.com/cmake/cmake/-/issues/24641) is masked by this model. The WMO bug causes the old driver to pass all inputs to the swift-frontend invocation, so the frontend tries parsing static archives and objects, which doesn't work. In the split model, we only need to pass `-wmo` to the object build step, where the only inputs are Swift source files. The link step does not need `-wmo` so we can call `swiftc` without it and avoid trying to parse objects and static archives as source.
I have most of an [initial implementation working](https://gitlab.kitware.com/etcwilde/cmake/-/commit/66b93295f96a2f9f6f9412dd79fa0a04a5e8a1ee?view=parallel), but want to get opinions on the approach taken before doing the other half of the remaining work. The biggest question I have is about modeling units of work that span multiple files. The translation units in C/C++ only contain a single file (at least until C++ modules), so `WriteObjectBuildStatement` and may of the API it calls taking a single `cmSourceFile` works fine, but Swift modules (and swiftc invocations) take all of the source files in the module at once, so we need to pass all of the source files in the module into the object statement. CMake isn't really set up for this.
I created a `WriteSwiftObjectBuildStatement` function that is effectively `WriteObjectBuildStatement`, but takes a vector reference of source files instead of a single `cmSourceFile`:
```
void cmNinjaTargetGenerator::WriteSwiftObjectBuildStatement(
std::vector<cmSourceFile const*> const & sources,
std::string const &config,
std::string const &fileConfig,
bool firstForConfig);
```
Then the implementation mostly does what `WriteObjectBuildStatment` does, but separating the combined statement work from the per-file work. Unfortunately, the work is somewhat interleaved. Getting things like flags and module names is the same for all files since there is a single compiler invocation, but we have to collect separate output-file-map information for each file in the module, before emitting the single output-file-map for that module.
I can probably factor things a little better if we decide this is the right path, but wanted to get something mostly working first. I've seen work for dyndeps and C++ modules with multi-file modules/translation-units, so it might be interesting trying to align the two if it makes sense.
I look forward to hearing thoughts, improvements, and responses. Thanks.https://gitlab.kitware.com/cmake/cmake/-/issues/25366Swift: First-class support for modeling Swift compilation modes2024-03-25T12:58:42-04:00Evan WildeSwift: First-class support for modeling Swift compilation modesSwift has different compilation modes that affect how the compiler behaves, and can impact the generated build graph.
Under normal compilation, the driver will emit a single object file for each source file in the module.
Whole-Module-Op...Swift has different compilation modes that affect how the compiler behaves, and can impact the generated build graph.
Under normal compilation, the driver will emit a single object file for each source file in the module.
Whole-Module-Optimization (WMO) mode results in only a single object file for the entire module, changing the behavior of the build graph.
Currently, folks must force the `-wmo`/`-whole-module-optimization` flag through the various channels of smashing flags to the compiler, but this only really works with the Ninja generator at this time. The Xcode project format requires that wholemodule optimizations be specified via setting the `SWIFT_COMPILATION_MODE` attribute to `wholemodule` so that it can model the difference in behavior. Passing it via "other flags" to the Swift compiler will not work, so flag-smashing the compilation mode is not portable across generators.
At the moment, CMake sets WMO on non-debug builds on both the ninja and Xcode generator. The Xcode generator injects the attribute directly, while the ninja generator picks it up from `CMAKE_Swift_FLAGS_{appropriate config names}_INIT`. We should instead migrate at least WMO to a target property (potentially with some `CMAKE_Swift_COMPILATION_MODE` default cmake variable for folks who want a consistent mode applied wholesale when targets are created) that then can be checked inside of CMake more easily than trying to detect the flags at generation-time.
Currently, Xcode has `wholemodule` and `incremental` compilation modes reflected in the UI, though because Xcode only supports whole-module compilation and incremental compilation, and not single-file compilation, `incremental` is the default so there is no affect in the Xcode project file. The Ninja generator can represent all three states though. Do we want to represent enabling WMO as a boolean, or make it a string that takes `wholemodule`, `incremental`, and <blank> to represent each state? Given that CMake is already emitting the OFM for incremental builds, there isn't a terribly big difference between incremental and single-file, though someone may find a reason to need single-file.https://gitlab.kitware.com/cmake/cmake/-/issues/24864Running cmake twice on Windows after creating CMakePresets.json fails with ge...2024-03-25T07:53:51-04:00Gary OberbrunnerRunning cmake twice on Windows after creating CMakePresets.json fails with generator platform errorI'm working on the [OpenFX](https://github.com/AcademySoftwareFoundation/openfx) project, adding cmake and conan support.
The issue I'm facing is basically that running our conan+cmake build script twice fails the second time on Windows...I'm working on the [OpenFX](https://github.com/AcademySoftwareFoundation/openfx) project, adding cmake and conan support.
The issue I'm facing is basically that running our conan+cmake build script twice fails the second time on Windows.
Conan (1.59.0) creates a `CMakePresets.json` file like this:
```
% cat build/generators/CMakePresets.json
{
"version": 3,
"vendor": {
"conan": {}
},
"cmakeMinimumRequired": {
"major": 3,
"minor": 15,
"patch": 0
},
"configurePresets": [
{
"name": "default",
"displayName": "'default' config",
"description": "'default' configure using 'Visual Studio 17 2022' generator",
"generator": "Visual Studio 17 2022",
"cacheVariables": {
"CMAKE_POLICY_DEFAULT_CMP0091": "NEW"
},
"toolchainFile": "C:\\Users\\garyo\\src\\OpenFX\\build\\generators\\conan_toolchain.cmake",
"binaryDir": "C:\\Users\\garyo\\src\\OpenFX\\build"
}
],
...
```
and on the second run, without changing anything, we get this error from cmake:
```
+ cmake --preset default -DBUILD_EXAMPLE_PLUGINS=TRUE
Preset CMake variables:
CMAKE_POLICY_DEFAULT_CMP0091="NEW"
CMAKE_TOOLCHAIN_FILE:FILEPATH="C:\Users\garyo\src\OpenFX\build\generators\conan_toolchain.cmake"
CMake Error: Error: generator platform:
Does not match the platform used previously: x64
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
```
I notice that the `conan_toolchain.cmake` does define `set(CMAKE_GENERATOR_PLATFORM "x64" CACHE STRING "" FORCE)` but this is not enough to prevent the error. The only thing I have found that prevents the error is to manually add `configurePresets[0].architecture = "x64"` to the conan-generated toolchain file. But perhaps I'm missing something? You can check out the project at github at https://github.com/AcademySoftwareFoundation/openfx -- to repro on Windows, check out the `cmake` branch of that repo, use an msys shell, conan 1.59.0, cmake 3.23.0, and just run `scripts/build-cmake.sh` twice. The first time it will succeed, then the second time it will fail with the above error.
When I reported this as a conan issue (see [here](https://github.com/conan-io/conan/issues/13792), they suggested that this looks like a cmake bug (or at least an unexpected behavior) and I should report it here. I'm hoping you can help me figure out a workaround.3.29.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/16033WiX 4.x might require new XML namespace2024-03-24T15:25:38-04:00Kitware RobotWiX 4.x might require new XML namespaceThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16033). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16033). Further discussion may take place here.Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/24877RPATH_CHANGE fails for ELF files with more than 65536 sections2024-03-24T14:34:30-04:00Jürg BilleterRPATH_CHANGE fails for ELF files with more than 65536 sectionsCMake project to reproduce the issue
* [CMakeLists.txt](/uploads/3be34ff726396e984bacb3a9288aa124/CMakeLists.txt) (trivial C++ project that installs an executable)
* `main.cc`: Trivial `main` function + the output of
```sh
for i in `seq ...CMake project to reproduce the issue
* [CMakeLists.txt](/uploads/3be34ff726396e984bacb3a9288aa124/CMakeLists.txt) (trivial C++ project that installs an executable)
* `main.cc`: Trivial `main` function + the output of
```sh
for i in `seq 1 70000`; do
echo "int var_$i __attribute__((section(\"section_$i\"))) = $i;"
done
```
The shell script is from https://sourceware.org/bugzilla/show_bug.cgi?id=5900
Steps to reproduce:
* Configure project with `-DCMAKE_INSTALL_RPATH=/usr/lib`
* Build and install the project
Installation fails with:
```
Install the project...
-- Install configuration: ""
-- Installing: [...]/elftest
CMake Error at cmake_install.cmake:55 (file):
file RPATH_CHANGE could not write new RPATH:
/usr/lib
to the file:
[...]/elftest
No valid ELF RPATH or RUNPATH entry exists in the file;
```
The cause of this bug seems to be that `cmELF` doesn't support ELF files with more than 65536 sections as then the real section count is in the header of section 0, not in the ELF header. I.e., `cmELF` doesn't find any sections and thus, doesn't find the `RPATH` or `RUNPATH` entries even though they exist.
I've encountered this issue with a real world project that statically links to gRPC (and indirectly to abseil-cpp).https://gitlab.kitware.com/cmake/cmake/-/issues/25809try_compile() drops CMAKE_<LANG>_USING_LINKER_... vars where <LANG> has a hyp...2024-03-24T14:33:37-04:00Craig Scotttry_compile() drops CMAKE_<LANG>_USING_LINKER_... vars where <LANG> has a hyphen or underscoreThe regular expression used [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Source/cmCoreTryCompile.cxx?ref_type=tags#L1165-L1167) to decide what variables to pass to the try_compile() when `CMAKE_LINKER_TYPE` is defined is:...The regular expression used [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Source/cmCoreTryCompile.cxx?ref_type=tags#L1165-L1167) to decide what variables to pass to the try_compile() when `CMAKE_LINKER_TYPE` is defined is:
```
cmsys::RegularExpression linkerTypeDef{
"^CMAKE_[A-Za-z]+_USING_LINKER_"
};
```
This doesn't match the variables where the language is something like `ASM_NASM` or `ASM-ATT`. Underscores and hyphens need to be added to the `[...]` to allow such languages to be included.
We also have no test coverage for that particular `if()` block. It would be good to add a test to verify the expected variables do get passed down to the `try_compile()`.3.29.1Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/25805cmake (1) --toolchain relative to -S path and not in cwd2024-03-22T17:19:54-04:00scivisioncmake (1) --toolchain relative to -S path and not in cwdI think this bug existed since cmake(1) --toolchain feature was added, or at least in CMake 3.26 and 3.28 on Linux and Windows.
Expected: `cmake -S <src> --toolchain <path>` is not impacted by `<src>`.
Bug: the `--toolchain <path>` is ...I think this bug existed since cmake(1) --toolchain feature was added, or at least in CMake 3.26 and 3.28 on Linux and Windows.
Expected: `cmake -S <src> --toolchain <path>` is not impacted by `<src>`.
Bug: the `--toolchain <path>` is relative to `<src>` if <path> is not absolute and not in cwd.
Specifically these argument forms of `--toolchain` fail if `-S <src>` is specified not as `.` and toolchain file is not in cwd.
```sh
cmake -S anywhere --toolchain ./a/mytool.cmake
cmake -S anywhere --toolchain a/mytool.cmake
```
## works
If I am in a cwd such that the toolchain is at `../mytool.cmake` that works:
```sh
cmake -S anywhere --toolchain ../mytool.cmake
# if that is the relative path to mytool.cmake
```
This also works
```sh
cmake -S . --toolchain a/mytool.cmake
#or
cmake --toolchain a/mytool.cmake
```https://gitlab.kitware.com/cmake/cmake/-/issues/25812Feature request: CMake presets should make the build directory2024-03-22T14:37:31-04:00Farid ZakariaFeature request: CMake presets should make the build directoryI am migrating our codebase to CMakePresets which I am enjoying however it is weird that there is now this "unified" way to specify all the CMake arguments but you still have to create the build directory.
Should CMake do the `mkdir` f...I am migrating our codebase to CMakePresets which I am enjoying however it is weird that there is now this "unified" way to specify all the CMake arguments but you still have to create the build directory.
Should CMake do the `mkdir` for us when it's using CMakePresets?https://gitlab.kitware.com/cmake/cmake/-/issues/25808Incorrectly ordered dependency for imported target with Ninja generator2024-03-22T10:55:34-04:00ChardIncorrectly ordered dependency for imported target with Ninja generatorIf a dependency is added to an imported target then the _Ninja_ generator does not appear to wire up this dependency _before_ the dependency on the actual imported binary (`IMPORTED_LOCATION`).
This means if the binary itself depends o...If a dependency is added to an imported target then the _Ninja_ generator does not appear to wire up this dependency _before_ the dependency on the actual imported binary (`IMPORTED_LOCATION`).
This means if the binary itself depends on something then that does not get evaluated, resulting in a build failure.
There are many ways this could be caused, but the provided example reproduces the issue via a symbolic link to the imported library location.
Steps:
* Create a build (binary) dir.
* `cmake <path-to-example> -G Ninja` (configure)
* `ninja` (build)
* `rm indirection` (remove symlink)
* `ninja` (rebuild)
It can be seen in the _build.ninja_ file that the symlink dependency follows the imported library binary dependency.
The _GNU Makefiles_ generator does not have the same problem (the symlink is correctly re-created).
A workaround for the _Ninja_ generator is to wire up an extra explicit rule on the imported binary (provided in example).
[CMakeLists.txt](/uploads/869bdb619bb1ad14869c0a13c7651e64/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/24681CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_LIBRARIES doesn't work for Ninja2024-03-21T13:25:11-04:00mtribiereCMAKE_<LANG>_USE_RESPONSE_FILE_FOR_LIBRARIES doesn't work for NinjaConfiguration:
* Cross-compilation
* Ninja
* Gcc-like compiler
* Windows environment
* Gcc-like AR
Disabling `CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_LIBRARIES` won't work with Ninja and therefore link flags will still be outputted to the RS...Configuration:
* Cross-compilation
* Ninja
* Gcc-like compiler
* Windows environment
* Gcc-like AR
Disabling `CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_LIBRARIES` won't work with Ninja and therefore link flags will still be outputted to the RSP file.
Example:
```
set(CMAKE_C_USE_RESPONSE_FILE_FOR_LIBRARIES OFF)
```3.27.0https://gitlab.kitware.com/cmake/cmake/-/issues/25668fileapi: Provide CONFIGURE_DEPENDS glob verification info2024-03-21T09:29:04-04:00ArcticLampyridarcticlampyrid@outlook.comfileapi: Provide CONFIGURE_DEPENDS glob verification info## Problem Description
When using the CONFIGURE_DEPENDS flag in CMake to specify file globbing for source file lists, CMake automatically generates a VerifyGlobs.cmake file. This file is used to re-check the specified globs before each b...## Problem Description
When using the CONFIGURE_DEPENDS flag in CMake to specify file globbing for source file lists, CMake automatically generates a VerifyGlobs.cmake file. This file is used to re-check the specified globs before each build, allowing CMake to reconfigure the project automatically if any changes are detected in the globbed files. This feature ensures that the build system remains up-to-date with the project's files and directories structure.
However, this process poses a challenge for IDEs, particularly in terms of IntelliSense and other code navigation features. Currently, the information necessary for verifying globs is only available internally within CMake, with no official method for IDEs to access this information ahead of time. This limitation can hinder the IDE's ability to perform early reconfiguration, which is essential for maintaining accurate IntelliSense and code analysis features.
## Suggested Solution
To address this issue, it would be beneficial for CMake to provide an idiomatic way for IDEs to access glob verification information. One proposed method is to expose this information through CMake's File API. By making glob verification details accessible via the File API, IDEs could perform early reconfiguration based on the most current file and directory structures. This enhancement would significantly improve the development experience by ensuring that code navigation features remain accurate and up-to-date.
## Expected Benefits
- Improved accuracy of IntelliSense and other code analysis tools in IDEs.
- Enhanced developer experience by ensuring that project configurations are always up-to-date with the current state of the file system.
- Streamlined development process, reducing the need for manual project reconfiguration.
## Related Issue
This proposal is helpful to resolve [microsoft/vscode-cmake-tools#3558](https://github.com/microsoft/vscode-cmake-tools/issues/3558).https://gitlab.kitware.com/cmake/cmake/-/issues/25566FindSWIG prefers swig4.0 (or in general swig<swigmajorversion>.0) named execu...2024-03-21T09:28:20-04:00Silvio TraversaroFindSWIG prefers swig4.0 (or in general swig<swigmajorversion>.0) named executables over swig named executablesIf you are in an Debian system, and in the system the `swig` package is installed, and if you are running a CMake script with `find_package(SWIG REQUIRED)` in a conda environment with both `cmake` and `swig` installed, the `SWIG_EXECUTAB...If you are in an Debian system, and in the system the `swig` package is installed, and if you are running a CMake script with `find_package(SWIG REQUIRED)` in a conda environment with both `cmake` and `swig` installed, the `SWIG_EXECUTABLE` found by CMake will be `/usr/bin/swig4.0` instead of the expected `$CONDA_PREFIX/bin/swig`, even if `which swig` returns `$CONDA_PREFIX/bin/swig`.
Similarly, if you install vanilla swig from source, and you install it in a path that you prepend to the `/usr/bin` system path (for example `/opt/newswig`), `which swig` will return `/opt/newswig/bin/swig`, but CMake's `find_package(SWIG REQUIRED)` will continue to find `/usr/bin/swig4.0` .
I guess something similar could happen with spack or conan swig packages when using them on an apt system, but I did not tried.
This happens as CMake prefers executables called `swig<pkgmajorversion>.0` (like `swig4.0`) over executables called `swig`, and the debian packaging installs `swig4.0`, while conda-forge packaging only installs `swig`, see the line `find_program(SWIG_EXECUTABLE NAMES ${_SWIG_NAMES} swig)` (https://github.com/Kitware/CMake/blob/v3.28.1/Modules/FindSWIG.cmake#L89).
Strictly speaking this is not a swig packaging issue, but rather an unexpected interaction between CMake, SWIG and the respective conda-forge and Debian packaging. However, I was quite confused by this, so I thought that it was useful to document it somewhere.
From what I understand, the symlink `swig<swigmajorversion>.0` is something that is not done by SWIG's buildsystem upstream, but rather a packaging details of Debian distributions. Indeed, if you check for example Fedora (https://packages.fedoraproject.org/pkgs/swig/swig/fedora-rawhide.html#files) or arch (https://archlinux.org/packages/extra/x86_64/swig/), they both only install `swig`.
For this reason, I would expect that CMake's FindSWIG would look first for `swig`, and only as a fallback for `swig<swigmajorversion>.0`. However, this would be technically a breaking change, so I am not sure how to handle that.https://gitlab.kitware.com/cmake/cmake/-/issues/25801ctest: modifying PATH via ENVIRONMENT property2024-03-21T09:21:59-04:00b1an b1anctest: modifying PATH via ENVIRONMENT propertycmake does not pass env to program correctly in a test case. The original report is in [VS developemnt community](https://developercommunity.visualstudio.com/t/CMake-cmake-does-not-pass-env-to-progr/10620955). Full test project is [test....cmake does not pass env to program correctly in a test case. The original report is in [VS developemnt community](https://developercommunity.visualstudio.com/t/CMake-cmake-does-not-pass-env-to-progr/10620955). Full test project is [test.zip](/uploads/f08e83e3587b6b2dcb6ca94fe9c4edc9/test.zip).https://gitlab.kitware.com/cmake/cmake/-/issues/25363`BUILD_RPATH` is not properly set when environment variable contains `LIBRARY...2024-03-21T06:29:09-04:00Cristian Le`BUILD_RPATH` is not properly set when environment variable contains `LIBRARY_PATH`As the title suggest, I've had an instance where I have imported libraries from `pkg-config`, using `gcc 10.3.0`+`ninja 1.11.1`+`cmake 3.26.3`, but for some reason after the linking stage, the `RPATH` is missing (after the build, before ...As the title suggest, I've had an instance where I have imported libraries from `pkg-config`, using `gcc 10.3.0`+`ninja 1.11.1`+`cmake 3.26.3`, but for some reason after the linking stage, the `RPATH` is missing (after the build, before the install). If I unset `LIBRARY_PATH`, the `RPATH` is correctly added.https://gitlab.kitware.com/cmake/cmake/-/issues/25792Ninja+Fortran: Module dependency not detected from INCLUDEd file2024-03-20T09:55:55-04:00Brad KingNinja+Fortran: Module dependency not detected from INCLUDEd fileConsider this example with a module dependency inside a file included by the Fortran `INCLUDE` directive:
```console
$ cat CMakeLists.txt
cmake_minimum_required (VERSION 3.26)
project(Example Fortran)
add_executable(main main.f90 foo.f9...Consider this example with a module dependency inside a file included by the Fortran `INCLUDE` directive:
```console
$ cat CMakeLists.txt
cmake_minimum_required (VERSION 3.26)
project(Example Fortran)
add_executable(main main.f90 foo.f90)
$ cat main.f90
include "included.f90"
program main
!use foo ! uncomment to work around
call included_subroutine
end program
$ cat included.f90
subroutine included_subroutine
use foo
call foo_subroutine
end subroutine
$ cat foo.f90
module foo
contains
subroutine foo_subroutine
print *, "Hello World!"
end subroutine
end module
```
The dependency of `main.f90.o` on `foo.mod` is not discovered unless the work around is uncommented:
```console
$ ninja CMakeFiles/main.dir/main.f90.o
...
Fatal Error: Cannot open module file ‘foo.mod’ for reading at (1): No such file or directory
```3.28.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25780Handling CMAKE_OSX_ARCHITECTURES being set to $(ARCHS_STANDARD) in generate_a...2024-03-20T09:51:51-04:00Craig ScottHandling CMAKE_OSX_ARCHITECTURES being set to $(ARCHS_STANDARD) in generate_apple_architecture_selection_file()The implementation and documentation for `generate_apple_architecture_selection_file()` both assume `CMAKE_OSX_ARCHITECTURES` lists specific architectures, but a common practice when using the Xcode generator is to give it the special va...The implementation and documentation for `generate_apple_architecture_selection_file()` both assume `CMAKE_OSX_ARCHITECTURES` lists specific architectures, but a common practice when using the Xcode generator is to give it the special value `$(ARCHS_STANDARD)`. This lets Xcode handle the set of architectures to build for, which is handy when performing an archive operation with xcodebuild. On the surface, it would seem that `generate_apple_architecture_selection_file()` doesn't handle a value like `$(ARCHS_STANDARD)`, and the comments in #25516 seem to dismiss supporting such a value. But I'm wondering if it would work if `$(ARCHS_STANDARD)` was listed as one of the single architectures? This feels like an abuse of knowledge of the implementation details, but maybe this suggests a way we could formally support `$(ARCHS_STANDARD)` as a special case when using the Xcode generator. I'd expect the include file for such a special value would probably map to the same one as `UNIVERSAL_INCLUDE_FILE`, but that's just a guess on my part, so we shouldn't assume that.
The documentation also makes no mention of cases where `CMAKE_OSX_ARCHITECTURES` might hold a special value like `$(ARCHS_STANDARD)`. While we don't currently mention `$(ARCHS_STANDARD)` anywhere else in the docs, I think that in this case, it is going to be relevant and common enough that we probably should explicitly document it and how to handle it. `$(ARCHS_STANDARD)` is essentially what Xcode uses by default when you create a new project in the Xcode IDE outside of CMake. With the recently added XCFramework support in CMake, plus the functionality added to CMakePackageHelpers in CMake 3.29, CMake projects might finally be able to start using `find_package()` and have it actually work for multi-architecture builds with the Xcode generator.
If we choose not to support `$(ARCHS_STANDARD)` in `generate_apple_architecture_selection_file()`, the documentation should be updated to explicitly mention that.3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25778Generated apple platform and architecture selection files must not raise fata...2024-03-20T09:51:50-04:00Craig ScottGenerated apple platform and architecture selection files must not raise fatal errorsCMake 3.29 is adding new `generate_apple_platform_selection_file()` and `generate_apple_architecture_selection_file()` commands to the `CMakePackageConfigHelpers` module. Both of these commands are aimed at creating files that would be u...CMake 3.29 is adding new `generate_apple_platform_selection_file()` and `generate_apple_architecture_selection_file()` commands to the `CMakePackageConfigHelpers` module. Both of these commands are aimed at creating files that would be used as part of a `<package>-config.cmake` file. Both commands generate files that can raise fatal errors, but that shouldn't be done from any `<package>-config.cmake` file if the error relates to something that package expects to be available or set, but isn't. What should happen is that the package sets `${CMAKE_FIND_PACKAGE_NAME}_FOUND` to false, `${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE` to an appropriate error message, and then it returns to the caller. The `find_package()` implementation should be able to move on to trying other locations and looking for other package config files.
The `ApplePlatformSelection.cmake.in` template will raise a fatal error if it encounters a `CMAKE_SYSTEM_NAME` it doesn't recognise. If Apple release a new platform in the future, and a project tries to build for it, the mere presence of a package generated with CMake 3.29 would cause that project's configure to fail, even if there was a newer package available somewhere which did understand the new platform.
The `AppleArchitectureSelection.cmake.in` template will raise a fatal error if `CMAKE_OSX_ARCHITECTURES` is not set, or if it is not one of the architectures listed in the `SINGLE_ARCHITECTURES` argument given to `generate_apple_architecture_selection_file()`. This has the same problem as for the platform above. If Apple comes out with a new architecture, the mere presence of a package generated with CMake 3.29 would again prevent a project that targets the new architecture from configuring.3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25779Wrong argument type for some generate_apple_architecture_selection_file() key...2024-03-20T09:51:50-04:00Craig ScottWrong argument type for some generate_apple_architecture_selection_file() keywordsThe implementation of `generate_apple_architecture_selection_file()` defines all of its keywords as single-value keywords, but `SINGLE_ARCHITECTURES`, `SINGLE_ARCHITECTURE_INCLUDE_FILES`, and `UNIVERSAL_ARCHITECTURES` are all multi-value...The implementation of `generate_apple_architecture_selection_file()` defines all of its keywords as single-value keywords, but `SINGLE_ARCHITECTURES`, `SINGLE_ARCHITECTURE_INCLUDE_FILES`, and `UNIVERSAL_ARCHITECTURES` are all multi-value keywords.3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25785(re)running cmake with ninja and clang-cl triggers ninja error about FindFirs...2024-03-20T09:34:38-04:00risa2000(re)running cmake with ninja and clang-cl triggers ninja error about FindFirstFileExA (possible regression)It seems the problem resurfaced in Visual Studio 17.8.5 with cmake version 3.27.2-msvc1 and still remains there in VS 17.9.3 with cmake version 3.28.0-msvc1.
When having a CMake project configured with ninja generator and with clang-cl ...It seems the problem resurfaced in Visual Studio 17.8.5 with cmake version 3.27.2-msvc1 and still remains there in VS 17.9.3 with cmake version 3.28.0-msvc1.
When having a CMake project configured with ninja generator and with clang-cl as a C/C++ compiler, cmake/ninja would trigger an error:
_ninja : error : FindFirstFileExA(Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared): The filename, directory name, or volume label syntax is incorrect._
I have first reported it on VS community forum here: https://developercommunity.visualstudio.com/t/rerunning-cmake-with-ninja-and-clang-c/10567377 and with the help from MS we concluded that it is not problem in clang or visual studio, but possibly in cmake. This problem is triggered with a new clang-cl (v18 built from LLVM master branch), but not with the one currently shipped with the VS (clang-cl v16.0.5)
Code to reproduce the problem is attached to this post. In order to reproduce it you need conan package manager (1.x) installed - I am using conan 1.62.0
To execute cmake correctly on the project, you need to create the conan “install” folder first, by running the batch file conan\\conan_install_all.cmd (run this from top level project dir as prescribed here, the paths to conan profiles are hardcoded there).
Then run CMake cache generation from VS IDE the usual way. You can do this for “native” MS cl compiler and for clang-cl compiler. Once the cache for clang-cl is generated and build the first time, the subsequent builds fail with the error. The only way to continue is to delete and regenerate the cache completely.
The same build with MS cl compiler works alright.
I already tested that one needs to use conan generated toolchain file for CMake. Building it without one does not trigger the error. Also when you remove the resource file main.rc from the build, it will pass all right.
[cmake_test.zip](/uploads/44f0ffe9ab3e84e165993bdbf4fb4191/cmake_test.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/25753cpack fails with FindFirstFileExA error after upgrade to LLVM 18.1.02024-03-20T09:34:38-04:00Alexey Rochevcpack fails with FindFirstFileExA error after upgrade to LLVM 18.1.0In my CI job (GitHub Actions) that uses clang-cl on Windows, `package` target started failing with following error:
```
ninja: error: FindFirstFileExA(Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621...In my CI job (GitHub Actions) that uses clang-cl on Windows, `package` target started failing with following error:
```
ninja: error: FindFirstFileExA(Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared): The filename, directory name, or volume label syntax is incorrect.
```
I use Ninja Multi-Config generator, and `CPACK_GENERATOR` is `ZIP;WIX`.
The only major change compared to previously successful jobs was LLVM upgrade - from 17.0.6 to 18.1.0.
CMake version is 3.28.3.