CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-21T16:12:04-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25804Reproducible Builds: Passing --date to jar in2024-03-21T16:12:04-04:00kpcyrdReproducible Builds: Passing --date to jar inHello!
I'm trying to reproduce a .jar that was built with CMake, the jar content seems to match but the .jar itself contains timestamps of the buildtime.
```
│ ├── usr/share/java/turbojpeg.jar
│ │ ├── zipinfo {}
│ │ │ @@ -1,18 +1,18 @@...Hello!
I'm trying to reproduce a .jar that was built with CMake, the jar content seems to match but the .jar itself contains timestamps of the buildtime.
```
│ ├── usr/share/java/turbojpeg.jar
│ │ ├── zipinfo {}
│ │ │ @@ -1,18 +1,18 @@
│ │ │ Zip file size: 56496 bytes, number of entries: 16
│ │ │ --rw---- 1.0 fat 0 bx stor 24-Jan-25 22:04 META-INF/
│ │ │ --rw---- 2.0 fat 74 bl defN 24-Jan-25 22:04 META-INF/MANIFEST.MF
│ │ │ --rw---- 2.0 fat 736 bl defN 24-Jan-25 22:04 TJBench$DummyDCTFilter.class
│ │ │ --rw---- 2.0 fat 37319 bl defN 24-Jan-25 22:04 TJBench.class
│ │ │ --rw---- 2.0 fat 11777 bl defN 24-Jan-25 22:04 TJExample.class
│ │ │ --rw---- 2.0 fat 24985 bl defN 24-Jan-25 22:04 TJUnitTest.class
│ │ │ --rw---- 2.0 fat 4555 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJ.class
│ │ │ --rw---- 2.0 fat 8937 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJCompressor.class
│ │ │ --rw---- 2.0 fat 336 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJCustomFilter.class
│ │ │ --rw---- 2.0 fat 12512 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJDecompressor.class
│ │ │ --rw---- 2.0 fat 904 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJException.class
│ │ │ --rw---- 2.0 fat 1124 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJLoader.class
│ │ │ --rw---- 2.0 fat 925 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJScalingFactor.class
│ │ │ --rw---- 2.0 fat 1429 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJTransform.class
│ │ │ --rw---- 2.0 fat 2469 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJTransformer.class
│ │ │ --rw---- 2.0 fat 4552 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/YUVImage.class
│ │ │ +-rw---- 1.0 fat 0 bx stor 24-Mar-02 04:40 META-INF/
│ │ │ +-rw---- 2.0 fat 74 bl defN 24-Mar-02 04:40 META-INF/MANIFEST.MF
│ │ │ +-rw---- 2.0 fat 736 bl defN 24-Mar-02 04:40 TJBench$DummyDCTFilter.class
│ │ │ +-rw---- 2.0 fat 37319 bl defN 24-Mar-02 04:40 TJBench.class
│ │ │ +-rw---- 2.0 fat 11777 bl defN 24-Mar-02 04:40 TJExample.class
│ │ │ +-rw---- 2.0 fat 24985 bl defN 24-Mar-02 04:40 TJUnitTest.class
│ │ │ +-rw---- 2.0 fat 4555 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJ.class
│ │ │ +-rw---- 2.0 fat 8937 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJCompressor.class
│ │ │ +-rw---- 2.0 fat 336 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJCustomFilter.class
│ │ │ +-rw---- 2.0 fat 12512 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJDecompressor.class
│ │ │ +-rw---- 2.0 fat 904 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJException.class
│ │ │ +-rw---- 2.0 fat 1124 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJLoader.class
│ │ │ +-rw---- 2.0 fat 925 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJScalingFactor.class
│ │ │ +-rw---- 2.0 fat 1429 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJTransform.class
│ │ │ +-rw---- 2.0 fat 2469 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJTransformer.class
│ │ │ +-rw---- 2.0 fat 4552 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/YUVImage.class
│ │ │ 16 files, 112634 bytes uncompressed, 53932 bytes compressed: 52.1%
```
The `jar` executable has a `--date` option to normalize this, but there's currently no way to configure this in CMake (although I'd love to be corrected on this). Ideally the `--date` flag would be set automatically if the `SOURCE_DATE_EPOCH` environment variable is set to a value. This environment variable is already referenced at other places in the CMake codebase.
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/25803check_c_source_compiles doesn't handle properly escaped source code.2024-03-22T19:26:43-04:00Juan Ramoscheck_c_source_compiles doesn't handle properly escaped source code.Originally found on CMake discourse:
https://discourse.cmake.org/t/syntax-error-in-cmake-code-at-usr-share-cmake-modules-checkcsourcecompiles-cmake-59/10432
Properly escaped code isn't accepted by `check_c_source_compiles`.
Here is a s...Originally found on CMake discourse:
https://discourse.cmake.org/t/syntax-error-in-cmake-code-at-usr-share-cmake-modules-checkcsourcecompiles-cmake-59/10432
Properly escaped code isn't accepted by `check_c_source_compiles`.
Here is a small example to illustrate the issue:
```cmake
include(CheckCSourceCompiles)
check_c_source_compiles("int main() { return '\\0'; }" RESULT)
```
The aforementioned code will fail:
```sh
when parsing string
int main() { return '\0'; }
Invalid character escape '\0'.
```
The route cause is issue #19281
Although a quick solution might be replace the implementation with a function.
The above situation also applies to other CMake modules that must accept arbitrary code:
`check_c_source_runs`, `check_cxx_source_compiles`, `check_cxx_source_runs`, etc.https://gitlab.kitware.com/cmake/cmake/-/issues/25802WINDOWS_EXPORT_ALL_SYMBOLS: MSVC LNK4197 when exporting classes with static m...2024-03-27T14:24:20-04:00Peter_HWINDOWS_EXPORT_ALL_SYMBOLS: MSVC LNK4197 when exporting classes with static members explicitlyThe target property WINDOWS_EXPORT_ALL_SYMBOLS allows for automatic export of symbols from a shared library. It does not export static members (and never has). Since classes derived from QObjects rely on static meta data, it has always b...The target property WINDOWS_EXPORT_ALL_SYMBOLS allows for automatic export of symbols from a shared library. It does not export static members (and never has). Since classes derived from QObjects rely on static meta data, it has always been necessary to explicitly export/import such classes even when enabling the automatic export. Up to and including cmake version 3.26, this worked as expected: The majority of symbols was exported automatically, and a few Qt-related classes had to be exported explicitly.
Using
- cmake 3.28.1 (or 3.27.9),
- VisualStudio 2022 17.9.2,
- and Qt 6.5,
exporting classes explicitly while also enabling WINDOWS_EXPORT_ALL_SYMBOLS leads to the linker warning LNK4197 ("export specified multiple times"). Without the explicit export, you get a linker error on the consuming side for the static data (as expected).
The immediate cause for the warning are additional entries of the form "??_7Foo@@6B@" in the export.def file generated by cmake, where "Foo" is the exported class.
Please find attached a minimal example with a shared library and a consuming executable. The example works up to cmake 3.26 and fails with cmake 3.28.1.
[symbol_export.zip](/uploads/fe575a0b9374b206c74a891bf1e8cf48/symbol_export.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/25800Bug with single quote escaping in add_custom_command2024-03-21T04:10:01-04:00David HunterBug with single quote escaping in add_custom_commandI was trying to add a custom command that used single quotes and ran into an issue with escaping/quoting.
The following is a fairly minimal test case, note this is with 3.28.1 on Windows. I am using the Visual Studio generator.
So I have...I was trying to add a custom command that used single quotes and ran into an issue with escaping/quoting.
The following is a fairly minimal test case, note this is with 3.28.1 on Windows. I am using the Visual Studio generator.
So I have a CMakeLists.txt file that looks like
```
cmake_minimum_required(VERSION 3.25)
project(hello_world)
add_executable(hello_world HelloWorld.cpp)
add_custom_command(
TARGET hello_world
COMMAND echo ' > Foo.out
COMMENT Stuff
VERBATIM)
```
So the intent here is to write a single quote character into a text file called Foo.out. However the text file has the text `"'"` added. If I look at the command line in the generated Visual Studio project it's
`echo "'" > Foo.out`
The > makes sense here as the VS output is an XML file so the '>' was correctly converted to `>`
The question is why are the double quotes added?
I tried every alternative I could think of like `\'` which also produced `"'"`.
Nothing I could find would write out an unquoted single quote.
I am wondering if CMake thinks that a single quote is a special character on a windows command line but I don't think it is.
Comands like `echo ' > tmp` and `dir '` are perfectly valid although weird looking.
So maybe there is a way to do what I'm trying but if there is it doesn't seem to be documented anywhere.
On the documentation front I think it would be extremely useful to have a bunch of examples that show some text in a CMakeLists.text and what will actually appear in a generated Visual Studio project. The documentation at https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#escape-sequences is all I could find and it doesn't help here in the slightest.https://gitlab.kitware.com/cmake/cmake/-/issues/25798WINDOWS_EXPORT_ALL_SYMBOLS causes ACCESS_VIOLATION (-1073741819) when /GL is ...2024-03-20T09:37:57-04:00Sebastian KoernerWINDOWS_EXPORT_ALL_SYMBOLS causes ACCESS_VIOLATION (-1073741819) when /GL is in useBuilding a project like Azure UMOCK-C as a shared build (using WINDOWS_EXPORT_ALL_SYMBOLS to make it work at all) causes MSBUILD to fail with error -1073741819.
I drilled it down to cmake's __create_def which generated empty def-files if...Building a project like Azure UMOCK-C as a shared build (using WINDOWS_EXPORT_ALL_SYMBOLS to make it work at all) causes MSBUILD to fail with error -1073741819.
I drilled it down to cmake's __create_def which generated empty def-files if the cl.exe switch /GL is in use.
I cannot reproduce the error when running cmake stand-alone with the object-list. The def file is empty, but the %ERRORLEVEL% is 0.
Should WINDOWS_EXPORT_ALL_SYMBOLS work with /GL?
This is cmake on Windows, Version 3.23.3 and 3.28.3 tested. Visual Studio 2019 and 2022https://gitlab.kitware.com/cmake/cmake/-/issues/25797Ninja: Link lines with MSVC can exceed Windows command-line length limits2024-03-21T13:25:09-04:00na ro (rona)Ninja: Link lines with MSVC can exceed Windows command-line length limitsthe question come from here
https://github.com/ninja-build/ninja/issues/2400
This problem is strange because when I set the target to static libraries it will compile successfully
Dynamic libraries(share) and executable programs give p...the question come from here
https://github.com/ninja-build/ninja/issues/2400
This problem is strange because when I set the target to static libraries it will compile successfully
Dynamic libraries(share) and executable programs give path constraints
If the long path function is enabled, it will give me the following error
The filename, directory name, or volume label syntax is incorrect.https://gitlab.kitware.com/cmake/cmake/-/issues/25796add_dependencies: Document behavior under Ninja generators2024-03-28T01:18:20-04:00Brad Kingadd_dependencies: Document behavior under Ninja generatorsAs identified in discussion starting at https://gitlab.kitware.com/cmake/cmake/-/issues/25788#note_1497400, the documentation of `add_dependencies` needs clarification for the behavior of the Ninja generators introduced for #15555.As identified in discussion starting at https://gitlab.kitware.com/cmake/cmake/-/issues/25788#note_1497400, the documentation of `add_dependencies` needs clarification for the behavior of the Ninja generators introduced for #15555.Juan RamosJuan Ramoshttps://gitlab.kitware.com/cmake/cmake/-/issues/25794Don't hard-code versions of Python, Boost, Swig etc2024-03-20T06:19:58-04:00Harmen StoppelsDon't hard-code versions of Python, Boost, Swig etcCMake does a poor job at forward compatibility in various Find*.cmake scripts.
For example `find_package(Python)` will happily pick up say system Python 3.6 even though Python 3.12 is in CMAKE_PREFIX_PATH, due to the fact that at the ti...CMake does a poor job at forward compatibility in various Find*.cmake scripts.
For example `find_package(Python)` will happily pick up say system Python 3.6 even though Python 3.12 is in CMAKE_PREFIX_PATH, due to the fact that at the time of the CMake release Python 3.12 was not released yet, or because CMake folks forgot to include 3.12 in the list of "known" Python versions.
Arguably this sequence of commits should just not happen:
- https://github.com/Kitware/CMake/commit/43844c5d82398c443a7f1d4c7aea23d470d1a6e8
- https://github.com/Kitware/CMake/commit/23cd98a66a3eca1cc8e89a77f4fdf406c4f4c113
- https://github.com/Kitware/CMake/commit/f6474214b39337f0c30e29bb986f93c3de730d4c
- https://github.com/Kitware/CMake/commit/dfab044c44caa1911cc2573341e369b6b0ec47fe
Instead of exhaustively listing known versions, which may break within days after a CMake release, it makes much more sense to look for a pattern `python(\d+\(.\d+)?)?` and allow newer versions of Python to be found.
The same applies to Swig and Boost, and possibly others.https://gitlab.kitware.com/cmake/cmake/-/issues/25793Document Escape Sequence mechanism for `message`2024-03-19T09:18:54-04:00Mathieu MalaterreDocument Escape Sequence mechanism for `message`It would be nice to document the "Escape Sequence" used for color message in terminal.
They have potential side effect with `Makefiles` generator, see for ref: #25789
I think the following doc page:
* https://cmake.org/cmake/help/late...It would be nice to document the "Escape Sequence" used for color message in terminal.
They have potential side effect with `Makefiles` generator, see for ref: #25789
I think the following doc page:
* https://cmake.org/cmake/help/latest/command/message.html
Could also reference the `CLICOLOR` env variable.https://gitlab.kitware.com/cmake/cmake/-/issues/25791Add list SET modification analog to list GET reading2024-03-22T05:31:02-04:00Benjamin BuchAdd list SET modification analog to list GET readingCurrently I have to use `REMOVE_AT` and `INSERT` to emulate a `SET`:
```cmake
cmake_minimum_required(VERSION 3.28)
set(my_list a b c d)
set(my_index 2)
list(GET my_list "${my_index}" my_value)
set(my_value "${my_value}2") # some proces...Currently I have to use `REMOVE_AT` and `INSERT` to emulate a `SET`:
```cmake
cmake_minimum_required(VERSION 3.28)
set(my_list a b c d)
set(my_index 2)
list(GET my_list "${my_index}" my_value)
set(my_value "${my_value}2") # some processing
list(REMOVE_AT my_list "${my_index}")
list(INSERT my_list "${my_index}" "${my_value}")
message(STATUS "${my_list}")
```
It would be great if your could just write:
```cmake
cmake_minimum_required(VERSION 3.28)
set(my_list a b c d)
set(my_index 2)
list(GET my_list "${my_index}" my_value)
set(my_value "${my_value}2") # some processing
list(SET my_list "${my_index}" "${my_value}")
message(STATUS "${my_list}")
```
It would also eliminate the asymmetry in the interface. A `GET` without `SET` is very unusual. Of course, this would also be very useful together with 'FIND'.https://gitlab.kitware.com/cmake/cmake/-/issues/25790CTest: build-and-test outputs the configure output only after it finishes2024-03-18T12:48:33-04:00alcroitoCTest: build-and-test outputs the configure output only after it finishesLooks like `ctest --build-and-test` buffers the configure output, and only prints it once the configure step has finished.
If the configure step takes a long time, there is no indication whether there is any progress or if the test is s...Looks like `ctest --build-and-test` buffers the configure output, and only prints it once the configure step has finished.
If the configure step takes a long time, there is no indication whether there is any progress or if the test is stuck.
This can also cause issues in a CI system, where a timeout watcher might kill the job if there is no output for some time.
Can be reproduced with:
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj)
set(src_dir "${CMAKE_BINARY_DIR}/src")
set(build_dir "${CMAKE_BINARY_DIR}/build")
set(source_path "${src_dir}/CMakeLists.txt")
set(source_project [=[
cmake_minimum_required(VERSION 3.16)
project(foo)
message("before 2s sleep")
execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 2)
message("after 2s sleep")
]=]
)
file(WRITE "${source_path}" "${source_project}")
set(ctest_command_args
--build-and-test
"${src_dir}"
"${build_dir}"
--build-generator ${CMAKE_GENERATOR}
)
include(CTest)
add_test(NAME "build_project" COMMAND ${CMAKE_CTEST_COMMAND} ${ctest_command_args})
```
`ctest --build-and-test` should either not buffer the configure output, or learn a new option `--echo-configure-output` to opt into the new behavior.https://gitlab.kitware.com/cmake/cmake/-/issues/25784InstallRequiredSystemLibraries: No support for Clang GNU-like front-end targe...2024-03-18T11:48:58-04:00Maxim ShcherbakovInstallRequiredSystemLibraries: No support for Clang GNU-like front-end targeting MSVC ABI
**Issue**
InstallRequiredSystemLibraries doesn't find crt's to install when using Ninja/Ninja Multi-Config with clang (from LLVM).
**Expected behaviour**
- `InstallRequiredSystemLibraries` finds and installs all necessary crt DLLs.
*...
**Issue**
InstallRequiredSystemLibraries doesn't find crt's to install when using Ninja/Ninja Multi-Config with clang (from LLVM).
**Expected behaviour**
- `InstallRequiredSystemLibraries` finds and installs all necessary crt DLLs.
**Actual behaviour**
- Nothing found and nothing installed.
**Context**
After a bit of investigation into the cmake default modules. From `InstallRequiredSystemLibraries.cmake`:
```
...
if(MSVC)
# Here goes all the "find" code.
endif()
...
```
Obviously this doesn't work for LLVM clang installed on Windows. I expect it to work the same way as for MSVC.
I'm not aware if LLVM clang compiler always uses MSVC C++ runtime libraries (I guess if there is no such possibility right now it could be added later by LLVM, so I'd write the code to not expect clang to always use MSVC C++ runtime libraries). But I've default compiled with clang, took a look with Dependencies Walker, and the output executable refers to `C:\Windows\system32\MSVCP140.dll` and to `C:\Windows\system32\VCRUNTIME140.dll`.https://gitlab.kitware.com/cmake/cmake/-/issues/25782CMake configure crashes and exits early in folder with Chinese characters on ...2024-03-18T10:17:20-04:00Garrett CampbellCMake configure crashes and exits early in folder with Chinese characters on a Chinese language Windows machine.<!--
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/
-->
# Steps to reproduce:
1. Create a Chinese language Windows machine / virtual machine.
2. Install Visual Studio.
3. Create a folder with any of the following character set in the name: 工, 程, 术, 中, 心. (e.g. D:\心, D:\工)
4. Create a new CMake Project inside the folder created in step 3. **Once the project is created, modify the `cmake_minimum_required` version to anything past 3.20. This issue does not reproduce with 3.20 as the minimum required version, but reproduces for anything beyond: 3.21, 3.22, etc.**
5. Close Visual Studio and open a Visual Studio developer command prompt (so that cmake.exe is on path).
6. cd into the new project directory.
7. If VS attempted to configure when you created the project, delete any configure/build output. This is done to ensure that we are only reproducing the command-line behavior and no VS behavior is affecting this.
8. Attempt to configure by running `cmake .`.
Note: This also reproduces outside of the VS developer prompt. I only used it in the repro steps for ease of repro and setup. The minimal thing to do is steps 3 and 4 (which can be done outside of VS), ensure you have cmake installed, attempt to configure.
# Expected Result:
Configure successfully
# Actual Result:
![image](/uploads/5434ecbcbb8617629e8b17ecb4cea58b/image.png)
Configure exits early after identifying the compilers and fails to generate the cache.
If you attempt to configure in Visual Studio, you will see something similar to this:
![image](/uploads/a2ccebd3fbae6a1dff2000f3e9fa55d6/image.png)
# Additional context:
CMake version: 3.28.0
I attached to the cmake configure process using both the VS CMake Debugger and the VS Code CMake Tools Cmake Debugger and found that the configure progress seems to crash and exit at the
`find_program(CMAKE_${_CMAKE_TOOL} NAMES ${_CMAKE_${_CMAKE_TOOL}_FIND_NAMES} HINTS ${_CMAKE_TOOLCHAIN_LOCATION} NO_CMAKE_PATH NO_CMAKE_ENVIRONMENT_PATH)`
line inside of CMakeFindBinUtils.cmake, which on my machine, is at line 224.https://gitlab.kitware.com/cmake/cmake/-/issues/25777FindZLIB: also search for pkg-config2024-03-14T20:25:28-04:00Mark KarpelesFindZLIB: also search for pkg-config`Modules/FindZLIB.cmake` will attempt to find `zlib` in various paths but won't attempt to use `pkg-config`, which `zlib` provides by default and I believe would be the most straightforward method to locate `zlib` on a given system.
I d...`Modules/FindZLIB.cmake` will attempt to find `zlib` in various paths but won't attempt to use `pkg-config`, which `zlib` provides by default and I believe would be the most straightforward method to locate `zlib` on a given system.
I do not know if there is any reason not to use `pkg-config`, but I believe it would make things a lot more standard.https://gitlab.kitware.com/cmake/cmake/-/issues/25776FindEXPAT: Regression in 3.27 when cross-compiling with MinGW2024-03-18T16:19:09-04:00Bert EzendamFindEXPAT: Regression in 3.27 when cross-compiling with MinGW!8225 broke my compilation "Cannot find libexpat".
See issue : https://discourse.cmake.org/t/cmake-cannot-find-the-expat-library/10327/2
Can anyone tell what to do to get it fixed?!8225 broke my compilation "Cannot find libexpat".
See issue : https://discourse.cmake.org/t/cmake-cannot-find-the-expat-library/10327/2
Can anyone tell what to do to get it fixed?https://gitlab.kitware.com/cmake/cmake/-/issues/25775Xcode: Compile options applied to ASM files are not respected2024-03-14T13:02:39-04:00Joey TengXcode: Compile options applied to ASM files are not respected<!--
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/
-->
Simple example:
```cmake
cmake_minimum_required(VERSION 3.16...3.28)
project(demo LANGUAGES C ASM)
add_executable(a a.S)
target_compile_options(a PRIVATE -DBUILD_AARCH64)
```
Expected behaviour (observed in Makefile generator, with `cmake --build build --verbose`
```
[ 50%] Building ASM object CMakeFiles/a.dir/a.S.o
/opt/homebrew/opt/ccache/libexec/cc -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -mmacosx-version-min=14.3 -DBUILD_AARCH64 -o CMakeFiles/a.dir/a.S.o -c /Users/demo/cmake-issue-demo/GAS_not_source_file/a.S
```
Undesired behaviour (observed in Xcode generator):
```
CompileC /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.o /Users/demo/cmake-issue-demo/GAS_not_source_file/a.S normal arm64 assembler-with-cpp com.apple.compilers.llvm.clang.1_0.compiler (in target 'a' from project 'demo')
cd /Users/demo/cmake-issue-demo/GAS_not_source_file
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x assembler-with-cpp -ivfsstatcache /var/folders/wx/p3kml5gn14s_5k6xp15qjtxc0000gn/C/com.apple.DeveloperTools/15.3-15E204a/Xcode/SDKStatCaches.noindex/macosx14.4-23E208-13f6e737bddbb37f317b3579f3535bf5.sdkstatcache -fmessage-length\=187 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unuse
cmake_minimum_required(VERSION 3.16...3.28)
d-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-implicit-fallthrough -fstrict-aliasing -Wdeprecated-declarations -Wno-sign-conversion -Wno-infinite-recursion -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-semicolon-before-method-body @/Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/533656923a283fa776881f304837ed9e-common-args.resp -MMD -MT dependencies -MF /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.d --serialize-diagnostics /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.dia -c /Users/demo/cmake-issue-demo/GAS_not_source_file/a.S -o /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.o
```
Noticed that `-DBUILD_AARCH64` is missing.
The `a.S` file can contain anything (mine was a simple hello world C program generated via `gcc -S`), and the `-DBUILD_AARCH64` flag can be any compile option.
Test environment is M2 MacBook Pro running macOS 14.3.1 with CMake 3.28.3.
My question is: is there a plan to fix this? How can I help to fix this issue?https://gitlab.kitware.com/cmake/cmake/-/issues/25774set_property: Undocumented support for APPEND after values2024-03-14T09:10:53-04:00Momtchil Momtchevset_property: Undocumented support for APPEND after values`conan` is a C++ package manager that produces `CMake` configurations.
`meson` is an alternative mixed language build system that can read `CMake` configurations.
Currently `conan` produces `CMake` files that contain statements of this ...`conan` is a C++ package manager that produces `CMake` configurations.
`meson` is an alternative mixed language build system that can read `CMake` configurations.
Currently `conan` produces `CMake` files that contain statements of this form:
`set_property(TARGET hello::hello PROPERTY INTERFACE_LINK_LIBRARIES "hello::say" APPEND)`
This statement has an `APPEND` effect when used in `CMake` - but does not match the grammar as defined here https://cmake.org/cmake/help/latest/command/set_property.html
The grammar specifies that the `APPEND` keyword must come before the `PROPERTY` keyword.
When encountering this dependency, `meson` which contains an alternative parser, considers `APPEND` to be an additional value.
Can someone clarify if this form is an edge case in your parser that happens to work, or otherwise, to correct the grammar for this statement?https://gitlab.kitware.com/cmake/cmake/-/issues/25773cmake_parse_arguments() and CMake cache slip through variables2024-03-25T09:55:45-04:00Torsten Tejlmandcmake_parse_arguments() and CMake cache slip through variablesUsing `cmake_parse_arguments()` allows cache variables to slip through when a specified argument to the function is omitted by the caller.
Knowing the nature / internal as to how local scope and cache variables work this is in many way ...Using `cmake_parse_arguments()` allows cache variables to slip through when a specified argument to the function is omitted by the caller.
Knowing the nature / internal as to how local scope and cache variables work this is in many way not surprising, but as a developer of re-usable CMake modules, then users of such modules may not be aware that using a given module suddenly add restrictions on which names are allowed to use for cache variables.
For example, creating a CMake module `foo.cmake` containing the following function:
```
function(foo)
cmake_parse_arguments(FOO "" "BAR" "BAZ" ${ARGN})
message("BAR: ${FOO_BAR}; BAZ: ${FOO_BAZ}")
endfunction()
```
and then having a CMakeList.txt file with:
```
cmake_minimum_required(VERSION 3.20)
project(test_foo)
include(foo)
foo() # Call foo without arguments.
```
Now running CMake without setting `FOO_BAR` or `FOO_BAZ` works as expected:
```
$ cmake -Bbuild .
...
BAR: ; BAZ:
...
```
but setting those on command line as cache variable, one will get:
```
$ cmake -Bbuild . -DFOO_BAR=bar -DFOO_BAZ=baz
...
BAR: bar; BAZ: baz
...
```
This is problematic, because a given project may not know all prohibited variables, as there exists several reusable CMake modules.
For example, using `CMakeCompilerIdDetection.cmake` and `GoogleTest.cmake` uses some generic prefixes which can easily collide with a project cache variable name.
Ref:
https://github.com/Kitware/CMake/blob/4285dec5f012260337193f29f18899d6cf2536a4/Modules/CMakeCompilerIdDetection.cmake#L38
```
cmake_parse_arguments(CID "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
```
https://github.com/Kitware/CMake/blob/4285dec5f012260337193f29f18899d6cf2536a4/Modules/GoogleTest.cmake#L317
```
cmake_parse_arguments(ARGS "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
```
`CID` and `ARGS` are not so unique prefixes, meaning that using those CMake modules restricts the use of certain cache variables.
Namely that variable with those prefixes should be avoided, hoever this is not highlighted by CMake or in its documentation.
Proposed solution:
1. Highlight in `cmake_parse_arguments()` documentation that it is important to select unique prefixes, as to minimize the risk of colliding with cache variable names chosen by a given project. Also highlight that cache variables will slip through.
2. Introduce a warning in `cmake_parse_arguments()` so that a warning can be printed if a cache variable of identical name as the `<PREFIX>_<ARGUMENT>` name exists, especially if `<ARGUMENT>` is not provided when the function is called. For the example given above, such warning should be printed when `foo()` is called without arguments but `FOO_BAR` and `FOO_BAZ` exists as cached variables.
The warning will help to ensure functions using `cmake_parse_arguments()` uses non-colliding prefixes, as well as warn a project whenever it uses a CMake variable that has a risk of colliding with a CMake module, such as `CID_PREFIX` (CMakeCompilerIdDetection) or `ARGS_TARGET` (GoogleTest).https://gitlab.kitware.com/cmake/cmake/-/issues/25772cmake --build: Use a default parallel jobs if the `--parallel 0` was passed2024-03-14T11:08:35-04:00Alex Overchenkocmake --build: Use a default parallel jobs if the `--parallel 0` was passed# Problem description
Just for now, CMake partially support of `cmake --build --parallel` for calling **native** tool concurrency.
We aren't talking about passing the specific concurrency value, such as `1` or `42`. Just about giving ch...# Problem description
Just for now, CMake partially support of `cmake --build --parallel` for calling **native** tool concurrency.
We aren't talking about passing the specific concurrency value, such as `1` or `42`. Just about giving chance to the native tool to determine the concurrency.
There are some cases how we can set the build concurrency just for now:
* From the CLI: `cmake --build --parallel` - it works
* From the environment variable `CMAKE_BUILD_PARALLEL_LEVEL`:
* on Windows via `set CMAKE_BUILD_PARALLEL_LEVEL=` call - doesn't work
* on Linux via `export CMAKE_BUILD_PARALLEL_LEVEL=` - doesn't tested, shouldn't also work
* From the `CMakePresets.json` file:
* via the `jobs` parameter - doesn't possible, because it requires a number, `0` value doesn't work
* via `CMAKE_BUILD_PARALLEL_LEVEL` environment variable (`environment` section) with `""` (empty) value - doesn't work
* via `CMAKE_BUILD_PARALLEL_LEVEL` environment variable (`environment` section) with `null` (JSON null, not the string) value - doesn't work
So, we can set it only by manual pass `--parallel` argument to the CMake, nothing else.
# Test environment
* Windows 10 22H2 x64
* `Visual Studio 17 2022` generator
* Native compiling (x64 to x64)
# Proposal
Just to use `0` value for this case. It is not acceptable value for now, but we can reserve & use it for running **native** tool concurrency.https://gitlab.kitware.com/cmake/cmake/-/issues/25771MSVC target_precompile_headers disables all warnings for the target2024-03-15T12:45:00-04:00AnyOldName3MSVC target_precompile_headers disables all warnings for the target`target_precompile_headers` causes CMake to generate a header to precompile, such as this one:
```cpp
/* generated by CMake */
#pragma system_header
#ifdef __cplusplus
#include <sol/sol.hpp>
#include <osg/State>
#include <osg/StateSet>
...`target_precompile_headers` causes CMake to generate a header to precompile, such as this one:
```cpp
/* generated by CMake */
#pragma system_header
#ifdef __cplusplus
#include <sol/sol.hpp>
#include <osg/State>
#include <osg/StateSet>
#include <osg/Node>
#include <osg/Drawable>
#include <osg/Camera>
#include <MyGUI_Widget.h>
#include <algorithm>
#include <filesystem>
#include <fstream>
#include <functional>
#include <memory>
#include <ostream>
#include <string>
#include <vector>
#endif // __cplusplus
```
It is then added to the target with the `/Fp` and `/Yu` flags.
For some reason, the `#pragma system_header` then ends up affecting every file in the target, and if `/external:W0` is set, as is generally sensible, no warnings will be generated any more.
This seems like an MSVC bug, but as far as I can tell, it affects every MSVC version that supports `#pragma system_header`, so seems like something CMake should work around.