CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-20T09:34:36-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25799Ninja: Detection of msvc_deps_prefix for clang-cl 18.12024-03-20T09:34:36-04:00Michael H.Ninja: Detection of msvc_deps_prefix for clang-cl 18.1Environment: MS Windows 11 cmake version: 3.26 - 3.28
During a build of llvm-project (version 18.1.1) using the Ninja generator and using the clang compilers (CMAKE_C_COMPILER": "clang-cl", "CMAKE_CXX_COMPILER": "clang-cl") I got the fo...Environment: MS Windows 11 cmake version: 3.26 - 3.28
During a build of llvm-project (version 18.1.1) using the Ninja generator and using the clang compilers (CMAKE_C_COMPILER": "clang-cl", "CMAKE_CXX_COMPILER": "clang-cl") I got the following error:
```
[main] Building folder: llvm-project
[build] Starting build
[proc] Executing command: ...\local\bin\cmake.EXE --build D:/temp/llvm-project/hbexbuild/x64 --parallel 32 --target install
[build] ninja: error: FindFirstFileExA(Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared): Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
[build]
[proc] The command: ...\local\bin\cmake.EXE --build D:/temp/llvm-project/hbexbuild/x64 --parallel 32 --target install exited with code: 1
[driver] Build completed: 00:00:01.174
[build] Build finished with exit code 1
```
It tracked this down to
```
...
tools/llvm-config/ExtensionDependencies.inc
tools/llvm-config/LibraryDependencies.inc
projects/openmp/runtime/src/CMakeFiles/omp.dir/libomp.rc.res: #deps 17, deps mtime 7322090345723586 (VALID)
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/sdv_driverspecs.h
Note: including file: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/includ/concurrencysal.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/driverspecs.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/winpackagefamily.h
Note: including file: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/includesal.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/SpecStrings.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/shared/winapifamily.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/verrsrc.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/commctrl.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/dde.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/dlgs.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winnt.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winuser.rh
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winver.h
Note: including file: D:/temp/llvm-project/openmp/runtime/src/kmp_platform.h
Note: including file: C:/Program Files (x86)/Windows Kits/10/include/10.0.22621.0/um/winresrc.h
Note: including file: D:/temp/llvm-project/hbexbuild/x64/projects/openmp/runtime/src/kmp_config.h
...
```
using `ninja -t deps`.
The reason for the problem is that `msvc_deps_prefix` detection failed. The detection of the prefix is done with a regular expression inside of `Modules\CMakeDetermineCompilerId.cmake`. I found the following deficiencies with the regular expression:
1. It is not documented and not understandable without documentation
2. It is wrong and unnecessary complex (the second part of this statement is also true for the 3.29.0-rc4.
I here provide a patch against 3.28.3 which solves 1. and 2.
[fix_msvc_deps_prefix-3.28.3-new.patch](/uploads/390769b92a81a8f649eb4e3043476a00/fix_msvc_deps_prefix-3.28.3-new.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/18141while(TRUE) doesn't warn where if(TRUE) would2024-03-20T09:31:10-04:00Adriaan de Grootwhile(TRUE) doesn't warn where if(TRUE) wouldConsider this CMakeLists.txt:
```
cmake_minimum_required(VERSION 2.6)
while(TRUE)
message(STATUS "While true")
break()
endwhile()
if(TRUE)
message(STATUS "If true")
endif()
```
This uses the old, and deprecated, setting for polic...Consider this CMakeLists.txt:
```
cmake_minimum_required(VERSION 2.6)
while(TRUE)
message(STATUS "While true")
break()
endwhile()
if(TRUE)
message(STATUS "If true")
endif()
```
This uses the old, and deprecated, setting for policy CMP0012. That means that TRUE isn't recognized as a Boolean truthy value, and so neither the while, nor the if, block is entered. Output is (after the language checking):
```
CMake Warning (dev) at CMakeLists.txt:6 (if):
if given arguments:
"TRUE"
An argument named "TRUE" appears in a conditional statement. Policy
CMP0012 is not set: if() recognizes numbers and boolean constants. Run
"cmake --help-policy CMP0012" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
```
The while doesn't trigger this warning, although the if does -- even though both are evaluating boolean contexts. That's a very minor inconsistency.https://gitlab.kitware.com/cmake/cmake/-/issues/15555Ninja: Object file compilation unconditionally depends on artifacts of depend...2024-03-19T15:11:53-04:00Kitware RobotNinja: Object file compilation unconditionally depends on artifacts of dependenciesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15555). Further discussion may take place here.
---
When the Ninja generator generates targets for .cc files, it adds dependenci...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15555). Further discussion may take place here.
---
When the Ninja generator generates targets for .cc files, it adds dependencies on any libraries that their target depend on. This means that in a parallel build, ninja won't start building any .cc files from one library until all depended-upon libraries have been built -- an unnecessary restriction. The only requirement should be that a target cannot be _linked_ until its required libraries are built.
This severely limits build parallelism in large projects. I manually post-processed a build.ninja file from a medium-size C++ project to remove these dependencies, and a parallel build using icecc on a small cluster was reduced from 1m30s to 1m0s. Looking at a Gantt chart of the build, I could see that all of the cluster cores were kept occupied much better after the fix, especially at the start of the build.
Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25788Fortran+Ninja: add_dependencies does not make modules available since CMake 3.282024-03-19T15:11:52-04:00scivisionFortran+Ninja: add_dependencies does not make modules available since CMake 3.28As noted by https://gitlab.kitware.com/cmake/cmake/-/issues/25425#note_1496770
```sh
git clone https://github.com/Goddard-Fortran-Ecosystem/pFUnit
# for reference I was on commit 10e99ef99
cmake -Bbuild -G Ninja
cmake --build build -...As noted by https://gitlab.kitware.com/cmake/cmake/-/issues/25425#note_1496770
```sh
git clone https://github.com/Goddard-Fortran-Ecosystem/pFUnit
# for reference I was on commit 10e99ef99
cmake -Bbuild -G Ninja
cmake --build build -t funit
```
issue happens with / without `-j1` or `-t` options, even repeatedly trying to build.
This example was with macOS, CMake 3.28.3, Ninja 1.11.1, and Gfortran 13.
This target is defined in "src/funit/CMakeLists.txt" and "src/funit/asserts/CMakeLists.txt" as target "asserts" OBJECT library
```
FAILED: src/funit/CMakeFiles/funit-main.dir/FUnit.F90.o src/funit/mod/funit.mod
/opt/homebrew/bin/gfortran-13 -IpFUnit/src/funit -IpFUnit/build/src/funit/mod -IpFUnit/include -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1 -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/src/v1/mod -IpFUnit/build/extern/fArgParse/mod -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v2 -IpFUnit/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v2 -IpFUnit/build/extern/fArgParse/extern/gFTL-shared/src/v2/mod -g -cpp -O0 -ffree-line-length-none -fallow-argument-mismatch -fbacktrace -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -Jsrc/funit/mod -fPIC -fdiagnostics-color=always -fopenmp -fpreprocessed -c src/funit/CMakeFiles/funit-main.dir/FUnit.F90-pp.f90 -o src/funit/CMakeFiles/funit-main.dir/FUnit.F90.o
pFUnit/src/funit/FUnit.F90:4:8:
4 | use PF_Assert
| 1
Fatal Error: Cannot open module file 'pf_assert.mod' for reading at (1): No such file or directory
```https://gitlab.kitware.com/cmake/cmake/-/issues/25795Add cmake.exe to Path on Windows by default2024-03-19T14:47:47-04:00Nazar MokrynskyiAdd cmake.exe to Path on Windows by defaultOriginally reported at https://github.com/chocolatey-community/chocolatey-packages/issues/2442, but turned up to be the default upstream behavior of MSI installer.
Please consider adding `cmake.exe` to `Path` in default installation, su...Originally reported at https://github.com/chocolatey-community/chocolatey-packages/issues/2442, but turned up to be the default upstream behavior of MSI installer.
Please consider adding `cmake.exe` to `Path` in default installation, such that users can use it right away.https://gitlab.kitware.com/cmake/cmake/-/issues/25789Makefiles: Odd behavior with rebuild_cache attached to stdout2024-03-19T03:24:42-04:00Mathieu MalaterreMakefiles: Odd behavior with rebuild_cache attached to stdoutConsider the following CMakeLists.txt:
```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
project(p)
execute_process(COMMAND ${CMAKE_COMMAND}
-P ${CMAKE_CURRENT_SOURCE_DIR}/demo.cmake
ERROR_VARIABLE my_VERSION)
message("1...Consider the following CMakeLists.txt:
```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
project(p)
execute_process(COMMAND ${CMAKE_COMMAND}
-P ${CMAKE_CURRENT_SOURCE_DIR}/demo.cmake
ERROR_VARIABLE my_VERSION)
message("1: ${my_VERSION}")
string(REPLACE "." ";" my_VERSION_LIST "${my_VERSION}")
list(GET my_VERSION_LIST 0 my_VERSION_MAJOR)
list(GET my_VERSION_LIST 1 my_VERSION_MINOR)
list(GET my_VERSION_LIST 2 my_VERSION_PATCH)
message("2: ${my_VERSION_MAJOR}")
```
where:
```
$ cat demo.cmake
set(GIT_VERSION 1.2.3)
message("${GIT_VERSION}")
```
Here is what I see from my Ubuntu system:
```
$ cmake .. && echo "-- done ---" && make rebuild_cache
1: 1.2.3
2: 1
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/demo/bin
-- done ---
Running CMake to regenerate build system...
1: 1.2.3
CMake Error at CMakeLists.txt:9 (list):
list index: 1 out of range (-1, 0)
CMake Error at CMakeLists.txt:10 (list):
list index: 2 out of range (-1, 0)
2: 1;2;3
-- Configuring incomplete, errors occurred!
See also "/tmp/demo/bin/CMakeFiles/CMakeOutput.log".
make: *** [Makefile:81: rebuild_cache] Error 1
```
However using a file output:
```
$ cmake .. && echo "-- done ---" && make rebuild_cache >& /tmp/my.log && echo "this time ok"
1: 1.2.3
2: 1
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/demo/bin
-- done ---
this time ok
```
Using:
```
$ cmake --version
cmake version 3.22.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```
and
```
$ make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
```https://gitlab.kitware.com/cmake/cmake/-/issues/25425Ninja: 3.27 regresses Fortran module dependencies with parallel execution2024-03-18T19:20:05-04:00Igor S. GerasimovNinja: 3.27 regresses Fortran module dependencies with parallel executionI have tried to compile xtb project [https://github.com/grimme-lab/xtb]. Unfortunately, there still are issues with compilation after !8974 which was included into cmake 3.28.0-rc5.
Steps to reproduce (will use GCC):
```
wget https://gi...I have tried to compile xtb project [https://github.com/grimme-lab/xtb]. Unfortunately, there still are issues with compilation after !8974 which was included into cmake 3.28.0-rc5.
Steps to reproduce (will use GCC):
```
wget https://github.com/Kitware/CMake/releases/download/v3.28.0-rc5/cmake-3.28.0-rc5-linux-x86_64.sh
wget https://github.com/grimme-lab/xtb/archive/refs/tags/v6.6.1.tar.gz
bash cmake-3.28.0-rc5-linux-x86_64.sh --skip-license
tar -xzvf v6.6.1.tar.gz
cd xtb-6.6.1
../bin/cmake -G"Ninja" -Bbuild -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
ninja -C build
```
Note, in my case, ninja runs ~100 command simultaneously.
With 3.28.0-rc4, cmake was failed on configure stage. Now, with 3.28.0-rc5, compilation fails due to improper dependency list, so one will receive messages like:
```
xtb/src/prog/argparser.f90:20:8:
20 | use xtb_mctc_accuracy, only : wp
| 1
Fatal Error: Cannot open module file 'xtb_mctc_accuracy.mod' for reading at (1): No such file or directory
```
Re-running ninja in parallel mode multiple times leads to success compilation. Like:
```
for i in `seq 1 100`
do
ninja -C build
done
```
Running ninja in single thread mode compiles xtb project successfully from the first run.
I failed to create a minimal reproducible example to notice such behaviour not in a real project.3.27.9Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25732cxxmodules: Incorrect object filename from $<TARGET_OBJECTS:tgt> with MSVC2024-03-18T10:18:29-04:00Alex Rieglercxxmodules: Incorrect object filename from $<TARGET_OBJECTS:tgt> with MSVCThe value returned from `$<TARGET_OBJECTS:tgt>` is incorrect when compiling an object library consisting of only a C++ module with MSVC.
This causes issues with linking module libraries since the obj file of the target library will have...The value returned from `$<TARGET_OBJECTS:tgt>` is incorrect when compiling an object library consisting of only a C++ module with MSVC.
This causes issues with linking module libraries since the obj file of the target library will have an unexpected name.
# Minimal reproduction:
[CMakeLists.txt](/uploads/091b7ed63583e5b3451c9e6cf40bb191/CMakeLists.txt)
[foo.ixx](/uploads/847c47239795ad8a8b6c682baebd983f/foo.ixx)
# System info
Visual Studio 17 2022
MSVC 19.40.33521.0
MSBuild version 17.10.0-preview-24081-01+97651a25d for .NET Framework
CMake version 3.29.0-rc2https://gitlab.kitware.com/cmake/cmake/-/issues/25781cmake doesn't find custom llvm2024-03-18T10:14:08-04:00Ivan Sučićcmake doesn't find custom llvm<!--
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/
-->
I built a custom llvm and it isn't found with cmake. Here are the detailed steps:
1. clone custom llvm repo and switch to branch release/17.x
2. build custom llvm and install it with cmake --build . --target install
3. add to env variable LLVMInstallDir the path to install of custom llvm.
4. please DELETE/UNINSTALL llvm shiped with visual studio
5. try to build the llvm with custom llvm and cmake reports that it can’t find llvm.https://gitlab.kitware.com/cmake/cmake/-/issues/25786'ARGN' prints empty on command line console2024-03-17T17:27:06-04:00Nihal Agarwal'ARGN' prints empty on command line consoleCmake 3.22.1
For the following code:
```
set(TEMP_VAR "It is a temp varaible 1")
set(TEMP_VAR2 "It is a temp varaible 2")
function( fn_name var var2 )
message( "${var} value is = ${${var}}" )
message( "${var2} value is = ${${var2}}" )
...Cmake 3.22.1
For the following code:
```
set(TEMP_VAR "It is a temp varaible 1")
set(TEMP_VAR2 "It is a temp varaible 2")
function( fn_name var var2 )
message( "${var} value is = ${${var}}" )
message( "${var2} value is = ${${var2}}" )
message( "ARGN: ${ARGN}" ) # all variable name
message( "ARGC: ${ARGC}" )
message( "ARG0: ${ARGV0}" )
message( "ARG1: ${ARGV1}" )
endfunction()```
fn_name(TEMP_VAR TEMP_VAR2)
```
I am getting following output:
```
TEMP_VAR value is = It is a temp varaible 1
TEMP_VAR2 value is = It is a temp varaible 2
ARGN:
ARGC: 2
ARG0: TEMP_VAR
ARG1: TEMP_VAR2
```
So, the **ARGN** is printed as empty, but when I removed the parameters from the function signature, the ARGN prints the expected result.
```
set(TEMP_VAR "It is a temp varaible 1")
set(TEMP_VAR2 "It is a temp varaible 2")
function( fn_name )
message( "ARGN: ${ARGN}" ) # all variable name
message( "ARGC: ${ARGC}" )
message( "ARG0: ${ARGV0}" )
message( "ARG1: ${ARGV1}" )
endfunction()
fn_name(TEMP_VAR TEMP_VAR2)
```
Output:
```
ARGN: TEMP_VAR;TEMP_VAR2
ARGC: 2
ARG0: TEMP_VAR
ARG1: TEMP_VAR2
```
as I didn't find info from the Documentation. It looks like a bug for me.https://gitlab.kitware.com/cmake/cmake/-/issues/25783android ndk toolchain Could not find a package configuration file provided by...2024-03-16T02:58:08-04:00guijiyangandroid ndk toolchain Could not find a package configuration file provided by "fmt" on windows osI try to use cmake android ndk toolchain to build spdlog, as I set CMAKE_PREFIX_PATH to path where fmt-config.cmake is located,it failed to find package of fmt.
cmakelists.txt
```cmake
set(CMAKE_PREFIX_PATH "F:/packages/f/fmt/10.2.1/7de...I try to use cmake android ndk toolchain to build spdlog, as I set CMAKE_PREFIX_PATH to path where fmt-config.cmake is located,it failed to find package of fmt.
cmakelists.txt
```cmake
set(CMAKE_PREFIX_PATH "F:/packages/f/fmt/10.2.1/7def98216fe149a88a59c825d35870c7/lib/cmake/fmt")
if(SPDLOG_FMT_EXTERNAL OR SPDLOG_FMT_EXTERNAL_HO)
if(NOT TARGET fmt::fmt)
message(STATUS "CMAKE_PREFIX_PATH: ${CMAKE_PREFIX_PATH}")
find_package(fmt CONFIG REQUIRED)
endif()
```
directory:
```powershell
PS D:\Code\OtherProject\cxx\spdlog> ls F:\packages\f\fmt\10.2.1\7def98216fe149a88a59c825d35870c7\lib\cmake\fmt\
directory: F:\packages\f\fmt\10.2.1\7def98216fe149a88a59c825d35870c7\lib\cmake\fmt
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2024/3/15 20:34 1900 fmt-config-version.cmake
-a---- 2024/3/15 20:34 1030 fmt-config.cmake
-a---- 2024/3/15 20:34 826 fmt-targets-release.cmake
-a---- 2024/3/15 20:34 4493 fmt-targets.cmake
```
output:
```log
[main] 正在配置项目: spdlog
[proc] 执行命令: "D:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DSPDLOG_FMT_EXTERNAL=ON -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=26 -DANDROID_STL=c++_shared -DSPDLOG_BUILD_TESTS=OFF -DSPDLOG_BUILD_SHARED=OFF -DSPDLOG_USE_STD_FORMAT=OFF -DSPDLOG_FMT_EXTERNAL_HO=OFF -DANDROID_USE_LEGACY_TOOLCHAIN_FILE=FALSE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_TOOLCHAIN_FILE:FILEPATH=D:/android-ndk-r26b/build/cmake/android.toolchain.cmake -SD:/Code/OtherProject/cxx/spdlog -Bd:/Code/OtherProject/cxx/spdlog/cmakebuild -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Android: Targeting API '26' with architecture 'arm64', ABI 'arm64-v8a', and processor 'aarch64'
[cmake] -- Android: Selected unified Clang toolchain
[cmake] -- The CXX compiler identification is Clang 17.0.2
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: D:/android-ndk-r26b/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] -- Build spdlog: 1.13.0
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
[cmake] -- Looking for pthread_create in pthreads
[cmake] -- Looking for pthread_create in pthreads - not found
[cmake] -- Looking for pthread_create in pthread
[cmake] -- Looking for pthread_create in pthread - not found
[cmake] -- Check if compiler accepts -pthread
[cmake] -- Check if compiler accepts -pthread - yes
[cmake] -- Found Threads: TRUE
[cmake] -- Build type: Debug
[cmake] -- CMAKE_PREFIX_PATH: F:/packages/f/fmt/10.2.1/7def98216fe149a88a59c825d35870c7/lib/cmake/fmt
[cmake] CMake Error at CMakeLists.txt:215 (find_package):
[cmake] Could not find a package configuration file provided by "fmt" with any of
[cmake] the following names:
[cmake]
[cmake] fmtConfig.cmake
[cmake] fmt-config.cmake
[cmake]
[cmake] Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set "fmt_DIR"
[cmake] to a directory containing one of the above files. If "fmt" provides a
[cmake] separate development package or SDK, be sure it has been installed.
[cmake]
```https://gitlab.kitware.com/cmake/cmake/-/issues/25516Apple: generate_apple_platform_selection_file per-architecture dispatch2024-03-15T01:36:07-04:00Brad KingApple: generate_apple_platform_selection_file per-architecture dispatchSplitting discussion out of https://gitlab.kitware.com/cmake/cmake/-/issues/25262#note_1444954, in which @alcroito wrote:
> The limitation is that the generated file differentiates only based on platform name, but not on architecture.
...Splitting discussion out of https://gitlab.kitware.com/cmake/cmake/-/issues/25262#note_1444954, in which @alcroito wrote:
> The limitation is that the generated file differentiates only based on platform name, but not on architecture.
> That means that different architecture object files need to be `lipo`-ed into one file per platform before they can be used with the platform selection file.
> In principle that's not a problem, I confirmed it's possible to do.
> But it gets a bit weird if each architecture build is done separately.
>
> Taking `iOS` as an example, I do 3 builds: `iphoneos sdk + arm64`, `iphonesimulator sdk + x86_64`, `iphonesimulator sdk + arm64`.
> The object files are installed in the following locations:
> ```
> $CMAKE_INSTALL_PREFIX1/lib/obj/lib/iphonesimulator-arm64/objects-Release/mytgt/obj1.cpp.o
> $CMAKE_INSTALL_PREFIX2/lib/obj/lib/iphonesimulator-x86_64/objects-Release/mytgt/obj1.cpp.o
> $CMAKE_INSTALL_PREFIX3/lib/obj/lib/iphoneos-arm64/objects-Release/mytgt/obj1.cpp.o
> ```
> I also generate `mytgtTargets.cmake` files for each of those, and they specify the `IMPORTED_OBJECTS_RELEASE` properties with the paths above.
>
> Now if i want to move those into an `xcframework`-ified SDK, and use the `generate_apple_platform_selection_file` file to select between them, i need to first `lipo` the `iphonesimulator-arm64` and `iphonesimulator-x86_64` and keep one of the two file paths, to keep the generated paths in `mytgtTargets.cmake` valid.
>
> The file path on disk will thus not reflect the reality of the file actually containing 2 architectures.
>
> You could say, don't add the architecture to the directory name when doing the per-arch builds, and i guess that's one way around the confusion, but you'd still need the extra `lipo`-ing of the object files.
>
> So I was thinking if we could avoid the need for the `lipo`-ing object files entirely, and also keep the platform+arch specific names, by changing `generate_apple_platform_selection_file` to optionally accommodate for architecture as well.
>
> Perhaps something like
> ```cmake
> generate_apple_platform_selection_file("${platform_selection_path}"
> INSTALL_DESTINATION "${dest}"
>
> MACOS_CONFIG_FILE "lib/macos/cmake/mylib/mylib-targets.cmake"
>
> IOS_ARCHITECTURES "arm64"
> IOS_CONFIG_FILES "lib/iphoneos/cmake/mylib/mylib-targets.cmake"
>
> IOS_SIMULATOR_ARCHITECTURES "arm64;x86_64"
> IOS_SIMULATOR_CONFIG_FILES "lib/iphonesimulator-arm64/cmake/mylib/mylib-targets.cmake;lib/iphonesimulator-x86_64/cmake/mylib/mylib-targets.cmake"
> IOS_SIMULATOR_CONFIG_FILE "lib/iphonesimulator/cmake/mylib/mylib-targets.cmake"
>
> )
> ```
> where path 0 of the `CONFIG_FILES` would be chosen if current `CMAKE_OSX_ARCHITECTURES` == value 0 of given `ARCHITECTURES` option, same with 1, and a fallback to the singular `CONFIG_FILE`.
Also, in https://gitlab.kitware.com/cmake/cmake/-/issues/25262#note_1445714, @alcroito wrote:
> > When I say "platforms", I consider iOS and iOS Simulator to be different platforms.
>
> Same.
>
> > Are you trying to `lipo` together iOS and iOS Simulator builds? That doesn't make sense to me.
>
> No. Sorry about the confusion. No lipo-ing of simulator and device builds.
> In fact, I'd like to avoid lipo-ing of the object files entirely.
>
> > Within the same platform, I would still expect to be able to set `CMAKE_OSX_ARCHITECTURES` to all the arches you want to build for on that platform, and be able to have the same compile definitions and such.
>
> 99% the that's the case, but talking about simulator arm64 vs x86_64, in Qt code we sometimes need to pass different compile definitions to different arches for example in code related to JIT-ing (because that's what the 3rd party code expects).
>
> That's why i want to avoid passing 2 architectures to `CMAKE_OSX_ARCHITECTURES`, as well as avoid lipo-ing due the file path confusion and all the extra complexity that comes with it, for little gain.3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25765Makefile: Missing CD command for text-based stubs rule for Apple2024-03-14T13:31:22-04:00Simon Märtensgit@slmaertens.devMakefile: Missing CD command for text-based stubs rule for Apple<!--
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/
-->
Hi,
when I'm using the Makefile generator on macOS, the rule that generates the text-based stubs for my shared library is missing a `CD` command which results in the `tapi` command failing because it can't find the shared library.
Makefile contents:
```Makefile
lib/libnag_kernel_shared.dylib: components/kernel/core/CMakeFiles/nag_kernel_shared.dir/link.txt
@$(CMAKE_COMMAND) -E cmake_echo_color "--switch=$(COLOR)" --green --bold --progress-dir=/Users/simonm/git/modular-library/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Linking Fortran shared library ../../../lib/libnag_kernel_shared.dylib"
cd /Users/simonm/git/modular-library/build/components/kernel/core && $(CMAKE_COMMAND) -E cmake_link_script CMakeFiles/nag_kernel_shared.dir/link.txt --verbose=$(VERBOSE)
lib/libnag_kernel_shared.tbd: lib/libnag_kernel_shared.dylib
/Library/Developer/CommandLineTools/usr/bin/tapi stubify -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk -o ../../../lib/libnag_kernel_shared.tbd ../../../lib/libnag_kernel_shared.dylib
```
Terminal output from `make -j1 VERBOSE=1`:
```
[ 13%] Linking Fortran shared library ../../../lib/libnag_kernel_shared.dylib
cd /Users/simonm/git/modular-library/build/components/kernel/core && /opt/homebrew/Cellar/cmake/3.28.3/bin/cmake -E cmake_link_script CMakeFiles/nag_kernel_shared.dir/link.txt --verbose=1
/opt/homebrew/bin/gfortran-13 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk -dynamiclib -Wl,-headerpad_max_install_names -o ../../../lib/libnag_kernel_shared.dylib -install_name @rpath/libnag_kernel_shared.dylib ../getcons/CMakeFiles/nag_engine_consts.dir/modules/nag_core_consts.f90.o CMakeFiles/nag_kernel_mods.dir/modules/nag_core_data_consts.f90.o CMakeFiles/nag_kernel_mods.dir/modules/nag_core_data_type.f90.o CMakeFiles/nag_kernel_mods.dir/modules/nag_core_enum_consts.f90.o
/Library/Developer/CommandLineTools/usr/bin/tapi stubify -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk -o ../../../lib/libnag_kernel_shared.tbd ../../../lib/libnag_kernel_shared.dylib
error: no such file or directory: '../../../lib/libnag_kernel_shared.dylib'
```
The library exists and if I run the command manually from the correct directory, it works.
___
Possible solution:
In `cmMakefileLibraryTargetGenerator.cxx:973` we create the command:
```C++
// Add rule to generate text-based stubs, if required
if (this->GeneratorTarget->IsApple() &&
this->GeneratorTarget->HasImportLibrary(this->GetConfigName())) {
auto genStubsRule =
this->Makefile->GetDefinition("CMAKE_CREATE_TEXT_STUBS");
cmList genStubs_commands{ genStubsRule };
```
and if I add the following it works as expected:
```C++
// Add rule to generate text-based stubs, if required
if (this->GeneratorTarget->IsApple() &&
this->GeneratorTarget->HasImportLibrary(this->GetConfigName())) {
auto genStubsRule =
this->Makefile->GetDefinition("CMAKE_CREATE_TEXT_STUBS");
cmList genStubs_commands{ genStubsRule };
this->LocalGenerator->CreateCDCommand(
genStubs_commands, this->Makefile->GetCurrentBinaryDirectory(),
this->LocalGenerator->GetBinaryDirectory());
```
I'm not sure if that is the correct place to add the CD command or if I'm missing something else. I'm happy to create a MR if this is an acceptable solution.
Best,
Simon3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25766Autogen: Imported library's location become target's autogen_timestamp_deps?2024-03-14T11:46:58-04:00Ratchanan SrirattanametAutogen: Imported library's location become target's autogen_timestamp_deps?The CMakeLists.txt attached below contains 1 imported static library ("built" by custom command's `BYPRODUCTS`) and 2 executables. Both executables depend on the imported library, but only `test2` executable have `CMAKE_AUTOMOC` enabled....The CMakeLists.txt attached below contains 1 imported static library ("built" by custom command's `BYPRODUCTS`) and 2 executables. Both executables depend on the imported library, but only `test2` executable have `CMAKE_AUTOMOC` enabled. When building with `make -j14`, following error occurred:
```
make[2]: *** No rule to make target 'libgtest.a', needed by 'CMakeFiles/test2_autogen_timestamp_deps'. Stop
make[1]: *** [CMakeFiles/Makefile2:168: CMakeFiles/test2_autogen_timestamp_deps.dir/all] Error 2
```
By deeper inspection, it's found that `libgtest.a` is depended on by `test2_autogen_timestamp_deps.dir/build.make`, but `Makefile2` doesn't add a dependency from `test2_autogen_timestamp_deps.dir/all` to `GTest.dir/all` where the lib is actually "built".
Now, if I move the `BYPRODUCTS` to the outer level custom target, CMake does add the dependency to `GTest.dir/all` in `Makefile2`. But in our project, these steps are actually added by `ExternalProject` and I don't have any idea on how we can influence the `BYPRODUCTS` of the top-level custom target (or any `STEP_TARGETS` it creates).
And, if I read the doc correctly, `autogen_timestamp_deps` is supposed to be used for `moc`, but I don't think a static library have anything to do with that. So I don't think this is an intended behavior?
Tested with CMake 3.28.3 and 3.29.0-rc3.
---
```
cmake_minimum_required(VERSION 3.5.0)
project(automoc-and-imported-lib VERSION 0.0 LANGUAGES CXX)
find_package(Qt5 COMPONENTS Core)
# Can be any random static lib on your system
set(a_static_lib /usr/lib/x86_64-linux-gnu/libgtest.a)
# In our project, this is ExternalProject_Add(). Imagine this is the build step...
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/fakeBuildGTest
COMMAND cp ${a_static_lib} ${CMAKE_CURRENT_BINARY_DIR}/libgtest.a
BYPRODUCTS ${CMAKE_CURRENT_BINARY_DIR}/libgtest.a)
# ...which gets pulled in by the custom target.
add_custom_target(GTest DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/fakeBuildGTest)
add_library(gtest STATIC IMPORTED)
set_property(TARGET gtest PROPERTY IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/libgtest.a)
add_dependencies(gtest GTest)
write_file(test.cpp "int main() { return 0; }")
add_executable(test1 test.cpp)
target_link_libraries(test1 gtest)
set(CMAKE_AUTOMOC ON)
add_executable(test2 test.cpp)
target_link_libraries(test2 gtest)
```3.28.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25748Flags for mold with GCC only work for GCC 12.1 and later2024-03-14T11:45:18-04:00Craig ScottFlags for mold with GCC only work for GCC 12.1 and laterCMake 3.29 is introducing direct support for linker selection through the `LINKER_TYPE` target property and `CMAKE_LINKER_TYPE` CMake variable.
The file at `Modules/Platform/Linux-GNU.cmake` unilaterally sets `CMAKE_${lang}_USING_LINKER...CMake 3.29 is introducing direct support for linker selection through the `LINKER_TYPE` target property and `CMAKE_LINKER_TYPE` CMake variable.
The file at `Modules/Platform/Linux-GNU.cmake` unilaterally sets `CMAKE_${lang}_USING_LINKER_MOLD` to `-fuse-ld=mold`. But according to the README for mold:
>* For Clang: pass -fuse-ld=mold
>
>* For GCC 12.1.0 or later: pass `-fuse-ld=mold`
>
>* For GCC before 12.1.0: the `-fuse-ld` option does not accept `mold` as a valid argument, so you need to use the `-B` option instead. The `-B` option tells GCC where to look for external commands like `ld`.
>
>If you have installed mold with `make install`, there should be a directory named `/usr/libexec/mold` (or `/usr/local/libexec/mold`, depending on your `$PREFIX`), and the `ld` command should be there. The `ld` is actually a symlink to `mold`. So, all you need is to pass `-B/usr/libexec/mold` (or `-B/usr/local/libexec/mold`) to GCC.
>
>If you haven't installed `ld.mold` to any `$PATH`, you can still pass `-fuse-ld=/absolute/path/to/mold` to clang to use mold. However, GCC does not accept an absolute path as an argument for `-fuse-ld`.
I've included the parts for Clang in the above because Clang on Linux uses the same platform files as GCC, so it gets the same definitions for `CMAKE_${lang}_USING_LINKER_MOLD`.
It looks like we really need to be checking the GCC version and using the most appropriate flag for that version. The added complication of whether or not `ld.mold` is on the PATH probably should also be considered. We could just document that it must be on the PATH rather than resorting to passing an absolute path with `-fuse-ld=...`. That would simplify the logic and make things a bit more consistent between how we would treat GCC and Clang.
CC: @marc.chevrier3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25758FetchContent_MakeAvailable() leaks __cmake_original_export_find_package_name ...2024-03-14T11:44:07-04:00Craig ScottFetchContent_MakeAvailable() leaks __cmake_original_export_find_package_name variableThe change in !8957 added blocks like the following to the `FetchContent_MakeAvailable()` implementation:
```cmake
list(APPEND __cmake_fcCurrentVarsStack "__fcprefix__${CMAKE_EXPORT_FIND_PACKAGE_NAME}")
set(CMAKE_EXPORT_...The change in !8957 added blocks like the following to the `FetchContent_MakeAvailable()` implementation:
```cmake
list(APPEND __cmake_fcCurrentVarsStack "__fcprefix__${CMAKE_EXPORT_FIND_PACKAGE_NAME}")
set(CMAKE_EXPORT_FIND_PACKAGE_NAME "${__cmake_contentName}")
```
followed later by something like:
```cmake
list(POP_BACK __cmake_fcCurrentVarsStack __cmake_original_export_find_package_name)
string(SUBSTRING "${__cmake_original_export_find_package_name}"
12 -1 __cmake_original_export_find_package_name
)
set(CMAKE_EXPORT_FIND_PACKAGE_NAME ${__cmake_original_export_find_package_name})
```
The second of the above blocks is also sometimes before or after a bunch of `unset()` calls intended to prevent leaking any temporary local variables to the calling scope, but `__cmake_original_export_find_package_name` is never unset. Therefore, it leaks out to the `FetchContent_MakeAvailable()` caller. If we keep the existing code, we should ensure we unset this variable too, just like the other temporary local variables.
The above pattern is more complicated than it needs to be though. There's actually no need for the `__fcprefix__` at all. The only place where that is needed is when pushing the very first variable of the command's implementation, to ensure that an empty `__cmake_fcCurrentVarsStack` variable upon entry still results in something being pushed. We know we don't have an empty `__cmake_fcCurrentVarsStack` stack whenever we need to push `CMAKE_EXPORT_FIND_PACKAGE_NAME` though, and pushing an empty value onto a non-empty stack will always push at least a semicolon. Therefore, we don't even need the temporary `__cmake_original_export_find_package_name` variable in the above blocks. We can operate on `CMAKE_EXPORT_FIND_PACKAGE_NAME` directly:
```cmake
list(APPEND __cmake_fcCurrentVarsStack "${CMAKE_EXPORT_FIND_PACKAGE_NAME}")
```
followed later by:
```cmake
list(POP_BACK __cmake_fcCurrentVarsStack CMAKE_EXPORT_FIND_PACKAGE_NAME)
```
Both the current code and the above suggested improvement suffer from not exactly preserving `CMAKE_EXPORT_FIND_PACKAGE_NAME` though. The existing code will leave `CMAKE_EXPORT_FIND_PACKAGE_NAME` undefined if it was explicitly set to an empty value before, and the suggested improved code above has the opposite problem of leaving `CMAKE_EXPORT_FIND_PACKAGE_NAME` defined to an empty string where it may have been undefined before. Currently, the way this variable affects the `EXPORT_FIND_PACKAGE_NAME` target property means this distinction doesn't affect the behavior right now, but ideally we would preserve the exact variable in case a future change makes a distinction between `CMAKE_EXPORT_FIND_PACKAGE_NAME` being undefined and it being defined but empty.
CC: @kyle.edwards3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25764FindPython3: add support for Python3_FIND_ABI under Windows2024-03-14T09:18:35-04:00LE GARREC VincentFindPython3: add support for Python3_FIND_ABI under WindowsDocumentation says : "So, on Windows systems, when Python3_FIND_ABI is defined, Python distributions from python.org will be found only if value for each flag is OFF or ANY."
I tried to implement a workaround because I need to have pyde...Documentation says : "So, on Windows systems, when Python3_FIND_ABI is defined, Python distributions from python.org will be found only if value for each flag is OFF or ANY."
I tried to implement a workaround because I need to have pydebug to use pybind11 in Debug mode : [Windows Python with Debug Libraries Installed causes linker error](https://github.com/pybind/pybind11/issues/3403)
List of problems I found :
- If I set `Python3_FIND_ABI(ON ANY ANY)`, `Python3_FIND_UNVERSIONED_NAMES` search `python` instead of `pythond` / `python_d`.
- `sys.abiflags` doesn't work for Windows. So don't try to read `sys.abiflags` to check if an interpreter is good. Also don't update `Python3_ABIFLAGS` when interpreter has been checked.
- `Changed in version 3.8: Default flags became an empty string (m flag for pymalloc has been removed).
` [System-specific parameters and functions](https://docs.python.org/3/library/sys.html). I didn't do any change about this change.https://gitlab.kitware.com/cmake/cmake/-/issues/23392ctest: Make "jobs" argument in "ctest --parallel <jobs>" optional2024-03-14T08:58:28-04:00Benjamin Buchctest: Make "jobs" argument in "ctest --parallel <jobs>" optionalCurrently `cmake` has a command line parameter `parallel` with automatic processor count guessing:
```
--parallel [<jobs>], -j [<jobs>]
```
- from https://cmake.org/cmake/help/v3.23/manual/cmake.1.html
On the other hand, with `ctest` ...Currently `cmake` has a command line parameter `parallel` with automatic processor count guessing:
```
--parallel [<jobs>], -j [<jobs>]
```
- from https://cmake.org/cmake/help/v3.23/manual/cmake.1.html
On the other hand, with `ctest` you always need to define the processor count:
```
-j <jobs>, --parallel <jobs>
```
- from https://cmake.org/cmake/help/v3.23/manual/ctest.1.html
This is an asynchrony in the interfaces. It is especially problematic since `ctest --parallel` is executed without complaint if the `jobs` argument is missing. While `cmake` uses all processor cores in this case, `ctest` uses only one core, so it ignores the parameter.3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/21677AUTOMOC: add depfile support for Makefiles2024-03-13T09:43:04-04:00Jörg BornemannAUTOMOC: add depfile support for MakefilesSince aebfbcaa4650ec6f540cc53b96d44cdfb87d82a1 AUTOMOC can use moc-generated depfiles for
- Qt >= 5.15
- and the Ninja generators
Now that !5617 is merged, we can add support for the Makefile generator too.
This issue serves as a to do ...Since aebfbcaa4650ec6f540cc53b96d44cdfb87d82a1 AUTOMOC can use moc-generated depfiles for
- Qt >= 5.15
- and the Ninja generators
Now that !5617 is merged, we can add support for the Makefile generator too.
This issue serves as a to do item.Jörg BornemannJörg Bornemannhttps://gitlab.kitware.com/cmake/cmake/-/issues/25600Autogen: 3.28 regresses some dependencies with Unix Makefiles generator2024-03-13T07:07:41-04:00Sam VanheerAutogen: 3.28 regresses some dependencies with Unix Makefiles generatorEDIT: See discussion at https://gitlab.kitware.com/cmake/cmake/-/issues/25600#note_1469954 for a more direct description of the problem after initial analysis.
---
In CMake 3.28.1 using the Makefile generator, when you have a target th...EDIT: See discussion at https://gitlab.kitware.com/cmake/cmake/-/issues/25600#note_1469954 for a more direct description of the problem after initial analysis.
---
In CMake 3.28.1 using the Makefile generator, when you have a target that uses Qt's AUTOMOC as well as a file generated by `add_custom_target` and the target being defined is in a subdirectory relative to the generated file running `make` fails with `no rule to make target`.
This seems to be because the generated filename in the `_autogen_timestamp_deps.dir/build.make` file is missing the directory part of the filename.
A minimal reproduction of this bug can be found here: https://github.com/SamVanheer/CMakeGeneratedFileBug
Uncommenting the `add_executable` command in the root `CMakeLists.txt` and commenting out the one in the `src` directory causes it to compile just fine. Note that you'll need to delete the generated header file to test the initial configuration again.
The filenames listed in `build.make` are:
```
src/CMakeFiles/Exe_autogen_timestamp_deps: ProjectInfo.hpp
src/CMakeFiles/Exe_autogen_timestamp_deps: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.15.3
src/CMakeFiles/Exe_autogen_timestamp_deps: /usr/lib/qt5/bin/moc
```
As you can see it's missing the directory.
Note that Qt does not need to be linked to for this to happen. As long as AUTOMOC is enabled and a valid Qt dependency has been found this will occur.
I encountered this in my own project in Github Actions before reproducing it locally using 3.28.1: https://github.com/SamVanheer/HalfLifeAssetManager/actions/runs/7533460940/job/20507360222
The problem does not appear to happen on Windows so this is probably only happening in the Makefile generator, but I have not tested other generators.3.28.2Orkun TokdemirOrkun Tokdemir