CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-10-23T12:06:38-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/24235Clang on Windows does not show color diagnostics unless -fansi-escape-codes i...2023-10-23T12:06:38-04:00Alvin WongClang on Windows does not show color diagnostics unless -fansi-escape-codes is addedOn Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes...On Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes` to the C/CXX flags. I tested two different scenarios:
- Windows console (cmd.exe) + ninja + [llvm-mingw](https://github.com/mstorsjo/llvm-mingw)
- GitHub Actions Windows runner + mingw32-make + llvm-mingw
I am not sure if this counts as a CMake issue or Clang's, but Clang always uses the Windows console API by default unless -fansi-escape-codes is given, and I guess it doesn't have direct access to the Windows console when run under make or ninja.https://gitlab.kitware.com/cmake/cmake/-/issues/24232Consider setting CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT on all compilers2023-01-12T09:22:50-05:00Russell GreeneConsider setting CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT on all compilersWhen adding compile flags, it seems like currently you have to check the COMPILER_ID and the COMPILER_VARIANT:
```
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU" OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND CMAKE_CXX_COMPILER_FRONTEND_VARIA...When adding compile flags, it seems like currently you have to check the COMPILER_ID and the COMPILER_VARIANT:
```
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU" OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "GNU"))
...
```
It would be nice if on gcc and msvc, we also set the COMPILER_FRONTEND_VARIANT to "GNU" and "MSVC" respectively to make that check as simple as
```
if (CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "GNU")
...
```
Is there a particular reason this would be not acceptable? I'm happy to write a patch if this makes sense.https://gitlab.kitware.com/cmake/cmake/-/issues/24216Windows: Problems with PATH-derived find_library search prefixes2024-03-25T15:31:09-04:00Brad KingWindows: Problems with PATH-derived find_library search prefixesSince CMake 3.3, on Windows, the `find_path`, `find_file`, and `find_library` commands compute search prefixes from the `PATH` entries of the form `$prefix/bin`.
The change was made by commit ffc06c12397e7cda7307afcfc8a79ebda4a786a6 for...Since CMake 3.3, on Windows, the `find_path`, `find_file`, and `find_library` commands compute search prefixes from the `PATH` entries of the form `$prefix/bin`.
The change was made by commit ffc06c12397e7cda7307afcfc8a79ebda4a786a6 for #15370, and was originally made for all platforms. CMake 3.6 reverted it for non-Windows platforms in commit b30b32a4931080280680aa5b439c0d4918553c56 due to finding shared libraries in undesired prefixes. However, the justification for to retain the behavior on Windows was stated in the commit message:
> The motivation was to support MSYS, MinGW and similar Windows platforms in their default environments automatically.
The idea is that on Windows one typically sets `PATH` as part of establishing specific development environments, so we might as well use that information to automatically find libraries and headers for the target environment.
Recently, !7694 taught `find_library` to search for the `libfoo.a` naming convention even for the MSVC ABI, for #23975. However, that regressed existing build environments as reported in https://gitlab.kitware.com/cmake/cmake/-/issues/23975#note_1280921 and #24168. Discussion in #24168 identified that `find_path` had already been finding MinGW headers even when using MSVC, but they previously went unused by luck because `find_library` was not finding the corresponding MinGW library prior to considering the `libfoo.a` naming convention. **The problems encountered with searching for the `libfoo.a` naming convention were not inherent, but were due to searching MinGW prefixes even when using MSVC, because they were derived from the `PATH`.**
!7962 resolved the regressions for the 3.25 series by reverting the change, but both issues' discussions identified more **general problems with searching `PATH`-derived prefixes**. They are very similar to the reasons CMake 3.6 reverted the behavior on non-Windows systems. I'm opening this issue to **propose dropping that behavior** on Windows too, and to discuss alternative ways to find MSYS and MinGW packages in their respective development environments without using `PATH` to derive search prefixes in general.3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24211FetchContent: Support relative remote URLs like git submodules2023-04-27T09:12:29-04:00Chris WrightFetchContent: Support relative remote URLs like git submodulesGit submodule URLs can be relative to the upstream repository, but when using `FetchContent`, a relative path is assumed to be a path to a local directory.
`FetchContent` should support relative `GIT_REPOSITORY` URLs such that, for exam...Git submodule URLs can be relative to the upstream repository, but when using `FetchContent`, a relative path is assumed to be a path to a local directory.
`FetchContent` should support relative `GIT_REPOSITORY` URLs such that, for example with this repo, `../Community.git` would not resolve to a local repository, but to `gitlab.kitware.com/cmake/Community.git`.
Git only falls back to assuming a relative path for a submodule is referring to a local repository if the containing repo does not have a default remote configured.
The main reason for allowing this is that the dependency repo will be cloned using the same mechanism as the parent project when using relative paths. This is particularly helpful for [Gitlab CI], for example:
#### https://docs.gitlab.com/ee/ci/git_submodules.html
> [This] instructs Git to automatically deduce the URL to use when cloning sources...
> GitLab CI/CD uses HTTPS for cloning your sources, and you can continue to use SSH to clone locally.https://gitlab.kitware.com/cmake/cmake/-/issues/24209PCH compilations fails on VC++/Ninja if CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP=12023-12-05T09:25:57-05:00Aurelien Regat-BarrelPCH compilations fails on VC++/Ninja if CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP=1Hello,
I recently updated our CI to 3.25.0 and our builds started to fail immediately (VC++ 2022, C++20, Ninja). I found it is related to `CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` being set to 1 by default, which has already been identifie...Hello,
I recently updated our CI to 3.25.0 and our builds started to fail immediately (VC++ 2022, C++20, Ninja). I found it is related to `CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` being set to 1 by default, which has already been identified and fixed by #24198. Great.
But in order to help you improve C++20 module support, here's a simple cmake project that fails to build with `CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP=1`.
```cpp
// pch.h is an empty header file
```
```cpp
// empty.cpp is an empty cpp file
```
```cmake
# CMakeLists.txt
cmake_minimum_required(VERSION 3.20)
project(Project)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
# setting this flag to 1 with VC++ / Ninja makes Ninja to complain:
# ninja: error: dependency cycle: CMakeFiles/MyLibWithPCH.dir/cmake_pch.cxx.obj -> CMakeFiles/MyLibWithPCH.dir/CXX.dd -> CMakeFiles/MyLibWithPCH.dir/empty.cpp.obj.ddi -> CMakeFiles/MyLibWithPCH.dir/cmake_pch.cxx.pch -> CMakeFiles/MyLibWithPCH.dir/cmake_pch.cxx.obj
set(CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP 1)
add_library(MyLibWithPCH
empty.cpp
)
target_precompile_headers(MyLibWithPCH PUBLIC pch.h)
```
```batch
REM from VC++ 2022 command prompt
mkdir build && cd build
cmake .. -G Ninja
ninja
ninja: error: dependency cycle: CMakeFiles/MyLibWithPCH.dir/cmake_pch.cxx.obj -> CMakeFiles/MyLibWithPCH.dir/CXX.dd -> CMakeFiles/MyLibWithPCH.dir/empty.cpp.obj.ddi -> CMakeFiles/MyLibWithPCH.dir/cmake_pch.cxx.pch -> CMakeFiles/MyLibWithPCH.dir/cmake_pch.cxx.obj
```
Hope it helps!3.28.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/24207VS: CMake fails to configure WindowsStore project for VS 2019+2023-11-29T09:51:13-05:00dvirtzVS: CMake fails to configure WindowsStore project for VS 2019+1. clone https://github.com/coderox/CoreApp
2. run `cmake -DCMAKE_SYSTEM_NAME="WindowsStore" -DCMAKE_SYSTEM_VERSION="10.0" -A x64 -G "Visual Studio 17 2022" -S . -B build`
3. error is
```
CMake Error at CMakeLists.txt:2 (project):
Fail...1. clone https://github.com/coderox/CoreApp
2. run `cmake -DCMAKE_SYSTEM_NAME="WindowsStore" -DCMAKE_SYSTEM_VERSION="10.0" -A x64 -G "Visual Studio 17 2022" -S . -B build`
3. error is
```
CMake Error at CMakeLists.txt:2 (project):
Failed to run MSBuild command:
C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/MSBuild/Current/Bin/amd64/MSBuild.exe
to get the value of VCTargetsPath:
MSBuild version 17.4.0+18d5aef85 for .NET Framework
Build started 29/11/2022 08:45:53.
Project "C:\Users\dyitzchaki\github\CoreApp\build\CMakeFiles\3.25.0\VCTargetsPath.vcxproj" on node 1 (default targets).
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(832,5): error : The BaseOutputPath/OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\Users\dyitzchaki\github\CoreApp\build\CMakeFiles\3.25.0\VCTargetsPath.vcxproj]
Done Building Project "C:\Users\dyitzchaki\github\CoreApp\build\CMakeFiles\3.25.0\VCTargetsPath.vcxproj" (default targets) -- FAILED.
Build FAILED.
```
The same command works with `-G "Visual Studio 15 2017"`.
cmake version 3.25.0https://gitlab.kitware.com/cmake/cmake/-/issues/24201FetchContent fails with SYSTEM and commit hash other than HEAD2022-12-05T06:23:37-05:00FabianFetchContent fails with SYSTEM and commit hash other than HEADCMake-Version: 3.25.0, Git-Version: 2.38.0
When trying to fetch a dependency using `SYSTEM` and referencing a commit hash using `GIT_TAG` other than `HEAD`, FetchContent fails:
```
cmake_minimum_required(VERSION 3.25.0)
project(fetch_co...CMake-Version: 3.25.0, Git-Version: 2.38.0
When trying to fetch a dependency using `SYSTEM` and referencing a commit hash using `GIT_TAG` other than `HEAD`, FetchContent fails:
```
cmake_minimum_required(VERSION 3.25.0)
project(fetch_content_bug)
include(FetchContent)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG 9b9a42166803e864a8b08c22cadfe8db447acb40 # not HEAD
GIT_SHALLOW OFF
SYSTEM
)
FetchContent_MakeAvailable(googletest)
```
```
$ cmake ..
Microsoft (R)-Build-Engine, Version 16.11.2+f32259642 für .NET Framework
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
Checking Build System
Creating directories for 'googletest-populate'
Building Custom Rule C:/Users/<hidden>/cmake_bug_repro/build/_deps/googletest-subbuild/CMakeLists.txt
Performing download step (git clone) for 'googletest-populate'
Cloning into 'googletest-src'...
fatal: reference is not a tree: 9b9a42166803e864a8b08c22cadfe8db447acb40
CMake Error at googletest-subbuild/googletest-populate-prefix/tmp/googletest-populate-gitclone.cmake:49 (message):
Failed to checkout tag: '9b9a42166803e864a8b08c22cadfe8db447acb40'
...
CMake Error at C:/Program Files/CMake/share/cmake-3.25/Modules/FetchContent.cmake:1616 (message):
Build step for googletest failed: 1
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.25/Modules/FetchContent.cmake:1756:EVAL:2 (__FetchContent_directPopulate)
C:/Program Files/CMake/share/cmake-3.25/Modules/FetchContent.cmake:1756 (cmake_language)
C:/Program Files/CMake/share/cmake-3.25/Modules/FetchContent.cmake:1970 (FetchContent_Populate)
CMakeLists.txt:43 (FetchContent_MakeAvailable)
-- Configuring incomplete, errors occurred!
```
Removing `SYSTEM` works:
```
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG 6b63c98ac43efc992122f1da12aaf0a0e0658206 # not HEAD
GIT_SHALLOW OFF
)
```
Using `HEAD` for `GIT_TAG` with `SYSTEM` works:
```
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG e68764c147ea0dac1e8811925c531d937396878e # head
GIT_SHALLOW OFF
SYSTEM
)
```
Using tags for `GIT_TAG` with `SYSTEM` works:
```
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG v1.12.0
GIT_SHALLOW OFF
SYSTEM
)
```Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/24188FindCUDAToolkit: PATH_SUFFIXES ../ pattern breaks on symlinks2022-12-01T08:02:53-05:00Brad KingFindCUDAToolkit: PATH_SUFFIXES ../ pattern breaks on symlinksThe CUDA toolkit layout in `nvcr.io/nvidia/nvhpc:22.9-devel-cuda_multi-ubuntu22.04` has symlinks like `/path/to/cuda/bin -> 11.7/bin`. As discussed in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7946#note_1280257, FindCUDATo...The CUDA toolkit layout in `nvcr.io/nvidia/nvhpc:22.9-devel-cuda_multi-ubuntu22.04` has symlinks like `/path/to/cuda/bin -> 11.7/bin`. As discussed in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7946#note_1280257, FindCUDAToolkit's use of a `PATH_SUFFIXES ../` pattern causes libraries to be found at paths like `/path/to/cuda/bin/../lib/libfoo.so`, but after removing `bin/../`, the path does not exist. Pending some future CMake development that improves the path normalization behavior, FindCUDAToolkit needs to be revised to avoid using `../` in `PATH_SUFFIXES`. !7945 already updated one such case IIUC.Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/24185FindPython doesn't support backporting any more in 3.252022-11-23T18:12:29-05:00Henry SchreinerFindPython doesn't support backporting any more in 3.25The FindPython module was originally designed to support backporting to older CMake's (3.7 initially). I used this fact when designing scikit-build-core; it provides a backport of FindPython and supports CMake 3.15+. This is tested and w...The FindPython module was originally designed to support backporting to older CMake's (3.7 initially). I used this fact when designing scikit-build-core; it provides a backport of FindPython and supports CMake 3.15+. This is tested and works for 3.24. However, in 3.25.0, it's now broken; it cannot be used on older CMakes anymore. This is important for us to provide the fixes and features for Python users that go in during the project lifespan, including !7917 and hopefully #24141.
This is what is broken:
```
Policy "CMP0134" is not known to this version of CMake.
```Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/24166FindMatlab: Set include directory as SYSTEM directory2023-01-12T09:21:40-05:00jorritolthuisFindMatlab: Set include directory as SYSTEM directory`matlab_add_mex()` currently adds the `${Matlab_INCLUDE_DIRS}` as `PRIVATE` include_directories. I believe it should be added as `SYSTEM PRIVATE`, because one is not expected to fix bugs in the header files provided by MathWorks.
To giv...`matlab_add_mex()` currently adds the `${Matlab_INCLUDE_DIRS}` as `PRIVATE` include_directories. I believe it should be added as `SYSTEM PRIVATE`, because one is not expected to fix bugs in the header files provided by MathWorks.
To give a concrete example: using MATLAB R2020b and GCC 9.4.0 with `-Wall -Wextra` produces the following warning
```
/usr/local/MATLAB/R2020b/simulink/include/simulink.c: At top level:
/usr/local/MATLAB/R2020b/simulink/include/simulink.c:3697: warning: ignoring #pragma warning [-Wunknown-pragmas]
3697 | #pragma warning ( push )
|
/usr/local/MATLAB/R2020b/simulink/include/simulink.c:3698: warning: ignoring #pragma warning [-Wunknown-pragmas]
3698 | #pragma warning ( disable: 4090 )
|
/usr/local/MATLAB/R2020b/simulink/include/simulink.c:3727: warning: ignoring #pragma warning [-Wunknown-pragmas]
3727 | #pragma warning ( pop )
|
```https://gitlab.kitware.com/cmake/cmake/-/issues/24162cmake cannot be compiled with Visual Studio 2022 17.42023-03-08T11:44:36-05:00Michael Bradecmake cannot be compiled with Visual Studio 2022 17.4Hi, with the current Visual Studio 2022 17.4.0 and msvc 19.34.31933.0, it is not possible anymore to compile cmake:
```
cmGlobalWatcomWMakeGenerator.cxx
.conan\data\cmake\3.24.0\_\_\build\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\source_...Hi, with the current Visual Studio 2022 17.4.0 and msvc 19.34.31933.0, it is not possible anymore to compile cmake:
```
cmGlobalWatcomWMakeGenerator.cxx
.conan\data\cmake\3.24.0\_\_\build\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\source_subfolder\Source\cmGlobalVisualStudioGenerator.cxx(633,47): error C2280: "std::basic_ostream<char,std::char_traits<char>> &std::operator <<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,const wchar_t *)" : Es wurde versucht, auf eine gelöschte Funktion zu verweisen [.conan\data\cmake\3.24.0\_\_\build\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\Source\CMakeLib.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.34.31933\include\ostream(965,31): message : Siehe Deklaration von "std::operator <<" [.conan\data\cmake\3.24.0\_\_\build\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\Source\CMakeLib.vcxproj]
.conan\data\cmake\3.24.0\_\_\build\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\source_subfolder\Source\cmGlobalVisualStudioGenerator.cxx(633,47): error C2088: "<<": Ungültig für class [.conan\data\cmake\3.24.0\_\_\build\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\Source\CMakeLib.vcxproj]```
I am using cryptopp with conan, which has as a build requirement cmake 3.24.0. But even with 3.24.2, the error still happens.3.24.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24150Xcode: Allow embeddeding extensionkit extensions2022-11-21T10:06:24-05:00Russell GreeneXcode: Allow embeddeding extensionkit extensionsStarting in iOS 16.1, ExtensionKit extensions are a new kind of extension:
https://developer.apple.com/documentation/extensionkit
These need to be placed in the Extensions/ directory of the bundle, which is done with
```
dstPath = "$(...Starting in iOS 16.1, ExtensionKit extensions are a new kind of extension:
https://developer.apple.com/documentation/extensionkit
These need to be placed in the Extensions/ directory of the bundle, which is done with
```
dstPath = "$(EXTENSIONS_FOLDER_PATH)";
dstSubfolderSpec = 16;
```
in the copy files build stage
Example: using the background assets extension apis (https://developer.apple.com/documentation/backgroundassets)https://gitlab.kitware.com/cmake/cmake/-/issues/24140FindCUDAToolkit: Possible wrong path for variable CUDAToolkit_MATH_INCLUDE_DIR2022-11-22T09:52:53-05:00Pierre KestenerFindCUDAToolkit: Possible wrong path for variable CUDAToolkit_MATH_INCLUDE_DIRHello,
In FindCUDAToolkit.cmake, when looking for header "cublas_v2.h", the directory `CUDAToolkit_MATH_INCLUDE_DIR` is build like this:
```cmake
set(CUDAToolkit_MATH_INCLUDE_DIR "${CUDAToolkit_TARGET_DIR}/../../math_libs/include")
cmak...Hello,
In FindCUDAToolkit.cmake, when looking for header "cublas_v2.h", the directory `CUDAToolkit_MATH_INCLUDE_DIR` is build like this:
```cmake
set(CUDAToolkit_MATH_INCLUDE_DIR "${CUDAToolkit_TARGET_DIR}/../../math_libs/include")
cmake_path(NORMAL_PATH CUDAToolkit_MATH_INCLUDE_DIR)
```
it actually fails on my system because CUDAToolkit_TARGET_DIR is a symbolic link.
I'd like to suggest the following change to resolve real path for CUDAToolkit_TARGET_DIR first:
```cmake
file(REAL_PATH "${CUDAToolkit_TARGET_DIR}" CUDAToolkit_TARGET_DIR)
set(CUDAToolkit_MATH_INCLUDE_DIR "${CUDAToolkit_TARGET_DIR}/../../math_libs/include")
```
or maybe, another solution could be:
```cmake
cmake_path(NORMAL_PATH CUDAToolkit_TARGET_DIR)
set(CUDAToolkit_MATH_INCLUDE_DIR "${CUDAToolkit_TARGET_DIR}/../../math_libs/include")
```
Let me know what you think.3.26.0https://gitlab.kitware.com/cmake/cmake/-/issues/24076Explicit value for parallel_read_safe setting of sphinxcontrib-cmakedomain pa...2023-06-23T10:41:00-04:00Joseph GrantExplicit value for parallel_read_safe setting of sphinxcontrib-cmakedomain packageparallel_read_safe is currently undefined for the sphinxcontrib-cmakedomain package as far as I can tell.
https://www.sphinx-doc.org/en/master/extdev/index.html#extension-metadata
This means that it will default to false. So could this...parallel_read_safe is currently undefined for the sphinxcontrib-cmakedomain package as far as I can tell.
https://www.sphinx-doc.org/en/master/extdev/index.html#extension-metadata
This means that it will default to false. So could this be explicitly set, and if so is there anything preventing it from being set to true?https://gitlab.kitware.com/cmake/cmake/-/issues/24056Add %z for adding time zone string2022-10-28T10:04:50-04:00Vasiliy KozyrevAdd %z for adding time zone stringIt is very necessary for our project to display the local time zone.
%z is fairly standardized for all operating systems, but %Z, unfortunately, is not.
This is how you can allow the formation of a digital time zone string:
`diff --gi...It is very necessary for our project to display the local time zone.
%z is fairly standardized for all operating systems, but %Z, unfortunately, is not.
This is how you can allow the formation of a digital time zone string:
`diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx index 677fdb658e..2d5784f6d5 100644 --- a/Source/cmTimestamp.cxx +++ b/Source/cmTimestamp.cxx @@ -201,6 +201,7 @@ std::string cmTimestamp::AddTimestampComponent( case 'w': case 'y': case 'Y': + case 'z': case '%': break; case 's': // Seconds since UNIX epoch (midnight 1-jan-1970)`https://gitlab.kitware.com/cmake/cmake/-/issues/24022try_compile: --debug-trycompile location discovery2022-10-11T11:17:25-04:00Brad Kingtry_compile: --debug-trycompile location discoveryAfter #22799, the location of a `try_compile` build directory is no longer predictable. Users of `--debug-trycompile` may need a new way to discover the location of the directory that ran a check they are trying to debug.After #22799, the location of a `try_compile` build directory is no longer predictable. Users of `--debug-trycompile` may need a new way to discover the location of the directory that ran a check they are trying to debug.https://gitlab.kitware.com/cmake/cmake/-/issues/23999MSVC for ARM/ARM64: Support macro ARM assemblers2023-01-12T15:38:05-05:00Mikhail PilinMSVC for ARM/ARM64: Support macro ARM assemblersHi there,
Windows ARM64 is coming, so we strongly need some support for ARM assemblers in CMake: `armasm.exe` and `armasm64.exe`. `.vcxproj` supports new node `MARMASM` and requires `<Import Project="$(VCTargetsPath)\BuildCustomizations...Hi there,
Windows ARM64 is coming, so we strongly need some support for ARM assemblers in CMake: `armasm.exe` and `armasm64.exe`. `.vcxproj` supports new node `MARMASM` and requires `<Import Project="$(VCTargetsPath)\BuildCustomizations\marmasm.props" />` and `<Import Project="$(VCTargetsPath)\BuildCustomizations\marmasm.targets" />` in additional. This feature should works for MSVC++ v142. As I understand from CMake sources we need new compiler type `ASM_MARMASM` to be implemented.https://gitlab.kitware.com/cmake/cmake/-/issues/23979ctest: --timeout silently ignored2023-10-02T11:46:17-04:00Jonathan Sweemerctest: --timeout silently ignoredIf I pass a value of 10,000,000 or more to `ctest --timeout` then it is silently ignored, and the default value of 1500 is used instead.
I spent several hours on google trying to figure out why the `--timeout` option does not work, and ...If I pass a value of 10,000,000 or more to `ctest --timeout` then it is silently ignored, and the default value of 1500 is used instead.
I spent several hours on google trying to figure out why the `--timeout` option does not work, and eventually figured it out for myself when I randomly tried a smaller number. This is incredibly frustrating because the `--verbose` output does not explain at all why the "computed" test timeout is different from the specified value. I expect the timeout to be what I specify, nothing more and nothing less. If it must be different for some reason, then there should at least be a warning emitted.
Furthermore, there seems to be no way to specify a timeout of "unlimited" using ctest. If there is in fact a way, please let me know what it is, and please also put it in the documentation for other users.
```console
$ ctest --version
ctest version 3.24.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```
```console
$ cat main.cpp
int main() {}
```
```console
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.24.0)
project(timeout-test LANGUAGES CXX)
include(CTest)
add_executable(timeout-test main.cpp)
add_test(timeout-test timeout-test)
```
```console
$ ctest --verbose --timeout 10000000
UpdateCTestConfiguration from :/home/sweemer/test/cmake/DartConfiguration.tcl
Parse Config file:/home/sweemer/test/cmake/DartConfiguration.tcl
UpdateCTestConfiguration from :/home/sweemer/test/cmake/DartConfiguration.tcl
Parse Config file:/home/sweemer/test/cmake/DartConfiguration.tcl
Test project /home/sweemer/test/cmake
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: timeout-test
1: Test command: /home/sweemer/test/cmake/timeout-test
1: Working Directory: /home/sweemer/test/cmake
1: Test timeout computed to be: 1500
1/1 Test #1: timeout-test ..................... Passed 0.00 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.00 sec
```
```console
$ ctest --verbose --timeout 1000000
UpdateCTestConfiguration from :/home/sweemer/test/cmake/DartConfiguration.tcl
Parse Config file:/home/sweemer/test/cmake/DartConfiguration.tcl
UpdateCTestConfiguration from :/home/sweemer/test/cmake/DartConfiguration.tcl
Parse Config file:/home/sweemer/test/cmake/DartConfiguration.tcl
Test project /home/sweemer/test/cmake
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: timeout-test
1: Test command: /home/sweemer/test/cmake/timeout-test
1: Working Directory: /home/sweemer/test/cmake
1: Test timeout computed to be: 1000000
1/1 Test #1: timeout-test ..................... Passed 0.00 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.00 sec
```3.27.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23938REGEX MATCH fails to compile (semver, subgroups)2022-09-06T15:24:23-04:00hinellREGEX MATCH fails to compile (semver, subgroups)```bash
tee regexFailure.cmake <<EOL
string(REGEX MATCH "^([0-9][0-9]*)\\.([0-9][0-9]*)\\.([0-9][0-9]*)(-(([0-9][0-9]|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*)(\\.([0-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*))*))?(\\+([0-9a-zA-Z-]+(\\.[0-9a-zA-Z-]+)*))...```bash
tee regexFailure.cmake <<EOL
string(REGEX MATCH "^([0-9][0-9]*)\\.([0-9][0-9]*)\\.([0-9][0-9]*)(-(([0-9][0-9]|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*)(\\.([0-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*))*))?(\\+([0-9a-zA-Z-]+(\\.[0-9a-zA-Z-]+)*))?$" SEMVER "99.0.14-test.99")
include(CMakePrintHelpers)
cmake_print_variables(SEMVER)
EOL
cmake -P regexFailure.cmake
```
The above fails in the CMake 3.24.1 with the error below.
```
...
CMake Error at create_git.cmake:23 (string):
string sub-command REGEX, mode MATCH failed to compile regex
...
```
I'm trying to parse entire [semver](http://semver.org/) version but it doesn't work wellhttps://gitlab.kitware.com/cmake/cmake/-/issues/23871[ENH] return() command: add capability to propagate variables to parent scope2022-09-07T09:51:54-04:00Marc Chevrier[ENH] return() command: add capability to propagate variables to parent scopeCurrently, the only possibility to propagate information to the parent scope is to use `set(PARENT_SCOPE)` or `unset(PARENT_SCOPE)` commands.
In many situations, it is painful because a large majority of commands work only with local va...Currently, the only possibility to propagate information to the parent scope is to use `set(PARENT_SCOPE)` or `unset(PARENT_SCOPE)` commands.
In many situations, it is painful because a large majority of commands work only with local variables. Moreover, with the introduction of command `block()`, it becomes more complex to propagate information because the update must cross two scopes.
To solve this problem, I propose to extend the `return()` command by supporting a list of variables which must be propagated to the result scope.
The proposed syntax, to be compatible with `block()` command, is:
```cmake
return([PROPAGATE <var-name>...])
```
With this capability, it is possible to write something like this:
```cmake
function(MY_FUNC)
set(MY_VAR ...)
block()
string(TOUPPER "${MY_VAR}" MY_VAR)
if(MY_VAR STREQUAL ...)
return(PROPAGATE MY_VAR)
endif()
endblock()
string(APPEND MY_VAR ...)
return(PROPAGATE MY_VAR)
endfunction()
```
One open question: should this behavior of `return()` supported in all cases or only in cases involving commands creating variable scope (i.e. `function()` and `add_subdirectory()`)?
I think a policy must be created for this new `retun()` syntax because, currently, this command accepts any arguments and ignore them.