CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-11T10:17:04-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25741ctest: Commenting in files for --tests-from-file or --exclude-from-file is am...2024-03-11T10:17:04-04:00Craig Scottctest: Commenting in files for --tests-from-file or --exclude-from-file is ambiguousThe docs for the `--tests-from-file` and `--exclude-from-file` ctest options states the following:
> Lines can be commented out using a #
Looking at the code, the `#` must appear as the first character of the line for it to be treated ...The docs for the `--tests-from-file` and `--exclude-from-file` ctest options states the following:
> Lines can be commented out using a #
Looking at the code, the `#` must appear as the first character of the line for it to be treated as a comment (after all leading whitespace has been stripped). While one reading of the above would be consistent with that, there's enough prior art in other languages for being able to put `#` at the end of a line after some contents to append a comment to it, and I'd expect a proportion of CMake users would intuitively expect that to work here too.
As a counter-argument, since CMake 3.19, we allow arbitrary characters in test names. This means a test name could conceivably contain, or even start with, a `#` character. We could document this as a limitation of `--tests-from-file` and `--exclude-from-file`. If we want to be conservative, we could make it clear that we only support comments using `#` at the start of a line, and we don't support test names that start with `#`.
We should probably also explicitly state that leading and trailing whitespace on each line is stripped. Technically, a test name could start or end with whitespace, but I think we should not attempt to support that here but maybe could document it as a limitation for completeness. Alternatively, we could not strip each line apart from the trailing newline character, but that's potentially going to trip up more people than just keeping the current behavior and documenting the limitation.
CC: @neundorf3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25740ctest: Missing file with --tests-from-file or --exclude-from-file is not a fa...2024-03-08T09:28:50-05:00Craig Scottctest: Missing file with --tests-from-file or --exclude-from-file is not a fatal errorWhen running ctest, if the file listed with either `--tests-from-file` or `--exclude-from-file` doesn't exist, a warning is printed but ctest runs anyway. This should be a fatal error, as it could result in running tests that were not in...When running ctest, if the file listed with either `--tests-from-file` or `--exclude-from-file` doesn't exist, a warning is printed but ctest runs anyway. This should be a fatal error, as it could result in running tests that were not intended to be run, and that could be destructive if tests do something that modifies system state (e.g. stop a server or running process).
CC: @neundorf3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25739ctest: No way to run ctest in parallel and let a job server determine the upp...2024-03-11T10:18:57-04:00Craig Scottctest: No way to run ctest in parallel and let a job server determine the upper limitWith the new job server support added in !9021, ctest now detects when it is running under a job server and will coordinate with that job server when it launches new tests. But running ctest in parallel requires that you specify an upper...With the new job server support added in !9021, ctest now detects when it is running under a job server and will coordinate with that job server when it launches new tests. But running ctest in parallel requires that you specify an upper limit on the number of jobs, and in this case, it would be reasonable for the user to want to let that be determined by the job server instead.
There's currently no way to tell ctest to run in parallel without specifying an upper limit on the number of jobs. Perhaps we could allow the `-j` or `--parallel` option to be given without a value to support this use case? We could consider making that an error if ctest is not being run under a job server, or we could just put the onus on the user not to do something silly, which is the approach that tools like `make` have taken when allowing `-j` without a value. We already support the "no value" case with `cmake --build`, so there's precedent for it.
We would also need to consider the `CTEST_PARALLEL_LEVEL` environment variable. It should be handled consistently, either supporting 0 as a special value, or allowing it to be defined but empty.3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25711FindOpenMP: Fails using Intel compilers (icl/icx) using CMAKE 3.29.0-rc22024-02-26T10:17:22-05:00Eirik MarthinsenFindOpenMP: Fails using Intel compilers (icl/icx) using CMAKE 3.29.0-rc2When upgrading CMake from 3.28 to 3.29.0-rc2 I am not able to find OpenMP when using The Intel compilers (icl/icx) on Windows.
The reason seems to be commit 3019af64. I have tried to use CMake 3.29.0-rc2 and just replace the FindOpenMP....When upgrading CMake from 3.28 to 3.29.0-rc2 I am not able to find OpenMP when using The Intel compilers (icl/icx) on Windows.
The reason seems to be commit 3019af64. I have tried to use CMake 3.29.0-rc2 and just replace the FindOpenMP.cmake file from 3.28 in the CMake installation and it fixes the problem. That commit is the only difference between the two versions.
Steps to reproduce:
Using the following CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.20)
project(OpenMPTest LANGUAGES CXX)
message(STATUS "CMAKE_CXX_COMPILER_ID : ${CMAKE_CXX_COMPILER_ID}")
message(STATUS "CMAKE_CXX_COMPILER_VERSION: ${CMAKE_CXX_COMPILER_VERSION}")
message(STATUS "CMAKE_CXX_SIMULATE_ID : ${CMAKE_CXX_SIMULATE_ID}")
find_package(OpenMP REQUIRED)
if(OpenMP_CXX_FOUND)
message(STATUS "OpenMP_CXX_FOUND : ${OpenMP_CXX_FOUND}")
message(STATUS "OpenMP_CXX_VERSION: ${OpenMP_CXX_VERSION}")
message(STATUS "OpenMP_CXX_FLAGS : ${OpenMP_CXX_FLAGS}")
endif()
```
If I use CMake 3.28 I get the following output:
```
> cmake -B build-icl -S . -G Ninja -DCMAKE_CXX_COMPILER=icl
-- The CXX compiler identification is Intel 2021.10.0.20230609
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/intel64/icl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX_COMPILER_ID : Intel
-- CMAKE_CXX_COMPILER_VERSION: 2021.10.0.20230609
-- CMAKE_CXX_SIMULATE_ID : MSVC
-- Found OpenMP_CXX: -Qopenmp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
-- OpenMP_CXX_FOUND : TRUE
-- OpenMP_CXX_VERSION: 5.0
-- OpenMP_CXX_FLAGS : -Qopenmp
-- Configuring done (18.6s)
-- Generating done (0.0s)
-- Build files have been written to: C:/dev/test/build-icl
> cmake -B build-icx -S . -G Ninja -DCMAKE_CXX_COMPILER=icx
-- The CXX compiler identification is IntelLLVM 2023.2.0 with MSVC-like command-line
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icx.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX_COMPILER_ID : IntelLLVM
-- CMAKE_CXX_COMPILER_VERSION: 2023.2.0
-- CMAKE_CXX_SIMULATE_ID : MSVC
-- Found OpenMP_CXX: -Qiopenmp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
-- OpenMP_CXX_FOUND : TRUE
-- OpenMP_CXX_VERSION: 5.0
-- OpenMP_CXX_FLAGS : -Qiopenmp
-- Configuring done (21.8s)
-- Generating done (0.0s)
-- Build files have been written to: C:/dev/test/build-icx
```
While Using CMake 3.29.0-rc2 gives the following error:
```
> cmake -B build-icl -S . -G Ninja -DCMAKE_CXX_COMPILER=icl
-- The CXX compiler identification is Intel 2021.10.0.20230609
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/intel64/icl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX_COMPILER_ID : Intel
-- CMAKE_CXX_COMPILER_VERSION: 2021.10.0.20230609
-- CMAKE_CXX_SIMULATE_ID : MSVC
CMake Error at C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.29/Modules/FindOpenMP.cmake:581 (find_package_handle_standard_args)
C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
CMakeLists.txt:7 (find_package)
-- Configuring incomplete, errors occurred!
> cmake -B build-icx -S . -G Ninja -DCMAKE_CXX_COMPILER=icx
-- The CXX compiler identification is IntelLLVM 2023.2.0 with MSVC-like command-line
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icx.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX_COMPILER_ID : IntelLLVM
-- CMAKE_CXX_COMPILER_VERSION: 2023.2.0
-- CMAKE_CXX_SIMULATE_ID : MSVC
CMake Error at C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.29/Modules/FindOpenMP.cmake:581 (find_package_handle_standard_args)
C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
CMakeLists.txt:7 (find_package)
-- Configuring incomplete, errors occurred!
```3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25710Swift: CMake 3.29.0-rc1 fails to produce working Swift macro executables2024-02-26T10:19:27-05:00Evan WildeSwift: CMake 3.29.0-rc1 fails to produce working Swift macro executablesThe macro executables produced when CMake 3.29.0-rc1 CMP0157 is set to `NEW` don't have the correct module name associated with them.
The Swift macro executable builds, but is invalid when someone tries to use it:
```
SwiftCMakeMacroTes...The macro executables produced when CMake 3.29.0-rc1 CMP0157 is set to `NEW` don't have the correct module name associated with them.
The Swift macro executable builds, but is invalid when someone tries to use it:
```
SwiftCMakeMacroTest/hello.swift:4:7: error: macro implementation type 'MacroTestMacros.StringifyMacro' could not be found in executable plugin 'SwiftCMakeMacroTest/build/MacroTestMacros-prefix/src/MacroTestMacros-build/MacroTestMacros'
```
When the CMP0157 is set to `OLD` or when using CMake 3.28, the macro works as expected.3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25702find_package OpenSSL can't find version 3.0.13 on windows2024-02-26T10:18:24-05:00Matthias Iselefind_package OpenSSL can't find version 3.0.13 on windows* Using the recommended installer on windows from https://slproweb.com/products/Win32OpenSSL.html (referenced in FindOpenSSL.cmake)
* run CMake find_package(OpenSSL)
* CMake can't find the installed OpenSSL libraries
* affects OpenSSL ve...* Using the recommended installer on windows from https://slproweb.com/products/Win32OpenSSL.html (referenced in FindOpenSSL.cmake)
* run CMake find_package(OpenSSL)
* CMake can't find the installed OpenSSL libraries
* affects OpenSSL version 3.0.13
* the reason is that "Shining Light Productions" changed the folder structure of the installed libraries
* according to the maintainer of the setup the new folder structure will be kept for the future3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/256793.29.0-rc1: librhash 1.4.4 breaks build with GLIBC<2.152024-02-15T12:53:24-05:00Matias Lopez3.29.0-rc1: librhash 1.4.4 breaks build with GLIBC<2.15Began testing the new release and we didn't get past building CMake itself. It errored with
```log
2024/02/14 08:05:52 ERROR /opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: rhash-librhash-rhash.c.o: in function `rh...Began testing the new release and we didn't get past building CMake itself. It errored with
```log
2024/02/14 08:05:52 ERROR /opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: rhash-librhash-rhash.c.o: in function `rhash_alloc_multi':
2024/02/14 08:05:52 ERROR rhash.c:(.text+0x1b8): undefined reference to `aligned_alloc'
2024/02/14 08:05:52 ERROR /opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: rhash-librhash-rhash.c.o: in function `rhash_file_update':
2024/02/14 08:05:52 ERROR rhash.c:(.text+0xcba): undefined reference to `aligned_alloc'
```
`aligned_alloc` was added in C11 and [supported by GLIBC 2.15+](https://www.gnu.org/software/gnulib/manual/html_node/aligned_005falloc.html), RHEL 6 ships with GLIBC 2.14 and hence won't build this.
I found that this call is an optimisation that not all platforms use [here](https://gitlab.kitware.com/cmake/cmake/-/commit/54eafb156f46badce53c3b443ec11824cef5f55b) and perhaps it's worth to add a check against GLIBC 2.153.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25675Static linking with IPO/LTO doesn't properly support object files with the sa...2024-02-16T09:48:51-05:00Aaron BaranyStatic linking with IPO/LTO doesn't properly support object files with the same filenameThe ARCHIVE variables used for IPO (e.g. `CMAKE_CXX_ARCHIVE_CREATE_IPO`, `CMAKE_CXX_ARCHIVE_APPEND_IPO`) use the "r", or "replace", option to combine the archives rather than the "q", or "quick append". Since the `ar` tool only takes the...The ARCHIVE variables used for IPO (e.g. `CMAKE_CXX_ARCHIVE_CREATE_IPO`, `CMAKE_CXX_ARCHIVE_APPEND_IPO`) use the "r", or "replace", option to combine the archives rather than the "q", or "quick append". Since the `ar` tool only takes the object file's filename without taking into account the parent directory, any object files with the same filename in different directories (e.g. `foo/Baz.cpp.o` and `bar/Baz.cpp.o`) may be silently overwritten when using the "r" option. The replacement logic often only happens when the archiving needs to be split into multiple calls to `ar`, such as with a large number of object files. (e.g. `foo/Baz.cpp.o` appears in the first call to `ar`, and `bar/Baz.cpp.o` appears in the second call) When this situation occurs, the object files that were replaced result in undefined symbol errors when linking the final static library.
For example, under `/usr/share/cmake/Modules/CMakeCXXInformation.cmake`, it will set the following values that *do* support multiple object files with the same filename when *not* using IPO:
```
set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_APPEND "<CMAKE_AR> q <TARGET> <LINK_FLAGS> <OBJECTS>")
```
However, the compiler-specific IPO variables, such as `/usr/share/cmake/Modules/Compiler/GNU.cmake`, use "r" in place of "q".
```
set(CMAKE_${lang}_ARCHIVE_CREATE_IPO
"\"${CMAKE_${lang}_COMPILER_AR}\" cr <TARGET> <LINK_FLAGS> <OBJECTS>"
)
set(CMAKE_${lang}_ARCHIVE_APPEND_IPO
"\"${CMAKE_${lang}_COMPILER_AR}\" r <TARGET> <LINK_FLAGS> <OBJECTS>"
)
```
In order to work around this issue, projects must manually set the `CMAKE_${lang}_ARCHIVE_*_IPO` variables.3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/256743.29.0-rc1: cmake_language(EXIT) does not work inside control flow2024-02-15T12:58:02-05:00scivision3.29.0-rc1: cmake_language(EXIT) does not work inside control flowhttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8228 added `cmake_language(EXIT code)`
BUG: `cmake_language(EXIT code)` statement does not terminate the script as specified in the
[docs](https://cmake.org/cmake/help/latest/comm...https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8228 added `cmake_language(EXIT code)`
BUG: `cmake_language(EXIT code)` statement does not terminate the script as specified in the
[docs](https://cmake.org/cmake/help/latest/command/cmake_language.html#terminating-scripts) when the command is mixed in with other CMake script logic like `if()`.
This unexpected behavior occurs with CMake 3.29.0-rc1 and nightly e.g.`3.29.20240212`
## unexpected mixed with if()
Example file "exit.cmake":
```cmake
cmake_minimum_required(VERSION 3.29)
message(STATUS "CMake ${CMAKE_VERSION}")
option(hi "")
if(hi)
message(STATUS "true")
cmake_language(EXIT 77)
else()
message(STATUS "false")
cmake_language(EXIT 75)
endif()
cmake_language(EXIT 76)
```
```sh
$ cmake -Dhi=true -P exit.cmake || echo $?
-- CMake 3.29.20240212-g063469e
-- true
76
```
```sh
$ cmake -Dhi=no -P exit.cmake || echo $?
-- CMake 3.29.20240212-g063469e
-- false
76
```
```sh
cmake -P exit.cmake --trace || echo $?
Put cmake in trace mode.
exit.cmake(1): cmake_minimum_required(VERSION 3.29 )
exit.cmake(3): message(STATUS CMake ${CMAKE_VERSION} )
-- CMake 3.29.20240212-g063469e
exit.cmake(5): option(hi )
exit.cmake(7): if(hi )
exit.cmake(10): else()
exit.cmake(11): message(STATUS false )
-- false
exit.cmake(12): cmake_language(EXIT 75 )
exit.cmake(15): cmake_language(EXIT 76 )
76
```
## unexpected mixed with block()
```cmake
cmake_minimum_required(VERSION 3.29)
block()
cmake_language(EXIT 77)
endblock()
cmake_language(EXIT 76)
```
```sh
$ cmake -P block.cmake || echo $?
76
```
## unexpected foreach()
while.cmake:
```cmake
cmake_minimum_required(VERSION 3.29)
foreach(i RANGE 3)
cmake_language(EXIT ${i})
message(STATUS "Should have already exited code ${i}")
endforeach()
message(FATAL_ERROR "Should have already exited")
```
```sh
$ cmake -P while.cmake --trace
Put cmake in trace mode.
while.cmake(1): cmake_minimum_required(VERSION 3.29 )
while.cmake(3): foreach(i RANGE 3 )
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(STATUS Should have already exited code ${i} )
-- Should have already exited code 0
while.cmake(7): message(STATUS Should have already exited code ${i} )
-- Should have already exited code 1
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(STATUS Should have already exited code ${i} )
-- Should have already exited code 2
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(STATUS Should have already exited code ${i} )
-- Should have already exited code 3
while.cmake(11): message(FATAL_ERROR Should have already exited )
CMake Error at while.cmake:11 (message):
Should have already exited
```
## foreach() with SEND_ERROR
This also behaves unexpected
```cmake
cmake_minimum_required(VERSION 3.29)
foreach(i RANGE 3)
cmake_language(EXIT ${i})
message(SEND_ERROR "Should have already exited code ${i}")
endforeach()
```
```sh
cmake -P while.cmake --trace
Put cmake in trace mode.
while.cmake(1): cmake_minimum_required(VERSION 3.29 )
while.cmake(3): foreach(i RANGE 3 )
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(SEND_ERROR Should have already exited code ${i} )
CMake Error at while.cmake:7 (message):
Should have already exited code 0
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(SEND_ERROR Should have already exited code ${i} )
CMake Error at while.cmake:7 (message):
Should have already exited code 1
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(SEND_ERROR Should have already exited code ${i} )
CMake Error at while.cmake:7 (message):
Should have already exited code 2
while.cmake(5): cmake_language(EXIT ${i} )
while.cmake(7): message(SEND_ERROR Should have already exited code ${i} )
CMake Error at while.cmake:7 (message):
Should have already exited code 3
$ echo $?
1
```
## additional test
The CMake self-test code does work as expected--there must be some unexpected behavior when `cmake_language(EXIT code)` is mixed with other CMake script logic (like if()).
```cmake
cmake_language(EXIT 7)
message(FATAL_ERROR "The include()-d script with EXIT 7 doesn't work")
```
```sh
$ cmake -P fatal.cmake || echo $?
7
```3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25634CPack/WiX: Windows installer status strings broken2024-01-25T10:33:15-05:00Mark WatermanCPack/WiX: Windows installer status strings brokenProgress messages in the Windows installer are only displaying a format string in recent versions of Windows:
![cmake_installer](/uploads/34a1048e6a4237010f3df89bccf3deed/cmake_installer.png)
This is a known issue with WIX that started...Progress messages in the Windows installer are only displaying a format string in recent versions of Windows:
![cmake_installer](/uploads/34a1048e6a4237010f3df89bccf3deed/cmake_installer.png)
This is a known issue with WIX that started with the Windows 10 Creators Update, circa 2017. Should be easy to fix: add the following element under the WIX script's <Product> tag:
`<UIRef Id="WixUI_ErrorProgressText" />`
See also: https://stackoverflow.com/questions/44161526/wix-copying-new-files-file-1-directory-9-size-6-shown-during-instal3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25615CPack/RPM: [PATCH] Fix CPACK_THREADS variable usage2024-01-24T08:39:59-05:00Elijah ZarezkyCPack/RPM: [PATCH] Fix CPACK_THREADS variable usage```
diff -up cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake
--- cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig 2023-11-28 17:52:37.000000000 +0300
+++ cmake-3.27.9/Modu...```
diff -up cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake
--- cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake.orig 2023-11-28 17:52:37.000000000 +0300
+++ cmake-3.27.9/Modules/Internal/CPack/CPackRPM.cmake 2024-01-18 11:00:25.592770537 +0300
@@ -1031,7 +1031,11 @@ function(cpack_rpm_generate_package)
set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w9.lzdio")
endif()
if(CPACK_RPM_COMPRESSION_TYPE STREQUAL "xz")
- set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w7.xzdio")
+ if(CPACK_THREADS GREATER "0")
+ set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w7T${CPACK_THREADS}.xzdio")
+ else()
+ set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w7T.xzdio")
+ endif()
endif()
if(CPACK_RPM_COMPRESSION_TYPE STREQUAL "bzip2")
set(CPACK_RPM_COMPRESSION_TYPE_TMP "%define _binary_payload w9.bzdio")
```3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25614cxxmodules: fails with extra ./ in path using Ninja and CMake 3.282024-02-15T12:54:45-05:00Theo Pariscxxmodules: fails with extra ./ in path using Ninja and CMake 3.28Ninja version: `1.11.1`
CMake version: `3.28.20240118-gbef9f09`
Clang version: `17` and `18` (git)
https://gitlab.kitware.com/theoparis/cxx-modules-issue
Error:
```
CMake Error in CMakeLists.txt:
Target "reproduction" has source fi...Ninja version: `1.11.1`
CMake version: `3.28.20240118-gbef9f09`
Clang version: `17` and `18` (git)
https://gitlab.kitware.com/theoparis/cxx-modules-issue
Error:
```
CMake Error in CMakeLists.txt:
Target "reproduction" has source file
/home/theo/repro/./src/module.cpp
in a "FILE_SET TYPE CXX_MODULES" but it is not scheduled for compilation.
```
I realized after making the repository that `export module module` is not the best naming-wise and that I should've used add_executable. I was following [this post on kitware.com by the way](https://www.kitware.com/import-cmake-the-experiment-is-over/).3.29.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25603gtest_discover_tests(): Honor TEST_LAUNCHER when obtaining test list2024-02-06T15:00:36-05:00Craig Scottgtest_discover_tests(): Honor TEST_LAUNCHER when obtaining test listOriginally raised in the forums here: https://discourse.cmake.org/t/wrapping-tests-discovered-by-gtest-discover-tests-into-a-wrapper/9852/2
The `gtest_discover_tests()` command runs the test executable with options to ask it to provide ...Originally raised in the forums here: https://discourse.cmake.org/t/wrapping-tests-discovered-by-gtest-discover-tests-into-a-wrapper/9852/2
The `gtest_discover_tests()` command runs the test executable with options to ask it to provide the list of tests it defines. !8963 added a new `TEST_LAUNCHER` test property, which allows projects to wrap the test executable. It may be desirable for that test launcher to also be used when running the test discovery step in `gtest_discover_tests()`. Depending on what the test launcher does, this might even be necessary.
One complication is that the test discovery can be done as either a `POST_BUILD` step at build time, or as a `PRE_TEST` step at test time. It seems wrong to use a test launcher for `POST_BUILD`, but right to use one for `PRE_TEST`. Potentially we could consider using `TEST_LAUNCHER` only for the `PRE_TEST` case and not for `POST_BUILD`.
It is worth comparing against the behavior of the `CROSSCOMPILING_EMULATOR` target property. This is honoured during test discovery, for both `POST_BUILD` and `PRE_TEST`. However, `CROSSCOMPILING_EMULATOR` is a target property, not a test property, so that still makes sense to use it for `POST_BUILD`.3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25593Modules/Compiler/ADSP-ASM.cmake file is in the repo. missing in the release 3...2024-01-16T11:19:07-05:00Mohan YModules/Compiler/ADSP-ASM.cmake file is in the repo. missing in the release 3.28.1<!--
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 would like to point out that Modules/Compiler/ADSP-ASM.cmake file is in the repo, but missing in the release 3.28.1
we are facing issues in moving from 3.12 to 3.28.1 because of this.
I would be great if this can be include in the next release. Thank you.3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25583FindVulkan: glslang removed target OGLCompiler2024-02-08T09:45:08-05:00moritz-hFindVulkan: glslang removed target OGLCompilerThe glslang component of FindVulkan explicity checks for the existence of a target called `OGLCompiler`.
But that target was removed with glslang 14.0.0, see release notes: https://github.com/KhronosGroup/glslang/releases/tag/14.0.0.
Thi...The glslang component of FindVulkan explicity checks for the existence of a target called `OGLCompiler`.
But that target was removed with glslang 14.0.0, see release notes: https://github.com/KhronosGroup/glslang/releases/tag/14.0.0.
This breaks using the glslang component of FindVulkan on a glslang 14 installation.3.29.0Juan RamosJuan Ramoshttps://gitlab.kitware.com/cmake/cmake/-/issues/25561execute_process: cmExecuteProcessCommandFixText() for UTF-8 output causes ass...2024-01-17T10:07:07-05:00Alexexecute_process: cmExecuteProcessCommandFixText() for UTF-8 output causes assertion failures on Windows due to isspace() usageI accidentally caught this bug while working on !8228 .
if the child process would generate some UTF-8 output, the cmExecuteProcessCommandFixText()'s logic related to whitespace trimming would fail with the assertion error (on debug bui...I accidentally caught this bug while working on !8228 .
if the child process would generate some UTF-8 output, the cmExecuteProcessCommandFixText()'s logic related to whitespace trimming would fail with the assertion error (on debug builds):
<details>
<summary>Message box with error</summary>
![message box image](/uploads/3fcee74882b8b21d1a5fcf4fe49b8d6b/изображение.png)
</details>
In my case, the guilty text was localized text from MSVC linker (There is a text after "decoding" it via online mojibakes decoder (in short, it complains that the entry point is not set for linker, the object files are not defined, the `/MACHINE` parameter is not set, so we use the X64, and the `/v` flag is not recognized):
<details><summary>Decoded text</summary>
```
Microsoft (R) Incremental Linker Version 14.39.33321.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : warning LNK4044: нераспознанный параметр "/v"; игнорируется
LINK : warning LNK4001: не указаны объектные файлы; использованы библиотеки
LINK : warning LNK4068: параметр /MACHINE не указан; принимается по умолчанию на X64
LINK : fatal error LNK1561: точка входа должна быть определена
```
</details>
The root cause is this code snippet (https://gitlab.kitware.com/cmake/cmake/-/blob/1f66051983ef0bdefa5de139fa9013830a4c3047/Source/cmExecuteProcessCommand.cxx#L379):
```cpp
// Fix the text in the output strings.
cmExecuteProcessCommandFixText(outputData.Output,
arguments.OutputStripTrailingWhitespace);
cmExecuteProcessCommandFixText(errorData.Output,
arguments.ErrorStripTrailingWhitespace);
```
It calls this function:
```
bool cmExecuteProcessCommandIsWhitespace(char c)
{
return (isspace(static_cast<int>(c)) || c == '\n' || c == '\r');
}
```
which uses the `isspace()` C standard library function , which is tied to locale and, in general, don't work robustly as the locale machinery is implementation defined.
As for MSVC this function may forward the char as signed (which could be converted to signed int, in my case it was the "degrees mark" ('°'), and their code was '-80' in debugger, so the `isspace()`'s assertion about char ranges has been failed.
As a workaround we may add additional cast to unsigned char, and cast this to int (the old hack), but I consider to avoid the isspace() completely as it may not know about UTF-8 specific whitespace chars.
I would try to make a PR with the additional cast to unsigned char to avoid the assertion failure on debug builds on Windows.
Thanks for your attention and sorry for some bad English3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25536CUDA::cuda_driver soname2024-01-17T09:06:43-05:00SomeoneCUDA::cuda_driver soname<!--
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! I'm experiencing soname mismatch issues trying to link a target that transitively depends on `CUDAToolkit::cuda_driver`, when using the stub driver library at build time.
#### Context
At least in Nixpkgs, when building a package that asks to link `libcuda.so` directly, we build it against the stub libraries distributed by nvidia together with cudart:
```bash
❯ tar -tJf - < <(wget -O- -q https://developer.download.nvidia.com/compute/cuda/redist/cuda_cudart/linux-x86_64/cuda_cudart-linux-x86_64-11.8.89-archive.tar.xz) | grep libcuda.so
cuda_cudart-linux-x86_64-11.8.89-archive/lib/stubs/libcuda.so
```
We later strip and substiute the runpaths so as to look up the driver in a dedicated impure location.
CMake recording `libcuda.so.1` in `DT_NEEDED` rather than `libcuda.so` presents us a problem in that there's no versioned soname in the upstream's tarball and we can't (won't) allow the build to see the real driver. We could maybe take the burden of generating the symlinks, but I'd like to verify there isn't an error happening in the previous steps
An example of where we encounter this issue: https://github.com/ggerganov/llama.cpp/pull/4606/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR305-R306
```
llama-cpp-cuda-f08e03e-dirty> : && /nix/store/...-gcc-wrapper-11.4.0/bin/g++ -O3 -DNDEBUG tests/CMakeFiles/test-tokenizer-0-falcon.dir/test-tokenizer-0-falcon.cpp.o -o bin/test-tokenizer-0-falcon common/libcommon.a libllama.so && :
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: warning: libcuda.so.1, needed by libllama.so, not found (try using -rpath or -rpath-link)
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuMemCreate'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuMemAddressReserve'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuMemSetAccess'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuDeviceGet'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuGetErrorString'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuDeviceGetAttribute'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuMemMap'
llama-cpp-cuda-f08e03e-dirty> /nix/store/...-binutils-2.40/bin/ld: libllama.so: undefined reference to `cuMemGetAllocationGranularity'
llama-cpp-cuda-f08e03e-dirty> collect2: error: ld returned 1 exit status
```
https://gist.github.com/SomeoneSerge/c93b43b19607a9217ddb79d26b0f7d77
Thanks
CC @robertmaynard3.29.0https://gitlab.kitware.com/cmake/cmake/-/issues/25526Missing order-only dependencies cause samurai error2024-01-09T10:52:47-05:00Alex XuMissing order-only dependencies cause samurai error```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.28)
project(ProjectName)
add_library(objectlib OBJECT /dev/null)
set_target_properties(objectlib PROPERTIES LINKER_LANGUAGE CXX)
add_library(lib empty.cc)
add_dependencies(lib ob...```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.28)
project(ProjectName)
add_library(objectlib OBJECT /dev/null)
set_target_properties(objectlib PROPERTIES LINKER_LANGUAGE CXX)
add_library(lib empty.cc)
add_dependencies(lib objectlib)
$ echo > empty.cc
$ cmake -G Ninja .
[ ... ]
$ samu
samu: file is missing and not created by any action: 'CMakeFiles/objectlib.dir'
$ ls -l CMakeFiles/objectlib.dir
ls: cannot access 'CMakeFiles/objectlib.dir': No such file or directory
$ grep CMakeFiles/objectlib.dir build.ninja
build cmake_object_order_depends_target_objectlib: phony || CMakeFiles/objectlib.dir
$ rm -r CMakeCache.txt CMakeFiles
$ sed -i -e 's:/dev/null:empty.cc:' CMakeLists.txt
$ cmake -G Ninja .
[ ... ]
$ ls -al CMakeFiles/objectlib.dir
total 0
drwxr-xr-x 2 alex alex 40 Dec 20 17:15 .
drwxr-xr-x 7 alex alex 220 Dec 20 17:15 ..
$ samu
[1/3] Building CXX object CMakeFiles/lib.dir/empty.cc.o
[2/3] Building CXX object CMakeFiles/objectlib.dir/empty.cc.o
[3/3] Linking CXX static library liblib.a
$ cmake --version
cmake version 3.28.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ samu --version
1.9
```
It appears that CMake skips creating object directories if no files are planned to be put there, but still adds an order-only dependency. The ninja documentation does not specify the behavior if order-only dependencies don't exist and can't be made; the reference implementation ignores it, but samurai issues an error. I would argue this is a bug in CMake, not samurai, for several reasons:
1. The order-only dependency is actually built if a rule exists. "order-only" refers to the behavior when the dependency exists but is newer than the target, not the behavior when it doesn't exist.
2. As far as I can tell, unbuildable order-only dependencies are useless.
3. Order-only dependencies (probably) come from GNU make, which also issues an error:
```
$ cat Makefile
b: | a
$ make
make: *** No rule to make target 'a', needed by 'b'. Stop.
$ make --version
GNU Make 4.4.1
```
By my reckoning, CMake shouldn't emit order-only dependencies without a rule to create the dependency.3.29.0Ben BoeckelBen Boeckelhttps://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/25478MSVC: Finding libraries named ${name}.dll.lib generated by rustc/cargo/cargo-c2023-12-09T08:12:00-05:00Daniel ChingMSVC: Finding libraries named ${name}.dll.lib generated by rustc/cargo/cargo-cThe Windows platform has three types of libraries: static, dynamic, and import. Unfortunately, the suffix for static and import libraries is the same (`.lib`). Various unofficial approaches are used to resolve this ambiguity by changing ...The Windows platform has three types of libraries: static, dynamic, and import. Unfortunately, the suffix for static and import libraries is the same (`.lib`). Various unofficial approaches are used to resolve this ambiguity by changing the names of either static or import libraries to indicate which one they are. For an example library named `foo`, MESON uses the `libfoo.a` for static libraries or `libfoo.dll.a` for import libraries depending on the compiler toolchain, some projects name their static libraries `foo_static.lib`, and in the case of the Rust toolchain, they have chosen to name the import library `foo.dll.lib` or `foo.dll.a` depending on the host compiler.
I'd like to add support for these `.dll.lib` suffixes for import libraries, so that finding libraries built with cargo-c / the rust toolchain has less friction.
I believe this would involve adding `.dll.lib` to the default list of `CMAKE_FIND_LIBRARY_SUFFIXES` when `WIN32 AND NOT MINGW`, but I'm not exactly sure in which file I should add it. I'd be happy to open a PR if y'all are interested in this improvement and can point me to the correct file.
https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa
https://github.com/rust-lang/cargo/blob/a5fa676731c8e570bb9be9c50d2202acea84b6b6/src/cargo/core/compiler/build_context/target_info.rs#L3893.29.0