CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-02-26T10:18:24-05:00https://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/25699Documentation misinformation on BUILD_SHARED_LIBS2024-02-21T09:33:53-05:00Jim BDocumentation misinformation on BUILD_SHARED_LIBSThis documentation seems to cause users to cause bad behaviors (and maybe it's my fault for including other projects CMakeLists with add_subdirectory instead of ExternalProject).
https://cmake.org/cmake/help/latest/variable/BUILD_SHARED...This documentation seems to cause users to cause bad behaviors (and maybe it's my fault for including other projects CMakeLists with add_subdirectory instead of ExternalProject).
https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html
"Global flag to cause add_library() to create shared libraries if on.
If present and true, this will cause all libraries to be built shared unless the library was explicitly added as a static library. This variable is often added to projects as an option() so that each user of a project can decide if they want to build the project using shared or static libraries."
I don't use this Option, but this impacts all projects. LibreSSL doesn't have the option() specified, so it uses whatever is set. By default this is unset, so the library builds statically, which it has been doing until today. I added LibSSH2, which does define `option(BUILD_SHARED_LIBS "Build Shared Libraries" ON)` which now LibreSSL is building as shared by default.
(this also indicates that one should set this as an option)
https://cmake.org/cmake/help/latest/guide/tutorial/Selecting%20Static%20or%20Shared%20Libraries.html
I also do not find a page for BUILD_STATIC_LIBS which I would assume would be `https://cmake.org/cmake/help/latest/variable/BUILD_STATIC_LIBS.html` which libssh and libssh2 both seems to think exists.
I was going to issue a bug report to libssh2 to not define these as options, since it ends up affecting everything in the whole project, and not just themselves... but from your documentation it implies they should.https://gitlab.kitware.com/cmake/cmake/-/issues/25698error: source file is not valid UTF-82024-02-21T08:18:39-05:00Jiri Zaloudekerror: source file is not valid UTF-8Hello,
so the situation is:
from Win10 64 I run Virtual Machine where the guest is MacOS,
From Win10 I share a folder with all projects (sources as well as builds folders).
When opening projects and run Cmake which creates build folder ...Hello,
so the situation is:
from Win10 64 I run Virtual Machine where the guest is MacOS,
From Win10 I share a folder with all projects (sources as well as builds folders).
When opening projects and run Cmake which creates build folder on guest macOS, all is fine,
when the Cmake creates build folder on host shared folder location, it gives an error:
`error: source file is not valid UTF-8`
to me, I think this is the false report, the cmake from macOS creates the build files itself, so its not reading any files from another drive (even virtualy shared).
Attached you can see all files form build directory created from guest to host virtualy shared folder
[cmake_bug_encoding.zip](/uploads/581eb511dcd17bd756c8ae161564c3dc/cmake_bug_encoding.zip)
I tries with CMake 3.27.7, but same applies for 3.24.4
PS: what is REALY interested, that if I configure the project to real iOS device, then CMake wiill handle fine without this error.
But when I configure the project for iOS Simulator, this error appears
I have checked with QT Support, and we discovered this is CMake topic rather then QT topic
Is there anything which can be done from Cmake side? to somehow force creating UTF8 encoding?https://gitlab.kitware.com/cmake/cmake/-/issues/25696Unity build errors since 3.28.22024-02-22T08:26:17-05:00Jörg MüllerUnity build errors since 3.28.2Like #25650 we encountered this with O3DE since CMake 3.28.2, including CMake 3.29.0-rc1 (so !9215 doesn't fix it) on both Windows and Linux:
```
ninja: error: 'External/Compression-10c56b98/Code/CMakeFiles/Compression.Private.Object.di...Like #25650 we encountered this with O3DE since CMake 3.28.2, including CMake 3.29.0-rc1 (so !9215 doesn't fix it) on both Windows and Linux:
```
ninja: error: 'External/Compression-10c56b98/Code/CMakeFiles/Compression.Private.Object.dir/debug/Source/CompressionModuleInterface.cpp.o', needed by 'bin/debug/libCompression.Editor.so', missing and no known rule to make it
```
or with the default generator on Linux:
```
make[2]: *** No rule to make target 'External/Compression-300528aa/Code/CMakeFiles/Compression.Private.Object.dir/Source/CompressionModuleInterface.cpp.o', needed by 'bin/profile/libCompression.Editor.Tests.so'. Stop.
```
A couple of cpp files are apparently expected to build on their own, although they also appear in unity build files:
```
% grep -r CompressionModuleInterface.cpp External/*
External/Compression-10c56b98/Code/CMakeFiles/Compression.Private.Object.dir/Unity/unity_0_cxx.cxx:#include "code/Gems/Compression/Code/Source/CompressionModuleInterface.cpp"
```
I'm sorry that I cannot provide a minimal example, but the error happens immediately when the build is started with Ninja (with Makefiles it compiles a considerable amount of files before the error appears) after the following setup commands (on Linux):
```
git clone "https://github.com/o3de/o3de.git" code
mkdir build
cd code
git lfs install
git lfs pull
python/get_python.sh
cd ../build
cmake ../code -G "Ninja Multi-Config" -DLY_UNITY_BUILD=ON
cmake --build .
```3.28.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25693[cmake] [security] It is unsafe to search ld or other exctuable files from en...2024-02-21T08:12:37-05:00LittleBox-x[cmake] [security] It is unsafe to search ld or other exctuable files from env pathwe found cmake will try to find "ld" from env path,as shown below in ohos platfrom。Android platform is the same.
![image.png](/uploads/f2f6444cbd5ad648842caef6ea070ddd/image.png)
This behavior may trigger [DLL Hijacking](https://www.aq...we found cmake will try to find "ld" from env path,as shown below in ohos platfrom。Android platform is the same.
![image.png](/uploads/f2f6444cbd5ad648842caef6ea070ddd/image.png)
This behavior may trigger [DLL Hijacking](https://www.aquasec.com/blog/cve-2022-32223-dll-hijacking/), so we hope clang can resolve this security issuehttps://gitlab.kitware.com/cmake/cmake/-/issues/25691Setting QT_DEFAULT_MAJOR_VERSION to 6 doesn't select Qt6 over Qt52024-02-19T14:36:54-05:00yurivictSetting QT_DEFAULT_MAJOR_VERSION to 6 doesn't select Qt6 over Qt5This code:
```
cmake_minimum_required(VERSION 3.28)
cmake_policy(VERSION 3.28)
project(X)
set(QT_DEFAULT_MAJOR_VERSION 6)
find_package(QT NAMES Qt6 Qt5 REQUIRED COMPONENTS Core Gui Widgets LinguistTools)
find_package(Qt${QT_VERSION_MAJO...This code:
```
cmake_minimum_required(VERSION 3.28)
cmake_policy(VERSION 3.28)
project(X)
set(QT_DEFAULT_MAJOR_VERSION 6)
find_package(QT NAMES Qt6 Qt5 REQUIRED COMPONENTS Core Gui Widgets LinguistTools)
find_package(Qt${QT_VERSION_MAJOR} REQUIRED COMPONENTS Core Gui Widgets LinguistTools)
message(STATUS "QT Major Version: " ${QT_VERSION_MAJOR})
```
is supposed to select QT6 in the mixed Qt5/Qt6 environment, but it selects Qt5:
> -- QT Major Version: 5
```
$ cmake --version
cmake version 3.28.2
```
Qt-6.6.1 + Qt-5.15.11
clang-16
FreeBSD 14.0https://gitlab.kitware.com/cmake/cmake/-/issues/25685CMake-generated Xcode project can't be tested with xcodebuild2024-02-27T16:08:39-05:00Dave AbrahamsCMake-generated Xcode project can't be tested with xcodebuildI have a project where a cmake-generated Xcode project can be tested from within Xcode, but not using xcodebuild.
Quick repro:
fork https://github.com/hylo-lang/XCTestDiscovery
enable github actions on your fork
push a commit that chang...I have a project where a cmake-generated Xcode project can be tested from within Xcode, but not using xcodebuild.
Quick repro:
fork https://github.com/hylo-lang/XCTestDiscovery
enable github actions on your fork
push a commit that changes "build-for-testing" to "test" in this line: https://github.com/hylo-lang/XCTestDiscovery/blob/866759d/.github/workflows/build-and-test.yml#L47
You can also generate the xcode project locally using cmake of course.
The error I get is “error: Scheme DummyTestee is not currently configured for the test action.”https://gitlab.kitware.com/cmake/cmake/-/issues/25680Cmake cannot find protobuf2024-02-16T07:04:15-05:00きかわだCmake cannot find protobufHello, everyone.I am a newbie recently interested in low and intermediate layers.
I can't figure it out, so let me ask my question here.
I am having trouble with CMake finding protobuf.
The same command was working until yesterday, but n...Hello, everyone.I am a newbie recently interested in low and intermediate layers.
I can't figure it out, so let me ask my question here.
I am having trouble with CMake finding protobuf.
The same command was working until yesterday, but now suddenly the error occurs.
What can I do to solve this problem? Please tell me.
Installed on PC M1 Mac with brew.
protoc --version libprotoc 25.2
Add to .zshrc
export PATH="/opt/homebrew/opt/protobuf/bin:$PATH"
source ~/.zshrc
Thanks for reading.
```erroer
cmake -GNinja -Bbuild -DCMAKE_BUILD_TYPE=Release -DWASMEDGE_PLUGIN_WASI_NN_BACKEND="GGML" -DWASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_METAL=ON -DWASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_BLAS=OFF .
-- Setting WASMEDGE_BUILD_WASI_NN_RPC to ON. If you see an error related to gRPC or protobuf, try setting this to OFF.
-- Build spdlog: 1.11.0
-- Build type: Release
-- Checking for module 'protobuf'
-- No package 'protobuf' found
CMake Error at /opt/homebrew/Cellar/cmake/3.28.3/share/cmake/Modules/FindPkgConfig.cmake:619 (message):
The following required packages were not found:
- protobuf
Call Stack (most recent call first):
/opt/homebrew/Cellar/cmake/3.28.3/share/cmake/Modules/FindPkgConfig.cmake:841 (_pkg_check_modules_internal)
lib/wasi_nn_rpc/CMakeLists.txt:2 (pkg_check_modules)
-- Configuring incomplete, errors occurred!
```https://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/25678Update provided Zstd to 1.5.52024-02-16T09:51:19-05:00Christoph GrüningerUpdate provided Zstd to 1.5.5CMake comes with a copy of Zstandard. It is version [1.5.0](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Utilities/cmzstd/lib/zstd.h#L72-L75) from May 2021. The most recent upstream version of Zstandard is 1.5.5 from April 2023.
...CMake comes with a copy of Zstandard. It is version [1.5.0](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Utilities/cmzstd/lib/zstd.h#L72-L75) from May 2021. The most recent upstream version of Zstandard is 1.5.5 from April 2023.
It comes with performance improvements and other fixes, e.g., it would include a fix for #22610 ([upstream issue](https://github.com/facebook/zstd/issues/2770))3.30.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25677Add support to start .cmd shims via a cmd.exe sub-shell on Windows2024-02-14T10:21:23-05:00Liviu IonescuAdd support to start .cmd shims via a cmd.exe sub-shell on WindowsIf I understand the current code right, in `ProcessWin32.c` the function `kwsysProcessCreate()` invokes `CreateProcessW()` directly.
This is fine for executables, but fails for `.cmd` shims (and probably several other Windows specific s...If I understand the current code right, in `ProcessWin32.c` the function `kwsysProcessCreate()` invokes `CreateProcessW()` directly.
This is fine for executables, but fails for `.cmd` shims (and probably several other Windows specific scripts), which require starting via a `cmd.exe` sub-shell.
In the npm/xpm ecosystem, all applications are started via symbolic links, but on Windows, where there are no symbolic links, `.cmd` shims are used, and all npm/xpm applications are practically `.cmd` shims; this makes CMake unusable with npm/xpm applications.
My current solution is a patch that checks if the command is an `.cmd`, and starts it via a `cmd.exe` sub-shell:
```c
#if 1
/* This patch adds support for running .cmd shims
via a cmd.exe sub-shell. */
wchar_t* wFrom = cp->Commands[index];
size_t fromLength = wcslen(wFrom);
wchar_t* wp = wFrom;
/* Skip initial spaces. */
while (*wp == L' ' || *wp == L'\t') {
++wp;
}
if (*wp == L'"') {
while (*++wp != L'"')
;
/* Stop on the ending quote. */
} else {
while (*wp != L' ' && *wp != L'\t') {
++wp;
}
/* Stop on the first space. */
}
wchar_t* wCmd;
wchar_t wDotCmd[] = L".cmd";
if (wcsncmp(wp - wcslen(wDotCmd), wDotCmd, wcslen(wDotCmd)) != 0) {
/* If not an explicit .cmd, execute it directly. */
wCmd = malloc((fromLength + 1) * sizeof(wchar_t));
wcscpy(wCmd, wFrom);
} else {
/* Run it via a cmd.exe subshell. */
wchar_t wCmdExe[] = L"cmd.exe /s /c \" ";
wchar_t wCmdEnd[] = L" \"";
wchar_t escapedChars[] = L"&\\<>^|";
bool inQuotedString = false;
/* Count the number of characters that need to be escaped. */
size_t escapedCount = 0;
for (size_t i = 0; i < fromLength; ++i) {
wchar_t wChr = wFrom[i];
if (wChr == L'"') {
inQuotedString = !inQuotedString;
}
if (!inQuotedString && wcsrchr(escapedChars, wChr) != NULL) {
++escapedCount;
}
}
wCmd = malloc(
(wcslen(wCmdExe) + fromLength + escapedCount + wcslen(wCmdEnd) + 1)
* sizeof(wchar_t)
);
wcscpy(wCmd, wCmdExe);
if (escapedCount > 0) {
inQuotedString = false;
wchar_t* wTo = wCmd + wcslen(wCmdExe);
for (size_t i = 0; i < fromLength; ++i) {
wchar_t wChr = wFrom[i];
if (wChr == L'"') {
inQuotedString = !inQuotedString;
}
if (!inQuotedString && wcsrchr(escapedChars, wChr) != NULL) {
*wTo++ = L'^';
}
*wTo++ = wChr;
}
*wTo++ = L'\0';
} else {
wcscat(wCmd, wFrom);
}
wcscat(wCmd, wCmdEnd);
}
/* Create inherited copies of the handles. */
(error = kwsysProcessCreateChildHandle(&si->StartupInfo.hStdInput,
si->hStdInput, 1)) ||
(error = kwsysProcessCreateChildHandle(&si->StartupInfo.hStdOutput,
si->hStdOutput, 0)) ||
(error = kwsysProcessCreateChildHandle(&si->StartupInfo.hStdError,
si->hStdError, 0)) ||
/* Create the process. */
(!CreateProcessW(0, wCmd, 0, 0, TRUE, creationFlags, 0, 0,
&si->StartupInfo, &cp->ProcessInformation[index]) &&
(error = GetLastError()));
free(wCmd);
#else
/* Create inherited copies of the handles. */
(error = kwsysProcessCreateChildHandle(&si->StartupInfo.hStdInput,
si->hStdInput, 1)) ||
(error = kwsysProcessCreateChildHandle(&si->StartupInfo.hStdOutput,
si->hStdOutput, 0)) ||
(error = kwsysProcessCreateChildHandle(&si->StartupInfo.hStdError,
si->hStdError, 0)) ||
/* Create the process. */
(!CreateProcessW(0, cp->Commands[index], 0, 0, TRUE, creationFlags, 0, 0,
&si->StartupInfo, &cp->ProcessInformation[index]) &&
(error = GetLastError()));
#endif
```
A more elaborate solution should probably check for other extensions too (like `.bat`), but I don't know the full list.
Any thoughts on this issue? Should I submit a merge request with this feature?https://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/25673Fortran module dependency between libraries2024-02-14T01:48:24-05:00Bo BerggrenFortran module dependency between libraries<!--
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/
-->
In a project with several libraries containing Fortran modules, no dependencies are generated from the module (in one library) and the code using the module (other library).https://gitlab.kitware.com/cmake/cmake/-/issues/25668fileapi: Provide CONFIGURE_DEPENDS glob verification info2024-03-21T09:29:04-04:00ArcticLampyridarcticlampyrid@outlook.comfileapi: Provide CONFIGURE_DEPENDS glob verification info## Problem Description
When using the CONFIGURE_DEPENDS flag in CMake to specify file globbing for source file lists, CMake automatically generates a VerifyGlobs.cmake file. This file is used to re-check the specified globs before each b...## Problem Description
When using the CONFIGURE_DEPENDS flag in CMake to specify file globbing for source file lists, CMake automatically generates a VerifyGlobs.cmake file. This file is used to re-check the specified globs before each build, allowing CMake to reconfigure the project automatically if any changes are detected in the globbed files. This feature ensures that the build system remains up-to-date with the project's files and directories structure.
However, this process poses a challenge for IDEs, particularly in terms of IntelliSense and other code navigation features. Currently, the information necessary for verifying globs is only available internally within CMake, with no official method for IDEs to access this information ahead of time. This limitation can hinder the IDE's ability to perform early reconfiguration, which is essential for maintaining accurate IntelliSense and code analysis features.
## Suggested Solution
To address this issue, it would be beneficial for CMake to provide an idiomatic way for IDEs to access glob verification information. One proposed method is to expose this information through CMake's File API. By making glob verification details accessible via the File API, IDEs could perform early reconfiguration based on the most current file and directory structures. This enhancement would significantly improve the development experience by ensuring that code navigation features remain accurate and up-to-date.
## Expected Benefits
- Improved accuracy of IntelliSense and other code analysis tools in IDEs.
- Enhanced developer experience by ensuring that project configurations are always up-to-date with the current state of the file system.
- Streamlined development process, reducing the need for manual project reconfiguration.
## Related Issue
This proposal is helpful to resolve [microsoft/vscode-cmake-tools#3558](https://github.com/microsoft/vscode-cmake-tools/issues/3558).https://gitlab.kitware.com/cmake/cmake/-/issues/25667Feature request: Add `add_source_files_properties` command2024-02-09T15:12:45-05:00Dan RavivFeature request: Add `add_source_files_properties` commandFeature request: Add `add_source_files_properties` command. This would append to a property's existing value, if any, rather than overwrite it like `set_source_files_properties` does.
I found this useful when adding source file-specific...Feature request: Add `add_source_files_properties` command. This would append to a property's existing value, if any, rather than overwrite it like `set_source_files_properties` does.
I found this useful when adding source file-specific `COMPILE_OPTIONS` such as disabling specific warnings on external source files (which are compiled within a target with other source files for warnings should be enabled, so I can't use `target_compile_options`). In case there are more similar use cases, adding the command would make users' life easier.
My hand-rolled version:
```
function(sr_add_source_files_properties files prop value_to_add)
foreach(file ${files})
get_source_file_property(value "${file}" ${prop})
if(value STREQUAL NOTFOUND)
set(value "${value_to_add}")
else()
list(APPEND value "${value_to_add}")
endif()
set_source_files_properties("${file}" PROPERTIES ${prop} "${value}")
endforeach()
endfunction()
```https://gitlab.kitware.com/cmake/cmake/-/issues/25665FindCUDAToolkit: driver and runtime libraries missing some dependencies2024-02-17T08:28:13-05:00Eyal Rozenbergeyalroz1@gmx.comFindCUDAToolkit: driver and runtime libraries missing some dependenciesThis issue is similar to #23835, but wider. It's possible that I should have reported them all together, so sorry about that.
Anyway, consider the two targets `CUDA::cuda_driver` and `CUDA::runtime`. On a typical GNU/Linux system (e.g. ...This issue is similar to #23835, but wider. It's possible that I should have reported them all together, so sorry about that.
Anyway, consider the two targets `CUDA::cuda_driver` and `CUDA::runtime`. On a typical GNU/Linux system (e.g. SLES 15 SP1), they have no value for their `INTERFACE_LINK_LIBRARIES` property. However, when using `ldd` on the respective actual libraries (`.so` files), we find:
```
$ ldd /usr/lib/libcuda.so
linux-gate.so.1 (0xf76e3000)
libm.so.6 => /lib/libm.so.6 (0xf5cf6000)
libc.so.6 => /lib/libc.so.6 (0xf5b1b000)
libdl.so.2 => /lib/libdl.so.2 (0xf5b16000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf5af7000)
librt.so.1 => /lib/librt.so.1 (0xf5aed000)
/lib/ld-linux.so.2 (0xf76e4000)
$
$ ldd /usr/local/cuda/lib64/libcudart.so
linux-vdso.so.1 (0x00007ffc82d1e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f69d497e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f69d4fc7000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f69d477a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f69d455c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f69d4354000)
```
Now, I don't know about `linux-vdso` and the `ld-linux` and `libc` dependencies; but it looks like these targets should have somerthing like:
```
find_package(Threads REQUIRED)
foreach (tgt cudart cuda_driver)
target_link_libraries(${tgt} INTERFACE Threads::Threads ${CMAKE_DL_LIBS})
if(UNIX AND NOT APPLE)
target_link_libraries(${tgt} INTERFACE rt) # Not 100% sure this is necessary
endif()
endforeach()
target_link_libraries(cuda_driver INTERFACE m)
```
i.e. the dependencies should be marked. Am I wrong?3.28.4https://gitlab.kitware.com/cmake/cmake/-/issues/25664Autogen/RCC: Missing `--no-zstd` argument causes user project builds to fail.2024-02-12T10:51:19-05:00Orkun TokdemirAutogen/RCC: Missing `--no-zstd` argument causes user project builds to fail.`--no-zstd` argument is needed for `RCC` when `QT_FEATURE_zstd` is `OFF`. This causes user project builds to fail. That bug is fixed with this https://codereview.qt-project.org/c/qt/qtbase/+/537546 but for the older versions, it should b...`--no-zstd` argument is needed for `RCC` when `QT_FEATURE_zstd` is `OFF`. This causes user project builds to fail. That bug is fixed with this https://codereview.qt-project.org/c/qt/qtbase/+/537546 but for the older versions, it should be fixed on the upstream side too.
Related Qt Bugs
* https://bugreports.qt.io/browse/QTBUG-121948
* https://bugreports.qt.io/browse/QTBUG-106466
* https://bugreports.qt.io/browse/QTBUG-101353Orkun TokdemirOrkun Tokdemirhttps://gitlab.kitware.com/cmake/cmake/-/issues/25661set(CMAKE_CXX_COMPILER /bin/clang++) breaks precompiled headers2024-02-07T10:13:13-05:00gitbruvset(CMAKE_CXX_COMPILER /bin/clang++) breaks precompiled headers<!--
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/
-->https://gitlab.kitware.com/cmake/cmake/-/issues/25657compile_commands.json contains extra @MyCode.cpp.o.modmap arguments which are...2024-02-08T00:02:00-05:00Matthias Gehrecompile_commands.json contains extra @MyCode.cpp.o.modmap arguments which are not used during compilationThis is a regression from 3.27.9 to 3.28.0 on Ubuntu 22.04 (x86-64).
The generated `compile_commands.json` contains a bogus `@MyCode.cpp.o.modmap` argument in the `command` field.
Running the target via `ninja -v MyCode.cpp.o` doesn't s...This is a regression from 3.27.9 to 3.28.0 on Ubuntu 22.04 (x86-64).
The generated `compile_commands.json` contains a bogus `@MyCode.cpp.o.modmap` argument in the `command` field.
Running the target via `ninja -v MyCode.cpp.o` doesn't show that argument (and the modmap file also doesn't exist).
cmake 3.27.9 doesn't add the `@MyCode.cpp.o.modmap` arguments in compile_commands.json.