CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-25T13:54:54-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25816find_package: Search within frameworks and xcframeworks2024-03-25T13:54:54-04:00Maartenfind_package: Search within frameworks and xcframeworksHow can I embed CMake configuration files in xcframework's?
The [currently supported search procedures](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure) only contain regular directory structures...How can I embed CMake configuration files in xcframework's?
The [currently supported search procedures](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure) only contain regular directory structures, macos apps and frameworks.
It would be useful to embed configuration files so to be able to use `find_package` for xcframework's as well.
Internally, xcframeworks are a collection of frameworks.
For reference, this is the tree of a SDL3 xcframework (limited to depth 3):
```
SDL3.xcframework/
├── Info.plist
├── ios-arm64
│ └── SDL3.framework
│ ├── default.metallib
│ ├── Headers
│ ├── Info.plist
│ ├── License.txt
│ ├── ReadMe.txt
│ └── SDL3
├── ios-arm64_x86_64-simulator
│ └── SDL3.framework
│ ├── _CodeSignature
│ ├── default.metallib
│ ├── Headers
│ ├── Info.plist
│ ├── License.txt
│ ├── ReadMe.txt
│ └── SDL3
├── macos-arm64_x86_64
│ └── SDL3.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── Resources -> Versions/Current/Resources
│ ├── SDL3 -> Versions/Current/SDL3
│ └── Versions
├── tvos-arm64
│ └── SDL3.framework
│ ├── default.metallib
│ ├── Headers
│ ├── Info.plist
│ ├── License.txt
│ ├── ReadMe.txt
│ └── SDL3
└── tvos-arm64_x86_64-simulator
└── SDL3.framework
├── _CodeSignature
├── default.metallib
├── Headers
├── Info.plist
├── License.txt
├── ReadMe.txt
└── SDL3
```
I believe CMake should, when e.g. targeting macos on arm64, look into the following additional directories when doing `find_package(SDL3)`:
- `SDL3.xcframework/macos-arm64_x86_64/SDL3.framework/Resources` (depends on the current target)
- `SDL3.xcframework/Resources`https://gitlab.kitware.com/cmake/cmake/-/issues/25813export(TARGETS) for add_library() defined in another file doesn't generate ta...2024-03-25T13:46:52-04:00Rafał Świdzińskiexport(TARGETS) for add_library() defined in another file doesn't generate target-<target>-<config>.cmake for CXX_MODULEs\[3.28.0\]
If `export()` command isn't in the same file scope as the `add_library()`, the file `${CMAKE_BINARY_DIR}/cmake/modules/target-calc-Debug.cmake` won't get created causing an issue in consuming project.
My top level listfile:
...\[3.28.0\]
If `export()` command isn't in the same file scope as the `add_library()`, the file `${CMAKE_BINARY_DIR}/cmake/modules/target-calc-Debug.cmake` won't get created causing an issue in consuming project.
My top level listfile:
```
cmake_minimum_required(VERSION 3.28)
project(ExportCalc CXX)
add_subdirectory(src bin)
export(TARGETS calc
FILE "${CMAKE_BINARY_DIR}/cmake/CalcTargets.cmake"
CXX_MODULES_DIRECTORY "modules"
NAMESPACE Calc::
)
```
And a listfile in src:
```
add_library(calc STATIC basic.cpp)
target_sources(calc
PUBLIC FILE_SET CXX_MODULES FILES extended.cppm
)
target_compile_features(calc PRIVATE cxx_std_20)
set_target_properties(calc PROPERTIES CXX_EXTENSIONS OFF)
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25811Feature request: Treat configuration warnings as errors2024-03-22T12:16:10-04:00Dan RavivFeature request: Treat configuration warnings as errorsIt would be helpful to be able to make CMake treat configuration warnings as errors.
Previously requested here https://discourse.cmake.org/t/cmake-warnings-as-error/3960It would be helpful to be able to make CMake treat configuration warnings as errors.
Previously requested here https://discourse.cmake.org/t/cmake-warnings-as-error/3960https://gitlab.kitware.com/cmake/cmake/-/issues/25806VS: Behaviour of CXX_SCAN_FOR_MODULES in Visual Studio generated projects2024-03-25T10:00:55-04:00David HunterVS: Behaviour of CXX_SCAN_FOR_MODULES in Visual Studio generated projectsThis is not so much a bug as issue with how CMake generates the MSBuild XML for a Visual Studio project file.
This is using CMake 3.29.
So I create a simple Hello World executable, set the C++ version to C++23 and generate a Visual Stu...This is not so much a bug as issue with how CMake generates the MSBuild XML for a Visual Studio project file.
This is using CMake 3.29.
So I create a simple Hello World executable, set the C++ version to C++23 and generate a Visual Studio solution.
Everything works fine.
I now want to use `import std;` so I add
`set_target_properties(hello_world PROPERTIES CXX_SCAN_FOR_MODULES true)`
This works and I can `import std;`. However when I look in the build properties in the Visual Studio GUI for the project. I see
`Scan Sources for Module Dependencies : No`
I was very confused by this.
So I looked in the vcxproj file and I see the MSBuild setting
`<ScanSourceForModuleDependencies>false</ScanSourceForModuleDependencies>` note the "false" here.
After more confusion I then discovered that there were source file specific settings like
`ScanSourceForModuleDependencies Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">true</ScanSourceForModuleDependencies>`
So at the moment CMake seems to always set the project wide setting to false and then always overrides is on the sources.
So things work because the source file settings were overriding the project settings.
This seems wrong to me the behavior I expect would be
- Setting the property `CXX_SCAN_FOR_MODULES` on a target should control the MSBuild setting for the project
- Setting the property `CXX_SCAN_FOR_MODULES` on a source should control the MSBuild setting on a source file
That way the `<ScanSourceForModuleDependencies>` only appears in the output on a source if it has explicitly been set but the CMakeLists.txt.
In an ideal world you would only add `<ScanSourceForModuleDependencies>` to a source file if the value differs from the project setting
but that would just be an optimization.
### `BuildStlModules`
On a related topic MSBuild does have a `BuildStlModules` setting. This seems to be a subset of `ScanSourceForModuleDependencies` and it allows you to use `import std;` but does not switch on full module support. I'm not sure if this a build time optimization thing. Maybe this is worth supporting if the other compilers are going to do something similar.Ben BoeckelBen Boeckelhttps://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?