CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-02-08T02:56:22-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25660Feature Request: Provide an optional combined+build form of invoking cmake.2024-02-08T02:56:22-05:00Michael JonesFeature Request: Provide an optional combined+build form of invoking cmake.My codebase has a wrapper script around cmake used by my development staff. This wrapper script orchestrates multiple different cmake configuration/build trees with different configuration settings from the same source directory. The scr...My codebase has a wrapper script around cmake used by my development staff. This wrapper script orchestrates multiple different cmake configuration/build trees with different configuration settings from the same source directory. The script also tries to wrangle whether or not it needs to run the configuration phase for a particular directory based on various heuristics such as if the user has changed the list of source directories to include in their build since the last run of the configuration phase (insusceptible via environment variable).
It would allow us to have much simpler logic if cmake were to support a command line invocation which provided all of the configuration parameters, ran configuration (only if needed based on the logic that cmake --build normally uses to determine if reconfiguration is needed) and then proceeded to invoke the build e.g.
```
cmake -G"Ninja Multi-Config" -S D:\builds\some-source-folder -B D:\builds\some-build-folder --toolchain my_toolchain_file.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_CROSS_CONFIGS=all -DCMAKE_DEFAULT_CONFIGS="Release;Debug" -DCMAKE_CONFIGURATION_TYPES="Release;Debug;Checked" -DCMAKE_UNITY_BUILD=ON --build D:\builds\some-build-folder --target some-target
```
So that the wrapper script need not separate the configuration and build steps in the majority of cases.
Notably this would also most likely become the default way many projects use cmake in their continuous integration scripts, since there's no human interactivity to be desired the easiest way to accomplish the CI build is one command.https://gitlab.kitware.com/cmake/cmake/-/issues/25659message: Allow choosing output stream (stdout vs stderr) regardless of mode /...2024-02-06T09:10:33-05:00alcroitomessage: Allow choosing output stream (stdout vs stderr) regardless of mode / levelWhen using cmake's script mode (`-P`) as a general scripting language, it would be useful to choose which output stream (`stderr` or `stdout`) messages should be printed to, regardless of message level (`STATUS`, `NOTICE`, etc.)
If one ...When using cmake's script mode (`-P`) as a general scripting language, it would be useful to choose which output stream (`stderr` or `stdout`) messages should be printed to, regardless of message level (`STATUS`, `NOTICE`, etc.)
If one wishes to print to `stdout`, they are forced to choose between `STATUS` to `TRACE`, but those also get the `--` prefix, which might be undesirable.
`message(NOTICE)` doesn't print the `--` prefix, but it goes to `stderr` instead.
Perhaps we can have a new signature, something like:
```
message(PRINT "message text" ... ECHO [stdout | stderr])
```
with a default to stdout.https://gitlab.kitware.com/cmake/cmake/-/issues/25658ctest_test: Add "show only" option2024-02-05T16:14:32-05:00Phani kiranctest_test: Add "show only" optionHello,
Currently, if we use -N with ctest script, no tests are shown. Request is to provide a SHOW_ONLY option for ctest_test() to help get a list of tests. Related discussion thread is here https://discourse.cmake.org/t/ctest-does-not-...Hello,
Currently, if we use -N with ctest script, no tests are shown. Request is to provide a SHOW_ONLY option for ctest_test() to help get a list of tests. Related discussion thread is here https://discourse.cmake.org/t/ctest-does-not-show-tests-when-executing-in-script-mode/9860
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/25656[macOS] precompiled_headers target forces Clang-only flags which break build ...2024-02-11T11:39:08-05:00Sergey Fedorov[macOS] precompiled_headers target forces Clang-only flags which break build with GCCFor some reason CMake forces arch flags in Clang-only form if precompiled_headers target is enabled. This breaks the build with GCC:
```
g++-mp-13: error: unrecognized command-line option '-Xarch_ppc'
```
Real-life example: https://githu...For some reason CMake forces arch flags in Clang-only form if precompiled_headers target is enabled. This breaks the build with GCC:
```
g++-mp-13: error: unrecognized command-line option '-Xarch_ppc'
```
Real-life example: https://github.com/magiblot/turbo/issues/65#issuecomment-1905023218
The correct flag for GCC would be `-arch ppc` (or `-arch x86_64` etc.).
This is apparently a know issue: https://android.googlesource.com/platform/external/deqp-deps/glslang/+/refs/heads/main/CMakeLists.txt#99
However it is still unfixed, from the looks of things.https://gitlab.kitware.com/cmake/cmake/-/issues/25655Emacs cmake-mode: add entries to compilation-error-regexp-alist2024-02-12T03:29:48-05:00Dave AbrahamsEmacs cmake-mode: add entries to compilation-error-regexp-alistIn the `*compilation*` buffer, errors of the form
```
CMake Error at CMakeLists.txt:72:
Parse error. Function missing ending ")". End of file reached.
```
are recognized, but incorrectly; I should be able to click on the first lin...In the `*compilation*` buffer, errors of the form
```
CMake Error at CMakeLists.txt:72:
Parse error. Function missing ending ")". End of file reached.
```
are recognized, but incorrectly; I should be able to click on the first line and jump to `CMakeLists.txt` line 72.
Possibly a better solution would be to make all CMake diagnostics Gnu-compliant so that the built-in recognizers just work.https://gitlab.kitware.com/cmake/cmake/-/issues/25654A conditionally disabled preset should be allowed to have a duplicate name2024-02-06T04:38:39-05:00Claus KleinA conditionally disabled preset should be allowed to have a duplicate nameThat would help to write simple and clear CMakePresets.json.
simple example
```json
{
"version": 7,
"configurePresets": [
{
"name": "default",
"binaryDir": "${sourceDir}/build/${presetName}",
...That would help to write simple and clear CMakePresets.json.
simple example
```json
{
"version": 7,
"configurePresets": [
{
"name": "default",
"binaryDir": "${sourceDir}/build/${presetName}",
"generator": "Ninja",
"cacheVariables": {
"VCPKG_TARGET_TRIPLET": "x64-windows"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Windows"
}
},
{
"name": "default",
"binaryDir": "${sourceDir}/build/${presetName}",
"generator": "Ninja",
"cacheVariables": {
"VCPKG_TARGET_TRIPLET": "x64-osx"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Darwin"
}
}
],
"buildPresets": [
{
"name": "default",
"configurePreset": "default"
}
],
"testPresets": [
{
"name": "default",
"configurePreset": "default",
"output": {
"outputOnFailure": true
},
"execution": {
"noTestsAction": "error",
"stopOnFailure": true
}
}
],
"packagePresets": [
{
"name": "default",
"configurePreset": "default",
"generators": [
"TGZ"
]
}
]
}
```https://gitlab.kitware.com/cmake/cmake/-/issues/25653emacs cmake-mode: Buffer is read-only: #<buffer *CMake Help*>2024-02-03T09:50:38-05:00Dave Abrahamsemacs cmake-mode: Buffer is read-only: #<buffer *CMake Help*>run M-x cmake-help add_executable
and then from within the *CMake Help* buffer, run run M-x cmake-help add_library
I get the error noted in the title with emacs-29.1run M-x cmake-help add_executable
and then from within the *CMake Help* buffer, run run M-x cmake-help add_library
I get the error noted in the title with emacs-29.1https://gitlab.kitware.com/cmake/cmake/-/issues/25648CUDA: using Microsoft compiler with Clang is not working on Windows2024-02-06T15:00:37-05:00Christian GerlachCUDA: using Microsoft compiler with Clang is not working on WindowsI am trying to replace nvcc as CUDA compiler on Windows by clang. I am using one of the latest cmake nightly builds (cmake-3.28.20240130-g 83db6b3) as there were a couple of improvements in this area lately. It is nice to see, that most ...I am trying to replace nvcc as CUDA compiler on Windows by clang. I am using one of the latest cmake nightly builds (cmake-3.28.20240130-g 83db6b3) as there were a couple of improvements in this area lately. It is nice to see, that most of the compiler combination simply work out of box now:
* host: `msvc` cuda: `nvcc` -\> works
* host: `clang` cuda: `nvcc` -\> works
* host: `clang` cuda: `clang` -\> works
* host: `msvc` cuda: `clang` -\> fails
From the log output it seems as msvc compiler options are integrated into the clang command line. This looks like the problem, which was mentioned in cmake/cmake!4888. Also cmake/cmake#21934 could be related. Is this supposed to work or am I doing anything wrong here?
I have prepared a small CMake test project to play with the different compiler options. The toolchain looks as follows:
<details>
<summary>Click to expand</summary>
```cmake
set (ENABLE_CLANG_FOR_HOST OFF)
set (ENABLE_CLANG_FOR_CUDA ON)
set (clang_ROOT "C:/3rd/clang-windows-msvc-17.6-amd64-release.16.0.1-z2")
#------------------------------------------------------------------------------
# Setup Visual Studio
set (VCRoot "C:/Program Files/Microsoft Visual Studio/2022/17.6/VC/Tools/MSVC/14.36.32532")
if(ENABLE_CLANG_FOR_HOST)
set (CMAKE_C_COMPILER "${clang_ROOT}/bin/clang.exe")
set (CMAKE_CXX_COMPILER "${clang_ROOT}/bin/clang++.exe")
else()
set (CMAKE_C_COMPILER "${VCRoot}/bin/Hostx64/x64/cl.exe")
set (CMAKE_CXX_COMPILER "${VCRoot}/bin/Hostx64/x64/cl.exe")
endif()
link_directories ("${VCRoot}/lib/x64")
#------------------------------------------------------------------------------
# Setup Windows SDK
set (WindowsSDKDir "C:/3rd/windows_kits-windows-msvc-17.6-amd64-release.10.0.22000.0-z1/10")
set (WindowsSDKBinDir "${WindowsSDKDir}/bin/10.0.22000.0/x64")
set (WindowsSDKLibDir "${WindowsSDKDir}/Lib/10.0.22000.0")
set (CMAKE_RC_COMPILER "${WindowsSDKBinDir}/rc.exe")
set (CMAKE_MC_COMPILER "${WindowsSDKBinDir}/mc.exe")
set (CMAKE_MT "${WindowsSDKBinDir}/mt.exe")
link_directories ("${WindowsSDKLibDir}/um/x64")
link_directories ("${WindowsSDKLibDir}/ucrt/x64")
#------------------------------------------------------------------------------
# Setup CUDA
set (CUDAToolkit_ROOT "C:/3rd/Cuda-11.4_gom2")
set (CMAKE_CUDA_ARCHITECTURES 52)
if (ENABLE_CLANG_FOR_CUDA)
set (CMAKE_CUDA_COMPILER "${clang_ROOT}/bin/clang++.exe")
else()
set (CMAKE_CUDA_COMPILER "${CUDAToolkit_ROOT}/bin/nvcc.exe")
set (CMAKE_CUDA_FLAGS_INIT "-allow-unsupported-compiler -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH")
endif()
```
</details>
And the configure output:
<details>
<summary>Click to expand</summary>
```bat
[main] Configuring project: vs-cuda
[driver] Removing C:/workspaces/vs-cuda/out/build/Release/CMakeCache.txt
[driver] Removing C:\workspaces\vs-cuda\out\build\Release\CMakeFiles
[proc] Executing command: C:/gom/cmake-3.29.0/bin/cmake.exe -DCMAKE_MAKE_PROGRAM=c:/gom/gom-build-tools-1.2/ninja.exe -DCMAKE_TOOLCHAIN_FILE=C:/workspaces/vs-cuda/toolchain.cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:/workspaces/vs-cuda/out/install/Release -SC:/workspaces/vs-cuda -BC:/workspaces/vs-cuda/out/build/Release -G Ninja
[cmake] -- The CXX compiler identification is MSVC 19.36.32538.0
[cmake] -- The CUDA compiler identification is Clang 16.0.1 with GNU-like command-line
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/17.6/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] -- Detecting CUDA compiler ABI info
[cmake] -- Detecting CUDA compiler ABI info - failed
[cmake] -- Check for working CUDA compiler: C:/3rd/clang-windows-msvc-17.6-amd64-release.16.0.1-z2/bin/clang++.exe
[cmake] -- Check for working CUDA compiler: C:/3rd/clang-windows-msvc-17.6-amd64-release.16.0.1-z2/bin/clang++.exe - broken
[cmake] CMake Error at C:/gom/cmake-3.29.0/share/cmake-3.28/Modules/CMakeTestCUDACompiler.cmake:59 (message):
[cmake] The CUDA compiler
[cmake]
[cmake] "C:/3rd/clang-windows-msvc-17.6-amd64-release.16.0.1-z2/bin/clang++.exe"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: 'C:/workspaces/vs-cuda/out/build/Release/CMakeFiles/CMakeScratch/TryCompile-168q5g'
[cmake]
[cmake] Run Build Command(s): c:/gom/gom-build-tools-1.2/ninja.exe -v cmTC_9df71
[cmake] [1/2] C:\3rd\clang-windows-msvc-17.6-amd64-release.16.0.1-z2\bin\clang++.exe --cuda-gpu-arch=sm_52 --cuda-path=C:\3rd\Cuda-11.4_gom2 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -MD -MT CMakeFiles/cmTC_9df71.dir/main.cu.obj -MF CMakeFiles\cmTC_9df71.dir\main.cu.obj.d -x cuda -c C:/workspaces/vs-cuda/out/build/Release/CMakeFiles/CMakeScratch/TryCompile-168q5g/main.cu -o CMakeFiles/cmTC_9df71.dir/main.cu.obj
[cmake] [2/2] C:\WINDOWS\system32\cmd.exe /C "cd . && C:\3rd\clang-windows-msvc-17.6-amd64-release.16.0.1-z2\bin\clang++.exe -nostartfiles -nostdlib --cuda-path=C:\3rd\Cuda-11.4_gom2 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview /machine:x64 -Xlinker /subsystem:console -fuse-ld=lld-link CMakeFiles/cmTC_9df71.dir/main.cu.obj -o cmTC_9df71.exe -Xlinker /MANIFEST:EMBED -Xlinker /implib:cmTC_9df71.lib -Xlinker /pdb:cmTC_9df71.pdb -Xlinker /version:0.0 -LC:/PROGRA~1/MICROS~4/2022/17.6/VC/Tools/MSVC/1436~1.325/lib/x64 -LC:/3rd/windows_kits-windows-msvc-17.6-amd64-release.10.0.22000.0-z1/10/Lib/10.0.22000.0/um/x64 -LC:/3rd/windows_kits-windows-msvc-17.6-amd64-release.10.0.22000.0-z1/10/Lib/10.0.22000.0/ucrt/x64 -lcudadevrt.lib -lcudart_static.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames -L"C:/3rd/Cuda-11.4_gom2/lib/x64" && cd ."
[cmake] FAILED: cmTC_9df71.exe
[cmake] C:\WINDOWS\system32\cmd.exe /C "cd . && C:\3rd\clang-windows-msvc-17.6-amd64-release.16.0.1-z2\bin\clang++.exe -nostartfiles -nostdlib --cuda-path=C:\3rd\Cuda-11.4_gom2 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview /machine:x64 -Xlinker /subsystem:console -fuse-ld=lld-link CMakeFiles/cmTC_9df71.dir/main.cu.obj -o cmTC_9df71.exe -Xlinker /MANIFEST:EMBED -Xlinker /implib:cmTC_9df71.lib -Xlinker /pdb:cmTC_9df71.pdb -Xlinker /version:0.0 -LC:/PROGRA~1/MICROS~4/2022/17.6/VC/Tools/MSVC/1436~1.325/lib/x64 -LC:/3rd/windows_kits-windows-msvc-17.6-amd64-release.10.0.22000.0-z1/10/Lib/10.0.22000.0/um/x64 -LC:/3rd/windows_kits-windows-msvc-17.6-amd64-release.10.0.22000.0-z1/10/Lib/10.0.22000.0/ucrt/x64 -lcudadevrt.lib -lcudart_static.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames -L"C:/3rd/Cuda-11.4_gom2/lib/x64" && cd ."
[cmake] clang++: error: no such file or directory: '/machine:x64'
[cmake] ninja: build stopped: subcommand failed.
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]
[cmake] CMake will not be able to correctly generate this project.
[cmake] Call Stack (most recent call first):
[cmake] CMakeLists.txt:2 (project)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[proc] The command: C:/gom/cmake-3.29.0/bin/cmake.exe -DCMAKE_MAKE_PROGRAM=c:/gom/gom-build-tools-1.2/ninja.exe -DCMAKE_TOOLCHAIN_FILE=C:/workspaces/vs-cuda/toolchain.cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:/workspaces/vs-cuda/out/install/Release -SC:/workspaces/vs-cuda -BC:/workspaces/vs-cuda/out/build/Release -G Ninja exited with code: 1
```
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/25642file(GET_RUNTIME_DEPENDENCIES) need a way to know whether the dependencies is...2024-01-28T02:12:34-05:00Jason Juangfile(GET_RUNTIME_DEPENDENCIES) need a way to know whether the dependencies is a framework or notWhen runtime dependencies are normal dylibs, the below example works properly:
```
add_library(Foo SHARED foo.cpp foo.h)
add_executable(Main main.cpp)
target_link_libraries(Main Foo)
set_target_properties(Main PROPERTIES INSTALL_RPATH "...When runtime dependencies are normal dylibs, the below example works properly:
```
add_library(Foo SHARED foo.cpp foo.h)
add_executable(Main main.cpp)
target_link_libraries(Main Foo)
set_target_properties(Main PROPERTIES INSTALL_RPATH "@executable_path")
install(TARGETS Main RUNTIME DESTINATION bin)
install(
CODE "file(GET_RUNTIME_DEPENDENCIES EXECUTABLES \$<TARGET_FILE:Main> RESOLVED_DEPENDENCIES_VAR DEPS)\n \"
foreach(DEP \${DEPS})\n \
file(INSTALL \${DEPS} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)\n \
endforeach()")
```
However, if the runtime dependent library is a framework it won't work, for example
```
add_library(Foo SHARED foo.cpp foo.h)
set_target_properties(Foo PROPERTIES FRAMEWORK TRUE PUBLIC_HEADER "foo.h")
add_executable(Main main.cpp)
target_link_libraries(Main Foo)
set_target_properties(Main PROPERTIES INSTALL_RPATH "@executable_path")
install(TARGETS Main RUNTIME DESTINATION bin)
install(
CODE "file(GET_RUNTIME_DEPENDENCIES EXECUTABLES \$<TARGET_FILE:Main> RESOLVED_DEPENDENCIES_VAR DEPS)\n \"
foreach(DEP \${DEPS})\n \
file(INSTALL \${DEPS} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)\n \
endforeach()")
```
After `cmake -DCMAKE_INSTALL_PREFIX=/tmp ..`, `make install`, `/tmp/bin/Main` failed with `dyld Library not loaded: @rpath/Foo.framework/Versions/A/Foo`, this is because only `Foo` is copied to `${CMAKE_INSTALL_PREFIX}/bin`, but what needs to happen is the entire framework `Foo.framework/Versions/A/Foo` to be copied to `${CMAKE_INSTALL_PREFIX}/bin`. There doesn't seem to be a function to take in the library name `${DEPS}` as an input and return the corresponding target as an output so we can check whether the target is a framework or not. I think what's better is for `file(GET_RUNTIME_DEPENDENCIES)` to provide a new argument like `RESOLVED_FRAMEWORK_DEPENDENCIES_VAR` to resolve this problem. Do you agree?https://gitlab.kitware.com/cmake/cmake/-/issues/25641cppcheck: Don't append compiler commands if using --project2024-01-28T05:40:30-05:00HackingPheasantcppcheck: Don't append compiler commands if using --project**cppcheck** supports the use of `--project` which takes in a `compile_commands.json` file. But like with what was happening with clang-tidy, CMake appends the compiler command line (the conflicting bit is the `--source=` flag) which cau...**cppcheck** supports the use of `--project` which takes in a `compile_commands.json` file. But like with what was happening with clang-tidy, CMake appends the compiler command line (the conflicting bit is the `--source=` flag) which causes cppcheck to error out.
Implementing the same thing as seen in cmake/cmake!7753 should fix up the issue.https://gitlab.kitware.com/cmake/cmake/-/issues/25640Crosscompilation support for same CMAKE_SYSTEM_NAME but different CMAKE_SYSTE...2024-02-12T10:44:37-05:00Pavel FerenczCrosscompilation support for same CMAKE_SYSTEM_NAME but different CMAKE_SYSTEM_PROCESSORCmake won't succeed building for an arm64 CPU target on an x86_64 CPU host if both the target and the host system name is "Darwin".
This is a common use-case for macOS builds, but affects all crosscompilation targets that are built for ...Cmake won't succeed building for an arm64 CPU target on an x86_64 CPU host if both the target and the host system name is "Darwin".
This is a common use-case for macOS builds, but affects all crosscompilation targets that are built for the same CMAKE_SYSTEM_NAME.
The issue is that Modules/CMakeDetermineSystem.cmake only detects crosscompilation if CMAKE_SYSTEM_NAME is manually defined.
While this works when the target system name is differs from the host system name (e.g, building for WinCE on a linux host), this solution won't work when building for the same system name and version, but for a different target CPU architecture.
This use-case is especially common on "Darwin" machines, because it's very common to build universal binaries for macOS (binaries that can run on multiple CPU architectures).https://gitlab.kitware.com/cmake/cmake/-/issues/25637CMake fails to configure CUDA using clang++-142024-01-26T08:10:49-05:00Eyal Rozenbergeyalroz1@gmx.comCMake fails to configure CUDA using clang++-14<sub>(Filed following [this SO answer](https://stackoverflow.com/a/77879291/1593077).)</sub>
I'm trying to configure a build with the following list file:
```
cmake_minimum_required(VERSION 3.24)
project(vector_addition_with_clang CUDA)...<sub>(Filed following [this SO answer](https://stackoverflow.com/a/77879291/1593077).)</sub>
I'm trying to configure a build with the following list file:
```
cmake_minimum_required(VERSION 3.24)
project(vector_addition_with_clang CUDA)
add_executable(vectorAdd vectorAdd.cu)
set_target_properties(vectorAdd PROPERTIES CUDA_ARCHITECTURES native)
```
and with the following command-line:
```
cmake -B build -DCMAKE_CUDA_HOST_COMPILER=clang++-14 -DCMAKE_CUDA_COMPILER=clang++-14
```
Now, if I replace clang++-14 with clang++-16, everything works fine. But with clang++-14 (and with `--debug-output`), I get:
```
-- The CUDA compiler identification is unknown
Called from: [3] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCompilerId.cmake
[2] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake
[1] /tmp/1_vector_addition/CMakeLists.txt
CMake Error at /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake:270 (message):
Failed to detect a default CUDA architecture.
Compiler output:
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
Called from: [2] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake
[1] /tmp/1_vector_addition/CMakeLists.txt
-- Configuring incomplete, errors occurred!
```
I get the same output if I replace the `native` architecture choice with a concrete value, e.g. `61`, corresponding to that of a GPU on my system.
Artifacts:
* Project source file and CMake list file: [bug_25637.tar.gz](/uploads/005559aa43ff689857481c6dc7d71e69/bug_25637.tar.gz)
* Trace file: [`trace.log.gz`](/uploads/1a3fd8e4cce07af9709eb87ca9d2421d/trace.log.gz)
* Build dir: [build_dir.tar.gz](/uploads/104e516554028d6f168ca6c7e362e853/build_dir.tar.gz)
System info:
* Devuan GNU/Linux Excalibur (like Debian Trixie but without systemd)
* CMake 3.28.1 binary distribution
* X86_64 machine
* CUDA 12.2 installed under /usr/local/cudahttps://gitlab.kitware.com/cmake/cmake/-/issues/25632Does it make sense to interpret //path/to/somewhere as a network destination ...2024-01-24T08:49:32-05:00René BertinDoes it make sense to interpret //path/to/somewhere as a network destination on every platform?I ran into a "destrooting" error (intermediate install to $DESTDIR) because of a redundant initial `/` that slipped into my build scripts.
```
:info:destroot CMake Error at settings/cmake_install.cmake:49 (file):
:info:destroot file cal...I ran into a "destrooting" error (intermediate install to $DESTDIR) because of a redundant initial `/` that slipped into my build scripts.
```
:info:destroot CMake Error at settings/cmake_install.cmake:49 (file):
:info:destroot file called with network path DESTINATION. This does not make sense when
:info:destroot using DESTDIR. Specify local absolute path or remove DESTDIR environment
:info:destroot variable.
:info:destroot DESTINATION=
:info:destroot //Applications/MacPorts/KF5
```
As `/Applications/MacPorts` suggests, this is on a Mac system. I know that `//Applications` would be interpreted as a network file "opcode" on MS Windows (and used to be on Apollo Domain/OS) but this is not the case on any other current OS that I know of. Posix OSes will just ignore the redudant slash.
Yet in the code (https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Source/cmFileInstaller.cxx#L426) I see no attempt to handle this situation in a platform-specific manner.
Is there a point to that? How likely is it that someone would use the same build configuration (a DESTINATION starting with `//`) on MSWin and on Mac/Linux/... AND use DESTDIR to do a temporary/test install?
IMHO it does certainly NOT make sense to raise this error knowing that a non-temporary install (without the use of DESTDIR) will just let the OS handle `//path/to/somewhere` the normal way. If the error above is intended to protect users from unwanted/unforeseen platform-specific behaviour the direct install path should probably raise an error when a network destination is used on platforms that don't support them, no?!https://gitlab.kitware.com/cmake/cmake/-/issues/25630FindMatlab: Version mappings are incorrect for MCR2024-01-25T03:01:53-05:00Hermann von KleistFindMatlab: Version mappings are incorrect for MCRFor some reason, the guys at ~~Meth~~MathWorks decided to use different release/version mappings for MCR and Matlab.
Compare https://www.mathworks.com/support/requirements/previous-releases.html and https://www.mathworks.com/products/co...For some reason, the guys at ~~Meth~~MathWorks decided to use different release/version mappings for MCR and Matlab.
Compare https://www.mathworks.com/support/requirements/previous-releases.html and https://www.mathworks.com/products/compiler/matlab-runtime.html.
This gives `matlab_get_version_from_release_name` and `matlab_get_release_name_from_version` return wrong results when used with MCR.
I would at least add a note to the docs for 3.28.x and maybe add `matlab_get_mcr_version_from_release_name` and `matlab_get_mcr_release_name_from_version` for 3.29.https://gitlab.kitware.com/cmake/cmake/-/issues/25628Controlling dependency source2024-01-25T05:35:00-05:00Cristian LeControlling dependency sourceBefore or as part of addressing #22686, it would be useful to first allow the users to define dependency source globally and per project. I suggest the following:
- Add a `<Package>_PACKAGE_SOURCE` cache variable that contains one of: `...Before or as part of addressing #22686, it would be useful to first allow the users to define dependency source globally and per project. I suggest the following:
- Add a `<Package>_PACKAGE_SOURCE` cache variable that contains one of: `config`, `module`, `pkg-config`, `fetch_content`, `provider_<provider>`, `unknown`. This variable is set by the corresponding `find_package`, `FetchContent`, etc. commands
- Alternatively or in addition, add a `package` level properties, where the package is defined whenever it enters: `find_package(CONFIG)`, `Find<Package>.cmake`, `FetchContent_MakeAvailable`, `<provider>_provide_dependency`. This would be similar to `CMAKE_FIND_PACKAGE_NAME`, but more generalized
- Would be nice to have all targets within a "package" scope populate some target property to point back to the package that populated it
- Add `CMAKE_FIND_PACKAGE_MODE` and `CMAKE_FIND_<Package>_MODE` as control parameters to exclusively choose to use one mode. If no appropriate mode is defined, e.g. `FethcContent_Declare` is not defined, then return `<Package>_FOUND=False`. This will be an alternative/addition to `CMAKE_REQUIRE_FIND_PACKAGE_<Package>`
What do you guys think? What nuances am I missing here?https://gitlab.kitware.com/cmake/cmake/-/issues/25626shared library target properties: Please warn if people does weird thing with...2024-02-05T09:58:45-05:00Sune Stolborg Vuorelashared library target properties: Please warn if people does weird thing with VERSION and SOVERSIONIt seems that sometimes projects, either due to typos or not fully understanding things, sets up stuff like
```
add_library(Foo SHARED ....)
set_target_properties(Foo PROPERTIES VERSION 1.2.3 SOVERSION 4)
```
where SOVERSION does not m...It seems that sometimes projects, either due to typos or not fully understanding things, sets up stuff like
```
add_library(Foo SHARED ....)
set_target_properties(Foo PROPERTIES VERSION 1.2.3 SOVERSION 4)
```
where SOVERSION does not match the first component of VERSION.
While things still technically works, it is surprising.
It happens either because people changes one but not the other or because people put "project/release-version" in VERSION and not the actual versioning for the library.
Having CMake gently telling people that they have a typo or are doing something weird would be nice.https://gitlab.kitware.com/cmake/cmake/-/issues/25623CPack Deb: "file" command output needs escaping / filtering2024-01-23T09:09:16-05:00Julian WolffCPack Deb: "file" command output needs escaping / filteringWe install a resource file with file extension ".package".
When using CPack to create a debian package, the "file" command invoked [in CPackDeb.cmake line 171](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Modules/Internal/CPack...We install a resource file with file extension ".package".
When using CPack to create a debian package, the "file" command invoked [in CPackDeb.cmake line 171](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Modules/Internal/CPack/CPackDeb.cmake#L171) outputs something like this:
```
/path/to/my/file.package: Hewlett-Packard Graphics Language, starting with "PACKAGEFx\332\305V\333n\3338\020}\367W\214\363$\247]z\"
```
Note the `\"` at the end.
This seems to break CMake's list handling. The subsequent call to readelf passes a long list of files as the _FILE argument.
My local fix is to remove any string containing quotes from the "file" command output before appending it to CPACK_DEB_INSTALL_FILES:
```
string(REGEX MATCH "(^.*:[^\"]*)" INSTALL_FILE_ITEM_ "${INSTALL_FILE_}")
list(APPEND CPACK_DEB_INSTALL_FILES "${CMAKE_MATCH_1}")
```
I'm not sure if this would cause other issues.https://gitlab.kitware.com/cmake/cmake/-/issues/25622install(EXPORT ...) generates outdated configs2024-01-30T16:44:02-05:00Frank Danainstall(EXPORT ...) generates outdated configs`cmExportFileGenerator::GeneratePolicyHeaderCode()` generates boilerplate at the top of the file that configures support all the way back to CMake 2.8.3 (according to the `RequiredCMakeVersion{Major,Minor,Patch}` values currently set in ...`cmExportFileGenerator::GeneratePolicyHeaderCode()` generates boilerplate at the top of the file that configures support all the way back to CMake 2.8.3 (according to the `RequiredCMakeVersion{Major,Minor,Patch}` values currently set in `cmExportFileGenerator.h`).<sup>1</sup>
On the one hand, it does appear that the code generated is still compatible with CMake 2.8.3+, since it doesn't use any modern features at all.
OTOH, CMake itself is making moves to begin phasing out versions < 3.5. (Like the warning output when `cmake_minimum_required()` is passed a lower `VERSION` less than 3.5.) So, given that, does it make sense to keep including boilerplate for ancient versions? Or should it be advanced to something more recent, like 3.0 or 3.5? (This would also allow use of more recent features _in the future_, should opportunities arise.)
#### Notes
1. ...While claiming, in a comment, to "Support CMake versions as far back as 2.6" — which handily demonstrates why comments that describe code are bad.https://gitlab.kitware.com/cmake/cmake/-/issues/25620Mixing MSVC-like and GNU-like compiler frontends on Windows2024-03-11T08:46:11-04:00Brad KingMixing MSVC-like and GNU-like compiler frontends on WindowsWe currently have [this check](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Modules/Platform/Windows-Clang.cmake#L185-189) that all enabled languages' compilers use the same frontend command-line style: either all MSVC-like or a...We currently have [this check](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Modules/Platform/Windows-Clang.cmake#L185-189) that all enabled languages' compilers use the same frontend command-line style: either all MSVC-like or all GNU-like. The explicit enforcement provides an early diagnostic for users trying to mix these compilers because we don't currently support mixing them.
One of the main problems is that `CMAKE_EXE_LINKER_FLAGS` and friends are used on link lines for all languages. For MSVC-like compiler frontends we use `link.exe` to drive linking. For GNU-like compiler frontends we use the compiler to drive linking. The linker command-line fragments in `CMAKE_EXE_LINKER_FLAGS` and friends cannot work for both. This has been raised in a few places recently, including:
* #25598
* https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9107#note_1468168
* https://discourse.cmake.org/t/handling-of-linker-flags-inconsistent/9827
In order to support mixing frontend styles we need to know more about the flags in `CMAKE_EXE_LINKER_FLAGS` and friends. One possibility is to add `LINKER:` prefixes in that string as needed, but that will break existing use cases where the values of those variables are forwarded by projects to other build systems or scripts.
We need to consider alternative ways of expressing such platform-wide linker flags.https://gitlab.kitware.com/cmake/cmake/-/issues/25618Support emitting Index-Store for SourceKit-lsp2024-01-20T16:38:57-05:00Evan WildeSupport emitting Index-Store for SourceKit-lspThe IndexStore helps SourceKit-lsp provide an improved LSP experience. AppleClang, Clang from the Swift toolchain on other platforms, and the Swift compiler on all platforms support emitting an index database with the `-index-store-path`...The IndexStore helps SourceKit-lsp provide an improved LSP experience. AppleClang, Clang from the Swift toolchain on other platforms, and the Swift compiler on all platforms support emitting an index database with the `-index-store-path` flag. We can provide a mechanism for enabling and disabling emitting the index.
The index is useful for development and should not be installed. It can likely go somewhere in the `CMakeFiles` directory. SourceKit-lsp will read the index-store path from the exported `compile_commands.json`.
Thoughts for consideration:
- We could consider only emitting the index store flag if `CMAKE_EXPORT_COMPILE_COMMANDS` is set to true, but then toggling that variable would require a full rebuild to get the full LSP behavior, instead of just reconfiguring, which is odd.
- We could have this flag passed to any compiler that supports it at all times, but it has an impact on compile-times so we likely want to have a user-configurable option. A reasonable default is likely to enable it for Debug configurations and disable it otherwise (this matches what Swift-package-manager does). This option should be either enabled or disabled for all targets, so a target property does not make sense.