CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-01-30T16:36:45-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25362ctest: Parsing files from `TEST_INCLUDE_FILES` is very limited2024-01-30T16:36:45-05:00Cristian Lectest: Parsing files from `TEST_INCLUDE_FILES` is very limited## Example usage
I am trying to insert test property `PROCESSORS` to be run appropriately at runtime to account for both `OMP_NUM_THREADS` and `MPI_EXEC` parallelization. This needs to count dynamically as `${OMP_NUM_THREADS:-1} * ${tes...## Example usage
I am trying to insert test property `PROCESSORS` to be run appropriately at runtime to account for both `OMP_NUM_THREADS` and `MPI_EXEC` parallelization. This needs to count dynamically as `${OMP_NUM_THREADS:-1} * ${test_mpi_np}`, where `test_mpi_np` is taken from each test's property that were previously parsed from the test file. The key issue here is that `OMP_NUM_THREADS` can vary between configure and `ctest` execution
## Issues encountered
In designing this, I've encountered numerous issues:
- `get_property` or `get_test_property` does not work with `get_property given TEST name that does not exist`
- `TEST_INCLUDE_FILES` prepends the includes, while in this case I want to append these commands to add to all of the known tests in the current directory
- CMake functionality in general appears very limited, would `math` even work in such caseshttps://gitlab.kitware.com/cmake/cmake/-/issues/25360FEATURE: a new approach for linker configuration2023-11-29T10:41:05-05:00Marc ChevrierFEATURE: a new approach for linker configurationWith the recent evolutions ( !8861 and !8885) regarding linker selection and identification, it seems judicious to make independent the linker configuration from the compiler one.
For a large part, various linkers, on a given platform, ...With the recent evolutions ( !8861 and !8885) regarding linker selection and identification, it seems judicious to make independent the linker configuration from the compiler one.
For a large part, various linkers, on a given platform, offers a good compatibility with each other, but this compatibility is not complete. For example, on Apple, to treat all warnings as errors (see #25343), the Apple linker has option `-fatal_warnings` but the linkers `LLVM LLD` or `MOLD` have option `--fatal-warnings`. So, today, there is no infrastructure to handle these differences.
For that purpose, I propose to introduce a set of files, dedicated to linker configuration, in a layout similar to the one used currently for the compiler configuration:
```cmake
# directory for linker configuration independant from the platform
Modules/Linker
## GNU linker configuration
Modules/Linker/GNU.cmake
## GNU Linker used by C compiler
Modules/Linker/GNU-C.cmake
# directory for linker configuration dependant from the platform
Modules/Platform/Linker
## Linux GNU linker configuration
Modules/Platform/Linker/Linux-GNU.cmake
## Linux GNU Linker used by C compiler
Modules/Plaform/Linker/Linux-GNU-C.cmake
## Default platform linker used by C compiler
Modules/Plaform/Linker/Linux-C.cmake
```
And the `ID` will be provided by the `CMAKE_<LANG>_COMPILER_LINKER_ID` variable (see !8885). When this variable is not defined, a fall-back to the default platform linker is managed (this the assumption used currently): in the example provided, the file `Modules/Platform/Linker/Linux-C.cmake` will be used.
And we will have, for example, for the platform:
* File `Modules/Platform/Linker/Linux-GNU.cmake`
```cmake
macro(__linux_linker_gnu lang)
...
endmacro()
```
* file `Modules/Platform/Linker/Linux-GNU-C.cmake`
```cmake
include(Platform/Linker/Linux-GNU)
__linux_linker_gnu(C)
```
* file `Modules/Platform/Linker/Linux-C.cmake`
```cmake
# default linker on Linux is GNU
include(Platform/Linker/Linux-GNU-C)
```https://gitlab.kitware.com/cmake/cmake/-/issues/25359FindDoxygen: No option for doxygen_add_docs() to specify USES_TERMINAL or JOB...2023-10-24T08:13:36-04:00Anthony AlayoFindDoxygen: No option for doxygen_add_docs() to specify USES_TERMINAL or JOB_POOL consoleHey there,
Thank you for an amazing product. I just tried out `doxygen_add_docs()` today:
https://github.com/Kitware/CMake/blob/master/Modules/FindDoxygen.cmake#L869
and it was quite evidence that nothing got printed to screen until e...Hey there,
Thank you for an amazing product. I just tried out `doxygen_add_docs()` today:
https://github.com/Kitware/CMake/blob/master/Modules/FindDoxygen.cmake#L869
and it was quite evidence that nothing got printed to screen until everything was already finished.
It would be great to have a visual indicator of progress. Could an option for `USES_TERMINAL` or `JOB_POOL console` be added for that purpose? That could be passed to the underlying `add_custom_command` .
Thanks,
Anthonyhttps://gitlab.kitware.com/cmake/cmake/-/issues/25358find_package(HDF5 1.8 COMPONENTS C HL REQUIRED) fails to find hdf5-1.12.22023-10-23T20:58:17-04:00yurivictfind_package(HDF5 1.8 COMPONENTS C HL REQUIRED) fails to find hdf5-1.12.2This script fails:
```
cmake_minimum_required(VERSION 3.0)
find_package(HDF5 1.8 COMPONENTS C HL REQUIRED)
```
Error:
```
-- Unable to determine HDF5 C flags from HDF5 wrapper.
CMake Error at /usr/local/share/cmake/Modules/FindPackageH...This script fails:
```
cmake_minimum_required(VERSION 3.0)
find_package(HDF5 1.8 COMPONENTS C HL REQUIRED)
```
Error:
```
-- Unable to determine HDF5 C flags from HDF5 wrapper.
CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_HL_LIBRARIES) (found
suitable version "1.12.2", minimum required is "1.8")
Call Stack (most recent call first):
/usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake/Modules/FindHDF5.cmake:1001 (find_package_handle_standard_args)
CMakeLists.txt:5 (find_package)
```
When the "1.8" version requirement is removed - find_package succeeds.
cmake-core-3.26.1
FreeBSD 13.2https://gitlab.kitware.com/cmake/cmake/-/issues/25356Evaluate using Profile-Guided Optimization (PGO) and LLVM BOLT for CMake2023-10-22T08:00:15-04:00Alexander ZaitsevEvaluate using Profile-Guided Optimization (PGO) and LLVM BOLT for CMakeHi!
Recently I checked Profile-Guided Optimization (PGO) improvements on multiple projects. The results are [here](https://github.com/zamazan4ik/awesome-pgo/). E.g. PGO results for LLVM-related tooling are [here](https://github.com/llvm...Hi!
Recently I checked Profile-Guided Optimization (PGO) improvements on multiple projects. The results are [here](https://github.com/zamazan4ik/awesome-pgo/). E.g. PGO results for LLVM-related tooling are [here](https://github.com/llvm/llvm-project/issues/63486). According to the tests, PGO helps with achieving better performance in many software domains. That's why I think trying to optimize CMake with PGO can be a good idea. We have the large amount of CMake scripts with non-trivial logic inside, so optimizing CMake probably could help with optimizing our CMake-times.
I can suggest the following action points:
* Perform PGO benchmarks on CMake. And if it shows improvements - add a note about possible improvements in CMake performance with PGO.
* Providing an easier way (e.g. a build option) to build scripts with PGO can be helpful for the end-users and maintainers since they will be able to optimize the CMake according to their own workloads.
* Optimize pre-built binaries
Testing Post-Link Optimization techniques (like [LLVM BOLT](https://github.com/llvm/llvm-project/blob/main/bolt/README.md)) would be interesting too (Clang and Rustc already use BOLT as an addition to PGO) but I recommend starting from the usual PGO.https://gitlab.kitware.com/cmake/cmake/-/issues/25354add_custom_command: clarify DEPENDS_EXPLICIT_ONLY, DEPFILE, and IMPLICIT_DEPE...2023-12-10T09:23:32-05:00Ben Boeckeladd_custom_command: clarify DEPENDS_EXPLICIT_ONLY, DEPFILE, and IMPLICIT_DEPENDS interactionsThe docs for `DEPENDS_EXPLICIT_ONLY` seem to indicate that it would be incompatible with `DEPFILE` or `IMPLICIT_DEPENDS`. However, there doesn't seem to be any kind of check for such specifications. An explicit callout in the docs would ...The docs for `DEPENDS_EXPLICIT_ONLY` seem to indicate that it would be incompatible with `DEPFILE` or `IMPLICIT_DEPENDS`. However, there doesn't seem to be any kind of check for such specifications. An explicit callout in the docs would be good as well.
Introduced in !8198.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/25351<LANG_ID>_<TOOL>_LAUNCHER target property should be ignored if blank2023-10-20T09:06:03-04:00midrare<LANG_ID>_<TOOL>_LAUNCHER target property should be ignored if blankIf a target's `<LANG_ID>_<TOOL>_LAUNCHER` evaluates to a blank string, then it should be ignored and the default tool should be used instead.
---
Here's the use case: You use the `ccache` compiler cache by setting a target's `CXX_LINKE...If a target's `<LANG_ID>_<TOOL>_LAUNCHER` evaluates to a blank string, then it should be ignored and the default tool should be used instead.
---
Here's the use case: You use the `ccache` compiler cache by setting a target's `CXX_LINKER_LAUNCHER` property, but `ccache` only supports certain compilers. So we'd use a generator expression to enable it conditionally.
For example:
```cmake
set_property(
TARGET your_exe_here
PROPERTY CXX_LINKER_LAUNCHER
"$<$<COMPILE_LANG_AND_ID:CXX,GNU,Clang,NVIDIA>:ccache>")
```
But if the compiler is not supported--if generator expression evaluates to an empty string--CMake tries to execute "" as an actual command. It seems it would be more sensible to ignore a blank string and go on to use the default exe.https://gitlab.kitware.com/cmake/cmake/-/issues/25350HIP: -DCMAKE_HIP_PLATFORM=nvidia fails without env HIP_PLATFORM=nvidia2024-01-02T10:29:13-05:00Michael PanzlaffHIP: -DCMAKE_HIP_PLATFORM=nvidia fails without env HIP_PLATFORM=nvidiaHi,
I'm currently trying out the new feature CMAKE_HIP_PLATFORM in cmake-3.28-rc1. Everything works flawless on the AMD system when I use -DCMAKE_HIP_PLATFORM=amd. However, on the Nvidia system I run into a problem when using -DCMAKE_HI...Hi,
I'm currently trying out the new feature CMAKE_HIP_PLATFORM in cmake-3.28-rc1. Everything works flawless on the AMD system when I use -DCMAKE_HIP_PLATFORM=amd. However, on the Nvidia system I run into a problem when using -DCMAKE_HIP_PLATFORM=nvidia will still attempt to configure the project for amd.
I use this example project for demonstration (rocm version 5.7.1):
https://gitlab.kitware.com/michael.panzlaff/cmake-hip-platform-bugdemo
Running
```
$ cmake -S . -B build -DCMAKE_HIP_PLATFORM=nvidia
```
will raise an error. However, the following does appear to work:
```
$ HIP_PLATFORM=nvidia cmake -S . -B build -DCMAKE_HIP_PLATFORM=nvidia
```
To me having to declare both variables appears to be counterintuitive. I'm not sure whether cmake hip support is at fault or the rocm cmake file.
cmake error output:
```
-- The CXX compiler identification is GNU 12.1.0
-- The C compiler identification is GNU 12.1.0
-- The HIP compiler identification is NVIDIA 12.1.105
Can't exec "/home/hpc/ihpc/ihpc112h/rocm/install/llvm/bin/clang++": No such file or directory at /home/hpc/ihpc/ihpc112h/rocm/install/bin//hipconfig.pl line 71.
Use of uninitialized value $HIP_CLANG_INCLUDE in concatenation (.) or string at /home/hpc/ihpc/ihpc112h/rocm/install/bin//hipconfig.pl line 80.
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /apps/SPACK/0.18.0/opt/linux-almalinux8-zen/gcc-8.5.0/gcc-12.1.0-aqjaxi6qzz4fjsdz6fyxpivbenk6akth/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /apps/SPACK/0.18.0/opt/linux-almalinux8-zen/gcc-8.5.0/gcc-12.1.0-aqjaxi6qzz4fjsdz6fyxpivbenk6akth/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting HIP compiler ABI info
-- Detecting HIP compiler ABI info - done
-- Check for working HIP compiler: /apps/SPACK/0.19.1/opt/linux-almalinux8-zen/gcc-8.5.0/cuda-12.1.1-nekgnnonum23hyldot34gqw76j42mzil/bin/nvcc - skipped
-- Detecting HIP compile features
-- Detecting HIP compile features - done
CMake Deprecation Warning at /home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config.cmake:20 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
Call Stack (most recent call first):
CMakeLists.txt:17 (find_package)
Can't exec "/home/hpc/ihpc/ihpc112h/rocm/install/llvm/bin/clang++": No such file or directory at /home/hpc/ihpc/ihpc112h/rocm/install/bin//hipconfig.pl line 71.
Use of uninitialized value $HIP_CLANG_INCLUDE in concatenation (.) or string at /home/hpc/ihpc/ihpc112h/rocm/install/bin//hipconfig.pl line 80.
CMake Deprecation Warning at /home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config-amd.cmake:21 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
Call Stack (most recent call first):
/home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config.cmake:150 (include)
CMakeLists.txt:17 (find_package)
CMake Error at /home/hpc/ihpc/ihpc112h/cmake/install_alex/share/cmake-3.28/Modules/CMakeFindDependencyMacro.cmake:76 (find_package):
By not providing "FindAMDDeviceLibs.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"AMDDeviceLibs", but CMake did not find one.
Could not find a package configuration file provided by "AMDDeviceLibs"
with any of the following names:
AMDDeviceLibsConfig.cmake
amddevicelibs-config.cmake
Add the installation prefix of "AMDDeviceLibs" to CMAKE_PREFIX_PATH or set
"AMDDeviceLibs_DIR" to a directory containing one of the above files. If
"AMDDeviceLibs" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
/home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config-amd.cmake:67 (find_dependency)
/home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config.cmake:150 (include)
CMakeLists.txt:17 (find_package)
-- Configuring incomplete, errors occurred!
```
cmake output when `HIP_PLATFORM=nvidia` environment variable is set:
```
-- The CXX compiler identification is GNU 12.1.0
-- The C compiler identification is GNU 12.1.0
-- The HIP compiler identification is NVIDIA 12.1.105
Can't exec "/home/hpc/ihpc/ihpc112h/rocm/install/llvm/bin/clang++": No such file or directory at /home/hpc/ihpc/ihpc112h/rocm/install/bin//hipconfig.pl line 71.
Use of uninitialized value $HIP_CLANG_INCLUDE in concatenation (.) or string at /home/hpc/ihpc/ihpc112h/rocm/install/bin//hipconfig.pl line 80.
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /apps/SPACK/0.18.0/opt/linux-almalinux8-zen/gcc-8.5.0/gcc-12.1.0-aqjaxi6qzz4fjsdz6fyxpivbenk6akth/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /apps/SPACK/0.18.0/opt/linux-almalinux8-zen/gcc-8.5.0/gcc-12.1.0-aqjaxi6qzz4fjsdz6fyxpivbenk6akth/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting HIP compiler ABI info
-- Detecting HIP compiler ABI info - done
-- Check for working HIP compiler: /apps/SPACK/0.19.1/opt/linux-almalinux8-zen/gcc-8.5.0/cuda-12.1.1-nekgnnonum23hyldot34gqw76j42mzil/bin/nvcc - skipped
-- Detecting HIP compile features
-- Detecting HIP compile features - done
CMake Deprecation Warning at /home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config.cmake:20 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
Call Stack (most recent call first):
CMakeLists.txt:17 (find_package)
CMake Deprecation Warning at /home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config-nvidia.cmake:21 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
Call Stack (most recent call first):
/home/hpc/ihpc/ihpc112h/rocm/install/lib64/cmake/hip/hip-config.cmake:154 (include)
CMakeLists.txt:17 (find_package)
-- Configuring done (3.6s)
-- Generating done (0.1s)
-- Build files have been written to: /home/hpc/ihpc/ihpc112h/test/build
```https://gitlab.kitware.com/cmake/cmake/-/issues/25349FindThreads fails if CMAKE_LINK_SEARCH_END_STATIC2023-10-19T06:03:17-04:00Anders PedersenFindThreads fails if CMAKE_LINK_SEARCH_END_STATICCMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.28)
project(test)
set(CMAKE_LINK_SEARCH_END_STATIC true)
find_package(Threads REQUIRED)
```
Output
```
root@8c04c339935a:/tmp/cmaketest/build# ~/cmake-3.28.0-rc2-linux-x86_64/bin...CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.28)
project(test)
set(CMAKE_LINK_SEARCH_END_STATIC true)
find_package(Threads REQUIRED)
```
Output
```
root@8c04c339935a:/tmp/cmaketest/build# ~/cmake-3.28.0-rc2-linux-x86_64/bin/cmake ..
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.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
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at /root/cmake-3.28.0-rc2-linux-x86_64/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/root/cmake-3.28.0-rc2-linux-x86_64/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
/root/cmake-3.28.0-rc2-linux-x86_64/share/cmake-3.28/Modules/FindThreads.cmake:226 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:5 (find_package)
```
It seemingly cannot find pthreads. The log reveals that it fails to build the test program for threads, complaining that `/usr/bin/ld: cannot find -lgcc_s: No such file or directory`
```
...
kind: "try_compile-v1"
backtrace:
- "/root/cmake-3.28.0-rc2-linux-x86_64/share/cmake-3.28/Modules/FindThreads.cmake:136 (try_compile)"
- "/root/cmake-3.28.0-rc2-linux-x86_64/share/cmake-3.28/Modules/FindThreads.cmake:179 (_threads_check_flag_pthread)"
- "CMakeLists.txt:5 (find_package)"
checks:
- "Check if compiler accepts -pthread"
directories:
source: "/tmp/cmaketest/build/CMakeFiles/CMakeScratch/TryCompile-r25b7F"
binary: "/tmp/cmaketest/build/CMakeFiles/CMakeScratch/TryCompile-r25b7F"
cmakeVariables:
CMAKE_C_FLAGS: ""
CMAKE_C_FLAGS_DEBUG: "-g"
CMAKE_EXE_LINKER_FLAGS: ""
CMAKE_LINK_SEARCH_END_STATIC: "true"
buildResult:
variable: "THREADS_HAVE_PTHREAD_ARG"
cached: true
stdout: |
Change Dir: '/tmp/cmaketest/build/CMakeFiles/CMakeScratch/TryCompile-r25b7F'
Run Build Command(s): /root/cmake-3.28.0-rc2-linux-x86_64/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f Makefile cmTC_32d2e/fast
/usr/bin/gmake -f CMakeFiles/cmTC_32d2e.dir/build.make CMakeFiles/cmTC_32d2e.dir/build
gmake[1]: Entering directory '/tmp/cmaketest/build/CMakeFiles/CMakeScratch/TryCompile-r25b7F'
Building C object CMakeFiles/cmTC_32d2e.dir/CheckForPthreads.c.o
/usr/bin/cc -o CMakeFiles/cmTC_32d2e.dir/CheckForPthreads.c.o -c /tmp/cmaketest/build/CMakeFiles/CMakeScratch/TryCompile-r25b7F/CheckForPthreads.c
Linking C executable cmTC_32d2e
/root/cmake-3.28.0-rc2-linux-x86_64/bin/cmake -E cmake_link_script CMakeFiles/cmTC_32d2e.dir/link.txt --verbose=1
/usr/bin/cc CMakeFiles/cmTC_32d2e.dir/CheckForPthreads.c.o -o cmTC_32d2e -pthread -Wl,-Bstatic
/usr/bin/ld: cannot find -lgcc_s: No such file or directory
/usr/bin/ld: cannot find -lgcc_s: No such file or directory
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_32d2e.dir/build.make:99: cmTC_32d2e] Error 1
gmake[1]: Leaving directory '/tmp/cmaketest/build/CMakeFiles/CMakeScratch/TryCompile-r25b7F'
gmake: *** [Makefile:127: cmTC_32d2e/fast] Error 2
exitCode: 2
```
The workaround is to just place the `set(CMAKE_LINK_SEARCH_END_STATIC true)` after the `find_package(Threads REQUIRED)`. Not a big issue, just thought I'd document it since I spent quite a while tracking it down and couldn't find any similar issues.https://gitlab.kitware.com/cmake/cmake/-/issues/25348Xcode: build-time environment2023-10-19T09:03:18-04:00RavbugXcode: build-time environmentI have a project which targets iOS (among other things), but needs to also generate an executable for the host to run during compilation. I achieve this with `add_custom_command` as follows, that generates a second config for the host to...I have a project which targets iOS (among other things), but needs to also generate an executable for the host to run during compilation. I achieve this with `add_custom_command` as follows, that generates a second config for the host to build and run:
```cmake
add_custom_command(
PRE_BUILD
WORKING_DIRECTORY ${TOOLS_DIR}
DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/deps/RGL/CMakeLists.txt"
COMMAND ${CMAKE_COMMAND} ${CC_GENERATOR} -DCMAKE_BUILD_TYPE=Release ${HT_ENABLE_WGSL} "${CMAKE_CURRENT_SOURCE_DIR}/deps/RGL"
OUTPUT "${TOOLS_DIR}/CMakeCache.txt"
)
```
and I generate the top-level Xcode project by setting `-DCMAKE_SYSTEM_NAME=iOS` on the command line.
However, this causes the `add_custom_command` to generate an iOS Xcode project, causing a failure when the host tries to run the resulting binary. I added a command in the subproject to print the environment variables that CMake is receiving, like this:
```cmake
execute_process(COMMAND "${CMAKE_COMMAND}" "-E" "environment")
```
which showed that something is setting some environment variables when it invokes the custom command:
```
TARGET_DEVICE_OS_VERSION=17.0
TARGET_DEVICE_PLATFORM_NAME=iphonesimulator
...
DEVELOPER_SDK_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
```
I want the custom command to have a "stock" environment, similar to if I invoked it from a fresh shell. Is this possible to do with `add_custom_command`?https://gitlab.kitware.com/cmake/cmake/-/issues/25347VS: DOTNET_SDK: Cannot generate a single dot net binary which contains the do...2023-10-18T13:28:13-04:00elkssonVS: DOTNET_SDK: Cannot generate a single dot net binary which contains the dotnet core runtime inside the exeCMAKE does not run dotnet publish to generate a single binary file which contains the dotnet runtime,
and its not possible to use custom command to call dotnet publish after the build is finished.
```
cmake_minimum_required(VERSION 3.2...CMAKE does not run dotnet publish to generate a single binary file which contains the dotnet runtime,
and its not possible to use custom command to call dotnet publish after the build is finished.
```
cmake_minimum_required(VERSION 3.25.1)
project(myproj LANGUAGES CSharp)
# https://stackoverflow.com/questions/2074144/generate-c-sharp-project-using-cmake
include(CSharpUtilities)
set(CMAKE_CSharp_FLAGS "/platform:anycpu")
file(GLOB SOURCES *.cs)
add_executable( myapp${SOURCES})
set(CMAKE_VS_NUGET_PACKAGE_RESTORE true)
set_target_properties(myapp PROPERTIES
DOTNET_SDK "Microsoft.NET.Sdk"
DOTNET_TARGET_FRAMEWORK "net6.0"
VS_GLOBAL_Configurations "Debug;Release;RelWithDebInfo;MinSizeRel"
VS_GLOBAL_Version "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_REVISION}.${VERSION_BUILD}" FILE_CONTENTS "${FILE_CONTENTS}"
VS_GLOBAL_ImplicitUsings enable
VS_GLOBAL_PublishSingleFile true
VS_GLOBAL_SelfContained true
VS_GLOBAL_RuntimeIdentifier win-x86
VS_GLOBAL_IncludeNativeLibrariesForSelfExtract true)
set_property(TARGET myappPROPERTY VS_PACKAGE_REFERENCES
"NUnit_3.13.3")
install( TARGETS myapp
COMPONENT default
DESTINATION . )
```https://gitlab.kitware.com/cmake/cmake/-/issues/25343feature: LINK_WARNING_AS_ERROR2023-10-24T09:14:01-04:00scivisionfeature: LINK_WARNING_AS_ERRORI have found COMPILE_WARNING_AS_ERROR useful for CI and in `try_compile` to detect issues at configure time.
A LINK_WARNING_AS_ERROR property would be useful to catch link-time warnings as errors in CI, to help users debug a build on th...I have found COMPILE_WARNING_AS_ERROR useful for CI and in `try_compile` to detect issues at configure time.
A LINK_WARNING_AS_ERROR property would be useful to catch link-time warnings as errors in CI, to help users debug a build on their system, and in `try_compile` to detect anomalous conditions.
Currently, I regex try_compile log to detect linker problems, which is a maintenance burden and shaky.
## Example
```cmake
cmake_minimum_required(VERSION 3.25)
set(CMAKE_EXE_LINKER_FLAGS_INIT -ld64)
# this will generate a linker warning, as an example for AppleClang
project(prop LANGUAGES C CXX)
set(CMAKE_LINK_WARNING_AS_ERROR true) # proposed
set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES CMAKE_LINK_WARNING_AS_ERROR)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c "int func();
int main(void) { func(); return 0; }")
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/lib.cxx "extern \"C\" int func(){ return 0; }")
try_compile(res SOURCES ${CMAKE_CURRENT_BINARY_DIR}/main.c ${CMAKE_CURRENT_BINARY_DIR}/lib.cxx)
message(STATUS "try_compile: ${res}")
# when CMAKE_LINK_WARNING_AS_ERROR is working, this would be FALSE
```
## Specific use case
In some cases, using AppleClang with GNU GFortran, C++ exception handling may be broken and is accompanied by linker warnings. That is, when running the target, C++ exceptions may not "catch" and the program halts at runtime instead of using the "catch" C++ user code.
I handle this situation now by using "try_compile()" and have CMake regex try_compile() linker warnings, and/or "try_run()" and warning the user C++ exception handling may not work. A more general approach is the option for linker warnings as errors.https://gitlab.kitware.com/cmake/cmake/-/issues/25342Feature: `FETCHCONTENT_INCLUDE`: Equivalent to `CMAKE_PROJECT_INCLUDE` for `F...2024-02-24T03:37:43-05:00Cristian LeFeature: `FETCHCONTENT_INCLUDE`: Equivalent to `CMAKE_PROJECT_INCLUDE` for `FetchContent_MakeAvailable`## Concept
The functions `FETCHCONTENT_INCLUDE`, `FETCHCONTENT_INCLUDE_BEFORE`, `FETCHCONTENT_<ProjectName>_INCLUDE` and `FETCHCONTENT_<ProjectName>_INCLUDE_BEFORE` would be the equivalents of `CMAKE_PROJECT_INCLUDE` variables, but:
- `...## Concept
The functions `FETCHCONTENT_INCLUDE`, `FETCHCONTENT_INCLUDE_BEFORE`, `FETCHCONTENT_<ProjectName>_INCLUDE` and `FETCHCONTENT_<ProjectName>_INCLUDE_BEFORE` would be the equivalents of `CMAKE_PROJECT_INCLUDE` variables, but:
- `INCLUDE_BEFORE` are included before the calls of `FetchContent_Declare`, potentially having a pre-defined `cmake_parser_arguments` interface of the arguments used
- Alternatively, the include could be before `FetchContent_MakeAvailable` such that the scope of the variables are limited
- `INCLUDE` are included after the calls of `FetchContent_MakeAvailable`, with a pre-defined variable that holds the name of the project. This should be called with the context of the project that was effectively called with `add_subdirectory`.
## Usage
Currently I do not have a killer usecase for this, but the one I have right now is: Injecting `set_package_properties` and `set_property(PACKAGES_FOUND)` for #25322. This is because the name as found in `FetchContent_Declare` is needed, and the inclusion of these files should be conditional to if `FetchContent` is used as opposed to if `find_package` override is called.
This would be different from simply calling `include()` in that the interface is a bit cleaner and it would contain the context of the inner project with `add_subdirectory`.
## Issues
- How would this interact with chained `FetchContent`? The simplest approach is that it does not interact, and simply the current variable scope is used. This would mean that it is hard to have one project that inject a script in all subprojects (like `set_package_properties`)https://gitlab.kitware.com/cmake/cmake/-/issues/25340execute_process() silently accepts invalid input/output/error files2024-02-02T10:07:30-05:00Kyle Edwardsexecute_process() silently accepts invalid input/output/error filesPrior to refactoring in !8665, `execute_process()` would silently accept an `INPUT_FILE`, `OUTPUT_FILE`, or `ERROR_FILE` that couldn't be opened, and simply proceed without it. This was discovered in the course of fixing #25338, which al...Prior to refactoring in !8665, `execute_process()` would silently accept an `INPUT_FILE`, `OUTPUT_FILE`, or `ERROR_FILE` that couldn't be opened, and simply proceed without it. This was discovered in the course of fixing #25338, which also revealed that the new code segfaults in such instances. We should restore the old behavior for now, but I believe it's a bug that should be fixed with a policy post-3.28. The new behavior should produce an error if the `INPUT_FILE`, `OUTPUT_FILE`, or `ERROR_FILE` can't be opened.https://gitlab.kitware.com/cmake/cmake/-/issues/25339Add CMakePresets for CMake itself2023-10-17T04:09:59-04:00Cristian LeAdd CMakePresets for CMake itselfShould include some basic presets for CMake itself. Not sure how practical it would be on the CI right now, but at least for (new) developers it would be useful to provide some basic ones:
- `default`
- `debug`
- `docs` (although it woul...Should include some basic presets for CMake itself. Not sure how practical it would be on the CI right now, but at least for (new) developers it would be useful to provide some basic ones:
- `default`
- `debug`
- `docs` (although it would make more sense to have it be buildable with plain `python`?)
- `gui`
- `cpack`
- `ctest`
Any other useful presets to implement or make them known?https://gitlab.kitware.com/cmake/cmake/-/issues/25336Generic-ADSP: ADSP_GENERATE_VDK no support for -o switch2023-10-13T11:24:57-04:00Peter RemmersGeneric-ADSP: ADSP_GENERATE_VDK no support for -o switchThe "ADSP_GENERATE_VDK" macro in Generic-ADSP-Common.cmake (defined at line 88 with version 3.27.7) is not very useful because there is no way to set the "-o" switch for the output directory.The "ADSP_GENERATE_VDK" macro in Generic-ADSP-Common.cmake (defined at line 88 with version 3.27.7) is not very useful because there is no way to set the "-o" switch for the output directory.https://gitlab.kitware.com/cmake/cmake/-/issues/25335Generic-ADSP: ADSP_ELFLOADER_EXECUTABLE not found2023-10-13T12:12:35-04:00Peter RemmersGeneric-ADSP: ADSP_ELFLOADER_EXECUTABLE not found`Platform/Generic-ADSP.Common.cmake` has (at line 97 in version 3.27.7) a line to find the `elfloader.exe`.
But this file is not found because the path where it's looked for (`_ADSP_FAMILY_DIR`) is the Blackfin subdirectory where it is n...`Platform/Generic-ADSP.Common.cmake` has (at line 97 in version 3.27.7) a line to find the `elfloader.exe`.
But this file is not found because the path where it's looked for (`_ADSP_FAMILY_DIR`) is the Blackfin subdirectory where it is not located. The file is actually in the VisualDSP base directory (`_ADSP_DIR`).
So to fix this the line should be changed
```patch
-find_program( ADSP_ELFLOADER_EXECUTABLE elfloader "${_ADSP_FAMILY_DIR}" )
+find_program( ADSP_ELFLOADER_EXECUTABLE elfloader "${_ADSP_DIR}" )
```https://gitlab.kitware.com/cmake/cmake/-/issues/25333Generic-ADSP: harmful library path added2023-10-13T11:24:39-04:00Peter RemmersGeneric-ADSP: harmful library path added`Platform/Generic-ADSP-Common.cmake` has this line (line 83 in version 3.27.7):
```cmake
link_directories("${_ADSP_FAMILY_DIR}/lib")
```
This adds the `...\VisualDSP 5.0\Blackfin\lib` directory to the default library search path.
That'...`Platform/Generic-ADSP-Common.cmake` has this line (line 83 in version 3.27.7):
```cmake
link_directories("${_ADSP_FAMILY_DIR}/lib")
```
This adds the `...\VisualDSP 5.0\Blackfin\lib` directory to the default library search path.
That's a bad idea, because the libraries exist in multiple versions for different "silicon revisions" in various subdirectories, and what happens is that the ones in the `\lib` dir are always found and used first even though they are not the correct version for the si-revision the project is compiled with and that was given to the linker command line.
The effect is that the linker spits out lots of warnings about si-revision mismatches, and of course not to mention the risk of the program misbehaving in certain corner cases.
Analog Devices' linker knows about si-revision and which version of library to link against, and where to find it.
I suggest to fix this by removing that line from `Platform/Generic-ADSP-Common.cmake` as it's not needed and, on the contrary, only does harm.
Besides, this cannot be undone in a toolchain file (not by any means I have found out so far), and I have to undo it in the project's CMakeLists.txt by clearing the LINK_DIRECTORIES property.https://gitlab.kitware.com/cmake/cmake/-/issues/25332presets: workflow: Run specific steps or subsets2023-12-05T06:02:44-05:00Cristian Lepresets: workflow: Run specific steps or subsetsFirst let me introduce the setup written in yaml for brevity:
```yaml
workflowPresets:
- name: minimal
steps:
- type: configure
name: minimal
- type: build
name: minimal
- type: test
name: ...First let me introduce the setup written in yaml for brevity:
```yaml
workflowPresets:
- name: minimal
steps:
- type: configure
name: minimal
- type: build
name: minimal
- type: test
name: minimal-unit-test
- type: test
name: minimal-functional-test
- name: full
steps:
- type: configure
name: full
- type: build
name: full
- type: test
name: full-unit-test
- type: test
name: full-functional-test
```
Now I want to add this to a CI where I run in order:
- `cmake --workflow --preset minimal,full --type configure`
- `cmake --workflow --preset minimal,full --type build`
- `cmake --workflow --preset minimal,full --type test`
This way if any of the previous step fails it will gate the other ones so that you don't waste resources. Otherwise if the full run is needed, the current method can be used.
To implement this usefully there are two features that should be added
- Allow for comma separated presets to be run
- The user is responsible to make sure the build directories are different
- It should only be used for workflow presets, otherwise there is an ambiguity when you override the settings, especially if you add `-B` in the configure preset
- Add another cli option `--type` which will filter the types in the workflow and run only the select items
- Mutually exclusive with `--fresh`
- Reporting step number could be set so that it reports like `step 2 of 4` when run with `--type build`, i.e. as if it was run in the full workflow
- The user is responsible to make sure the steps are run in a correct order
- Possibly could also add `--step` accepting the specific workflow step number to run