CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-15T12:09:15-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25770AutoMoc: Produces 'note: No relevant classes found. No output generated.' whe...2024-03-15T12:09:15-04:00Alexey EdelevAutoMoc: Produces 'note: No relevant classes found. No output generated.' when Q_OBJECT macro is part of the multiline commentWhen Q_OBJECT macro is part of the multi-line comment AutoMoc passes the source file to moc, but shouldn't. This causes the warning produced by moc: _note: No relevant classes found. No output generated._
The minimal example that reprod...When Q_OBJECT macro is part of the multi-line comment AutoMoc passes the source file to moc, but shouldn't. This causes the warning produced by moc: _note: No relevant classes found. No output generated._
The minimal example that reproduces the issue:[automoc_qobject_multiline_comment.tar.gz](/uploads/674aed362eb8a7a0575474961f1eff55/automoc_qobject_multiline_comment.tar.gz)Orkun TokdemirOrkun Tokdemirhttps://gitlab.kitware.com/cmake/cmake/-/issues/25769CPACK_RPM_[COMPONENT]_PACKAGE_PREFIX Ignored2024-03-12T14:39:03-04:00Josef GrausCPACK_RPM_[COMPONENT]_PACKAGE_PREFIX IgnoredCMake version for issue: v3.29.0-rc2
I'm having a strange issue with [CPACK_RPM_[COMPONENT]_PACKAGE_PREFIX](https://cmake.org/cmake/help/latest/cpack_gen/rpm.html#variable:CPACK_RPM_%3CCOMPONENT%3E_PACKAGE_PREFIX)
In my toy example, I ...CMake version for issue: v3.29.0-rc2
I'm having a strange issue with [CPACK_RPM_[COMPONENT]_PACKAGE_PREFIX](https://cmake.org/cmake/help/latest/cpack_gen/rpm.html#variable:CPACK_RPM_%3CCOMPONENT%3E_PACKAGE_PREFIX)
In my toy example, I have two components, "apps" and "libs". They build into separate RPMs as expected, no issues there. However, I can't configure them to have different default install prefixes for the RPMs. The behavior I'm experiencing makes it appear that that `CPACK_RPM_apps_PACKAGE_PREFIX` and `CPACK_RPM_libs_PACKAGE_PREFIX` are effectively ignored, even though they're recognized by the CPack RPM module?
My simple example:
```
set(CPACK_GENERATOR "RPM")
set(CPACK_RPM_PACKAGE_DEBUG ON)
set(CPACK_PACKAGE_NAME "example-package")
set(CPACK_PACKAGE_DESCRIPTION "Minimum reproducible example for this issue.")
set(CPACK_PACKAGE_VENDOR "Me")
set(CPACK_RPM_apps_FILE_NAME "${CPACK_PACKAGE_NAME}-apps.${CMAKE_HOST_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_libs_FILE_NAME "${CPACK_PACKAGE_NAME}-libs.${CMAKE_HOST_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_PACKAGE_RELOCATABLE ON)
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_COMPONENTS_ALL apps libs)
# Package default installation locations
set(CPACK_RPM_apps_PACKAGE_PREFIX "/opt/example-package-apps/")
set(CPACK_RPM_libs_PACKAGE_PREFIX "/opt/example-package-libs/")
```
When I inspect the resulting rpm, it shows all the files with the default prefix `/usr`. However, the `CPACK_RPM_PACKAGE_DEBUG` output clearly shows that the per-component prefixes were at least detected. For example, an output snippet for the "apps" component:
```
CPackRPM:Debug: processing PREFIX
CPackRPM:Debug: using CPACK_RPM_PACKAGE_PREFIX
CPackRPM:Debug: User defined Prefix:
/opt/apps/
```
My best guess is something odd is going on here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Internal/CPack/CPackRPM.cmake?ref_type=heads#L130
Could there be an issue with the `${CPACK_RPM_PACKAGE_COMPONENT}` substitution (this one is confusing since `CPACK_RPM_PACKAGE_COMPONENT` is defined in the documentation as being `ON` or `True`, not a list of component names)? I'm not terribly familiar with the module though, so I could be off the mark.
Would someone be able to help me out? It would be much appreciated.https://gitlab.kitware.com/cmake/cmake/-/issues/25768Feature request: Enable use of custom compiler toolchains for Android devices2024-03-12T14:37:53-04:00Heiko LewinFeature request: Enable use of custom compiler toolchains for Android devicesHello!
Currently the cmake modules dealing with Android specifics do not provide an easy way to use a compiler toolchain not supplied by Google's NDK.
The checks are very narrowly tied to expected directory structures and files found in...Hello!
Currently the cmake modules dealing with Android specifics do not provide an easy way to use a compiler toolchain not supplied by Google's NDK.
The checks are very narrowly tied to expected directory structures and files found in the NDK; often there is no way to just set a value manually and override automatic detection.
As an example if `CMAKE_SYSTEM_ROOT` is set it is checked to match a certain pattern. The only ways to get around such checks would be to set some values that trigger early-exit clauses in the Android specific modules (like setting CMAKE_SYSTEM_VERSION to 1) which leave all variables normally set by the modules up to be set by the user - which _would_ be fine, but I am concerned that a project's CMakeLists may check `CMAKE_SYSTEM_VERSION` and base bahviour on the value found there.
tl;dr I want an early-exit variable for Android specific modules shipped with cmake or means to override automatic checks/feature detection with finer granularity.https://gitlab.kitware.com/cmake/cmake/-/issues/25767EXPORT_PACKAGE_DEPENDENCIES: Guarded by experimental UUID2024-03-12T14:17:06-04:00Brad KingEXPORT_PACKAGE_DEPENDENCIES: Guarded by experimental UUID!8957 added the `EXPORT_PACKAGE_DEPENDENCIES` feature to `install(EXPORT)` and `export()`. However, some design concerns have been raised in a few issues leading to the decision to move the feature behind an experimental gate. This iss...!8957 added the `EXPORT_PACKAGE_DEPENDENCIES` feature to `install(EXPORT)` and `export()`. However, some design concerns have been raised in a few issues leading to the decision to move the feature behind an experimental gate. This issue tracks the relevant issues that need to be addressed before removing the experimental gate.
Issues include:
* [x] #25756
* [ ] #25757
* [ ] #25758https://gitlab.kitware.com/cmake/cmake/-/issues/25763CUDA: Separable compilation fails with Clang and native/all/all-major archs2024-03-13T05:21:50-04:00Garima GuptaCUDA: Separable compilation fails with Clang and native/all/all-major archsCMake fails when CMAKE_CUDA_ARCHITECTURES is set to native, all or all-major with Clang for targets with CUDA_SEPARABLE_COMPILATION setting as ON, then cmake does not detect correct value for architecture
When env is clang and CMAKE_CUD...CMake fails when CMAKE_CUDA_ARCHITECTURES is set to native, all or all-major with Clang for targets with CUDA_SEPARABLE_COMPILATION setting as ON, then cmake does not detect correct value for architecture
When env is clang and CMAKE_CUDA_ARCHITECTURES is set to native, all, or all-major then targets which has CUDA_SEPARABLE_COMPILATION set to ON, gives error because it uses architecture as sm_native if native is set and sm_all if all or all-major is set for CMAKE_CUDA_ARCHITECTURES
The targets which are set with CUDA_SEPARABLE_COMPILATION as ON, calls internally in cmake "cmMakefileExecutableTargetGenerator::WriteDeviceExecutableRule" function in file cmMakefileExecutableTargetGenerator.cxx (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5221/diffs#47db539af92be7d459f78d00c444a672f76bc133)
```
if (this->Makefile->GetSafeDefinition("CMAKE_CUDA_COMPILER_ID") == "Clang") {
this->WriteDeviceLinkRule(commands, targetOutput);
} else {
this->WriteNvidiaDeviceExecutableRule(relink, commands, targetOutput);
}
```
so when env is gnu, then it calls WriteNvidiaDeviceExecutableRule which does not use CMAKE_CUDA_ARCHITECTURES variable but when env is clang, it calls WriteDeviceLinkRule and it uses the value of CMAKE_CUDA_ARCHITECTURES variable. And this does not find the exact architecture value when CMAKE_CUDA_ARCHITECTURES is native, all or all-major.https://gitlab.kitware.com/cmake/cmake/-/issues/25762xctest_add_test should run `xcodebuild test` instead of `xctest`2024-03-24T07:28:36-04:00Jason Juangxctest_add_test should run `xcodebuild test` instead of `xctest`Let's say we create a minimal example using `xctest_add_test`, for example
```
xctest_add_bundle(test mylibrary)
xctest_add_test(Alltests test test.cpp)
```
and run `ctest` via `cmake --build . --target RUN_TESTS`, investigating `Testing...Let's say we create a minimal example using `xctest_add_test`, for example
```
xctest_add_bundle(test mylibrary)
xctest_add_test(Alltests test test.cpp)
```
and run `ctest` via `cmake --build . --target RUN_TESTS`, investigating `Testing/Temporary/LastTest.log` will show that the test command generated by cmake is `/Applications/Xcode.app/Contents/Developer/usr/bin/xctest /Users/jason/minimal/build/Debug/test.xctest`. However, directly running the `xctest` tool will only work for simple scenarios, it won't execute correctly when dyld search path environment variables such as `DYLD_FRAMEWORK_PATH` or `DYLD_LIBRARY_PATH` are needed. On the other hand, if the test command generated by cmake is `xcodebuild test -project minimal.xcodeproj -scheme mylibrary`, the test would've execute correctly because dyld search path environment variables such as `DYLD_FRAMEWORK_PATH` or `DYLD_LIBRARY_PATH` will be provided to the test runner.
Can we fix `xctest_add_test` so that it runs `xcodebuild test` instead of `xctest`?https://gitlab.kitware.com/cmake/cmake/-/issues/25760VS: Errors with special character in Windows user name2024-03-11T12:40:23-04:00Garrett CampbellVS: Errors with special character in Windows user nameWhen a Windows user has a special character, i.e. "Test(". Using a VS generator will cause build errors after configuration.
Below are simple reproduction steps:
1. Unzip the attached repro project. [Repro.zip](/uploads/2950d7fb365606...When a Windows user has a special character, i.e. "Test(". Using a VS generator will cause build errors after configuration.
Below are simple reproduction steps:
1. Unzip the attached repro project. [Repro.zip](/uploads/2950d7fb36560642d17bc5bddf95b685/Repro.zip)
2. Open a terminal at the folder of the repro project
3. Configure the project by running the following command: `cmake -G "Visual Studio 17 2022" -A x64 -DCMAKE_CONFIGURE_TYPES:STRING="Debug"` This will succeed
4. Then, attempt to build by running: `cmake --build .`. This will show an error similar to "'C:/Users/Test' is not recognized as ..."https://gitlab.kitware.com/cmake/cmake/-/issues/25759A static library gets generated implicitly when TARGET_SUPPORTS_SHARED_LIBS i...2024-03-17T21:46:51-04:00Louis DionneA static library gets generated implicitly when TARGET_SUPPORTS_SHARED_LIBS is falseOn platforms that do not support dynamic linking, if a shared library is created CMake will currently fall back implicitly to creating a STATIC library instead. This happens here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Sour...On platforms that do not support dynamic linking, if a shared library is created CMake will currently fall back implicitly to creating a STATIC library instead. This happens here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmAddLibraryCommand.cxx?ref_type=heads#L236
This is confusing: instead, I believe CMake should print the warning but leave the target type alone. Changing the target type can lead to other failures down the line that are simply more confusing and at the end of the day, changing the library type to STATIC is unlikely to be what the user wants. The user most likely wants a failure so they can fix their code.
This was encountered in the process of refactoring libc++'s CMake configuration. We basically define targets for both the shared and the static libraries, but users may decide to build and install only one of those if they desire. On embedded platforms that don't support dynamic linking, this fails because while the users wouldn't be building and installing the unsupported shared library, they still get a definition since we define the static library twice (once via the normal definition of the static variant of the library, and once via the shared library being implicitly changed to a static library).https://gitlab.kitware.com/cmake/cmake/-/issues/25757install(EXPORT ... EXPORT_PACKAGE_DEPENDENCIES) forces export file to be the ...2024-03-13T17:30:25-04:00Craig Scottinstall(EXPORT ... EXPORT_PACKAGE_DEPENDENCIES) forces export file to be the <package>-config.cmake fileThe new `EXPORT_PACKAGE_DEPENDENCIES` keyword for `install(EXPORT)` writes `find_dependency()` calls into the generated export file. This assumes that the export file is the `<package>-config.cmake` file for the package, because the `fin...The new `EXPORT_PACKAGE_DEPENDENCIES` keyword for `install(EXPORT)` writes `find_dependency()` calls into the generated export file. This assumes that the export file is the `<package>-config.cmake` file for the package, because the `find_dependency()` call works by forcing the calling scope to return if the dependency cannot be found. That works if the `find_dependency()` call is in the `<package>-config.cmake` file, but it doesn't work if it is in a file included by `<package>-config.cmake`.
Some projects will need to define their own custom `<package>-config.cmake` file to account for package-specific logic like defining functions, perhaps including multiple export files to define the package targets, and so on. We cannot rely on the export file always being the `<package>-config.cmake` file. However, the generated export files don't provide a way to say to whatever included them "I was successful" or "I failed to find one or more dependencies". Up to CMake 3.28, a custom `<package>-config.cmake` file would always assume the generated export files it includes were successful.
Thinking more about these sort of more complex packages, if they use multiple export sets, they would want to first find all the dependencies for all export sets before creating targets for any of the export sets. This would then allow the package to properly honour the "we either fully succeed, or we don't create any targets and CMake can move on to trying to find another location that provides this package" (also see #25756). This suggests that the `find_dependency()` calls should not be in the same file as the generated export file. They need to be separate, and most likely there needs to be a way to generate the final `<package>-config.cmake` file in such a way that all the `find_dependency()` calls get inlined so that failing to find any dependency will early-exit the `<package>-config.cmake` file. Perhaps this could be incorporated into the `configure_package_config_file()` command from the `CMakePackageConfigHelpers` module. We could add something like a `DEPENDENCY_EXPORTS` option to `configure_package_config_file()`, and the project would list the export sets after it. The command would then query internal information recorded somewhere by `install(EXPORT... EXPORT_PACKAGE_DEPENDENCIES)` for each of those export sets, find each one's generated dependencies file, and inline them into the generated `<package>-config.cmake` file. Note that this also means `install(EXPORT)` could be modified to _always_ generate a dependencies file and not require a new `EXPORT_PACKAGE_DEPENDENCIES` keyword. We could allow such a keyword to instead customise the name of the dependencies file, but we can provide a sensible default based on the file name of the export itself.
I'm sure there are other possible strategies for resolving this, but it does seem to me like embedding the `find_dependency()` calls in the export file is the wrong place, except for the special case of there only being one export file and that export file being the `<package>-config.cmake` file directly. If we still want to support this special case, we likely need a keyword in the `install(EXPORT)` call to indicate whether the export file will indeed be the `<package>-config.cmake` file rather than being `include()`'d by it.
CC: @kyle.edwards @brad.king @eyalrozhttps://gitlab.kitware.com/cmake/cmake/-/issues/25754Presets: sourceDirName expands to an empty string when source dir contains tr...2024-03-11T09:50:10-04:00Eugene ShalyginPresets: sourceDirName expands to an empty string when source dir contains trailing slashWhen source directory ends with the slash, which is the case for the GUI by default, ${sourceDirName} expands to an empty string. CMake version 3.28.3.When source directory ends with the slash, which is the case for the GUI by default, ${sourceDirName} expands to an empty string. CMake version 3.28.3.https://gitlab.kitware.com/cmake/cmake/-/issues/25749Policy CMP0141 is set only from CLI2024-03-07T08:39:25-05:00Pavel RežňákPolicy CMP0141 is set only from CLIHello, I have a problem persuading CMake to remove `/Zi` flag from a project that specifies `cmake_minimum_required < 3.25`.
I have this setup:
```cmake
# toolchain.cmake
set(CMAKE_POLICY_DEFAULT_CMP0141 NEW)
set(CMAKE_MSVC_DEBUG_INFO...Hello, I have a problem persuading CMake to remove `/Zi` flag from a project that specifies `cmake_minimum_required < 3.25`.
I have this setup:
```cmake
# toolchain.cmake
set(CMAKE_POLICY_DEFAULT_CMP0141 NEW)
set(CMAKE_MSVC_DEBUG_INFORMATION_FORMAT $<$<CONFIG:Debug,RelWithDebInfo>:Embedded>)
```
```cmake
# CMakeLists.txt
cmake_minimum_required(VERSION 3.24)
project(cmake_test VERSION 1.0.0 LANGUAGES CXX)
add_executable(cmake_test)
target_sources(cmake_test PRIVATE main.cpp)
```
When I use `cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="toolchain.cmake"` then CMakeCache.txt contains `/Zi` in `CMAKE_CXX_FLAGS_DEBUG`. If I add `-DCMAKE_POLICY_DEFAULT_CMP0141=NEW` directly to the command line then `/Zi` is removed and replaced with `/Z7`.
Than you in advance for help or fix.https://gitlab.kitware.com/cmake/cmake/-/issues/25747check_c_compiler_flag does not seem to check for "invalid feature modifier"2024-03-07T08:32:42-05:00Phong Nguyencheck_c_compiler_flag does not seem to check for "invalid feature modifier"I'm currently on a project that has to compile against a large number of targets. One of the components I'm compiling is AOM, which uses `check_c_compiler_flag` to determine legitimate compiler options for various optimizations (see [cpu...I'm currently on a project that has to compile against a large number of targets. One of the components I'm compiling is AOM, which uses `check_c_compiler_flag` to determine legitimate compiler options for various optimizations (see [cpu.cmake](https://aomedia.googlesource.com/aom/+/refs/heads/main/build/cmake/cpu.cmake)). Unfortunately, this error detection appears to fail under CMake.
GCC will emit an error like this:
```
➜ tmp g++ -march=armv8.2-a+bad limits.cpp
cc1plus: error: invalid feature modifier in ‘-march=armv8.2-a+dotprod+i8mm+sve’
```
Clang will emit an error like this:
```
➜ tmp clang -march=armv8.2-a+bad limits.cpp
clang-16: error: unsupported argument 'armv8.2-a+bad' to option '-march='
```
Neither flag is currently recognized by `CMakeCheckCompilerFlagCommonPatterns.cmake`. I locally added `unsupported argument` and that appeared to work, but it did not detect `invalid feature modifier`. Is it possible that the delegation to `cc1plus` causes CMake to miss it, even when added?https://gitlab.kitware.com/cmake/cmake/-/issues/25746`OBJC_STANDARD` Supported Values List is Incomplete2024-03-07T08:30:56-05:00Tyler Nichols`OBJC_STANDARD` Supported Values List is IncompleteIt looks like the list of supported values for the [OBJC_STANDARD](https://cmake.org/cmake/help/latest/prop_tgt/OBJC_STANDARD.html) target property is missing the following values:
* `17` (Objective C17)
* `23` (Objective C23)
My un...It looks like the list of supported values for the [OBJC_STANDARD](https://cmake.org/cmake/help/latest/prop_tgt/OBJC_STANDARD.html) target property is missing the following values:
* `17` (Objective C17)
* `23` (Objective C23)
My understanding is that this list should match the list of supported values for the [C_STANDARD](https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD.html) target property.https://gitlab.kitware.com/cmake/cmake/-/issues/25743Feature Request: Make `<projectName>_VERSION` available in the parent (or glo...2024-03-06T09:23:13-05:00Luc TourailleFeature Request: Make `<projectName>_VERSION` available in the parent (or global) scopeWhen integrating a dependency with `find_package` and a version config file is available, `find_package` provides a variable `<PackageName>_VERSION` variable.
When integrating a dependency with `add_subdirectory` (e.g. with `FetchConten...When integrating a dependency with `find_package` and a version config file is available, `find_package` provides a variable `<PackageName>_VERSION` variable.
When integrating a dependency with `add_subdirectory` (e.g. with `FetchContent_MakeAvailable`) and the `project` call contains a `VERSION`, a variable `<projectName>_VERSION` is set but only in the scope of the directory.
Would it make sense to set this variable in the parent scope or even in the cache? Currently there is no easy way to retrieve the version of a dependency integrated with `add_subdirectory`, and having the variable would allow writing code that works regardless of whether the dependency is "found" or "added". Also, it would be consistent with `<projectName>_SOURCE_DIR` and `<projectName>_BINARY_DIR`, which are already cache variables (see #25714).https://gitlab.kitware.com/cmake/cmake/-/issues/25738presets: Support `rerun-failed` in test presets2024-03-05T08:16:41-05:00John Szwastpresets: Support `rerun-failed` in test presetsI would like to configure some test presets to run with the `--rerun-failed` option.
I know it's easy to add the flag at the command line, but I would like such a preset configured in my IDE. I don't really care whether it is a dedicat...I would like to configure some test presets to run with the `--rerun-failed` option.
I know it's easy to add the flag at the command line, but I would like such a preset configured in my IDE. I don't really care whether it is a dedicated option or a generic field for adding arbitrary command-line options.https://gitlab.kitware.com/cmake/cmake/-/issues/25737GHS: custom_command with multiple outputs executes multiple times2024-03-04T16:17:27-05:00William SciaroniGHS: custom_command with multiple outputs executes multiple times# Background
- Using CMake with the `Green Hills MULTI" generator
With the following configuration:
```cmake
cmake_minimum_required(VERSION 3.27)
project(Example LANGUAGES CXX)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/...# Background
- Using CMake with the `Green Hills MULTI" generator
With the following configuration:
```cmake
cmake_minimum_required(VERSION 3.27)
project(Example LANGUAGES CXX)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/one.cpp ${CMAKE_CURRENT_BINARY_DIR}/two.cpp
COMMAND touch ${CMAKE_CURRENT_BINARY_DIR}/one.cpp ${CMAKE_CURRENT_BINARY_DIR}/two.cpp
COMMENT "GENERATING one.cpp and two.cpp"
)
add_library(SomeLib ${CMAKE_CURRENT_BINARY_DIR}/one.cpp ${CMAKE_CURRENT_BINARY_DIR}/two.cpp)
```
The generation output is similar to the following
```log
Building ALL_BUILD.tgt.gpj
Processing Custom Rule SomeLib_cc0_one.cpp.rule.sh because one.cpp does not exist
GENERATING one.cpp and two.cpp
Processing Custom Rule SomeLib_cc0_one.cpp.rule.sh because two.cpp does not exist
GENERATING one.cpp and two.cpp
Compiling one.cpp because it has changed
Compiling two.cpp because it has changed
Archiving libSomeLib.a because two.o has changed
Done
```https://gitlab.kitware.com/cmake/cmake/-/issues/25736Add new platform AmigaOS4 (PPC)2024-03-13T06:34:25-04:00Josef WegnerAdd new platform AmigaOS4 (PPC)Hi,
We want to add a new platform `AmigaOS4` to CMake.
We have already a draft for a CMake Toolchain file at [josefwegner/CMAKE_AOS4 (github.com)](https://github.com/josefwegner/CMAKE_AOS4). This toolchain file already works for simple...Hi,
We want to add a new platform `AmigaOS4` to CMake.
We have already a draft for a CMake Toolchain file at [josefwegner/CMAKE_AOS4 (github.com)](https://github.com/josefwegner/CMAKE_AOS4). This toolchain file already works for simple projects. With additional changes (FindOpenGL.cmake) it can also compile SDL2 and OpenGL sample programs.
Also, we forked the project at [Josef Wegner / CMake · GitLab (kitware.com)](https://gitlab.kitware.com/FlynnTheAvatar/cmake).
Could you please give us some guidelines on how we can convert the toolchain file to a definition used in Platform directory.
Thank you,
Josefhttps://gitlab.kitware.com/cmake/cmake/-/issues/25735Warning/Error for incorrect `check_cxx_compiler_flag` usage2024-03-04T02:53:17-05:00Alexander RichardsonWarning/Error for incorrect `check_cxx_compiler_flag` usageI spent quite a while debugging why some check_cxx_compiler_flag in LLVM
were not working as expected. It turns out the configure checks were using:
`check_cxx_compiler_flag(-Werror -Wempty-body COMPILER_RT_HAS_EMPTY_BODY_FLAG)`
The che...I spent quite a while debugging why some check_cxx_compiler_flag in LLVM
were not working as expected. It turns out the configure checks were using:
`check_cxx_compiler_flag(-Werror -Wempty-body COMPILER_RT_HAS_EMPTY_BODY_FLAG)`
The check_cxx_compiler_flag macro only takes two arguments and passing
three to it ends up calling
`cmake_check_compiler_flag(CXX "${_FLAG}" ${_RESULT})` with ${_FLAG}
equal to `-Werror` and the result variable being the actually tested
compiler flag (-Wempty-body).
`--debug-trycompile` shows the following surprising line in the generated
CMakeLists.txt:
`add_definitions([==[-D-Wempty-body]==] [==[-Werror]==])` which then
results in the following error while running the check:
```
FAILED: CMakeFiles/cmTC_72736.dir/src.cxx.o
tmp/upstream-llvm-readonly/bin/clang++ -nodefaultlibs -std=c++17 -fcolor-diagnostics -D-Wempty-body -Werror -MD -MT CMakeFiles/cmTC_72736.dir/src.cxx.o -MF CMakeFiles/cmTC_72736.dir/src.cxx.o.d -o CMakeFiles/cmTC_72736.dir/src.cxx.o -c .../cmake-build-all-sanitizers/CMakeFiles/CMakeScratch/TryCompile-nyh3QR/src.cxx
In file included from <built-in>:450:
<command line>:1:9: error: macro name must be an identifier
1 | #define -Wempty-body 1
| ^
1 error generated.
```
I tried running the CMake debugger to see why this add_defitions line is being added, but I can't figure it out easily.
I think it would be great if the callers of cmake_check_compiler_flag() could warn/error for such incorrect usage that can be quite difficult to track down.https://gitlab.kitware.com/cmake/cmake/-/issues/25733Allow users to specify additional individual Co-Compilers2024-03-03T08:20:36-05:00Thorsten KleinAllow users to specify additional individual Co-CompilersHello,
currently there is only some choice of `__run_co_compile` supported:
- `--cppcheck=`
- `--cpplint=`
- `--iwyu=`
- `--lwyu=`
- `--tidy=`
The huge benefit of those co-compilers is that incremental builds are supported (according to...Hello,
currently there is only some choice of `__run_co_compile` supported:
- `--cppcheck=`
- `--cpplint=`
- `--iwyu=`
- `--lwyu=`
- `--tidy=`
The huge benefit of those co-compilers is that incremental builds are supported (according tools are only run for changes).
If users currently want to integrate their own linting tools, they have to abuse one of the existing co-compiler integrations.
For example they might use some "wrapper" script which calls the actual tool plus their individual tool afterwards.
Instead, it would be nice to allow users to integrate the linting tools without any abuse of existing co-compilers.
Therefore I propose to introduce some new co-compiler, e.g. it could be named `--individual` or `--co-compiler`
Since it would be nice to support multiple individual co-compilers, the co-compiler shall just start with according pattern. For example:
- `__run_co_compile --individual-mylinter1=...`
- `__run_co_compile --individual-formattingtool=...`
- `__run_co_compile --individual-refactoringtool=...`
The co-compilers could be enabled within `CMakelists.txt` via some property (analog to `<LANG>_CLANG_TIDY`):
- `CXX_CO_COMPILERS="mylinter1;formattingtool;refactoringtool"`.
The tool for each co-compiler can be specified via `<LANG>_CO_COMPILER_<NAME>` (analog to `HEADER_DIRS_<NAME>:
```
CXX_CO_COMPILER_mylinter1=/path/to/mylinter1"
CXX_CO_COMPILER_formattingtool=/path/to/formattingtool"
CXX_CO_COMPILER_refactoringtool=/path/to/refactoringtool"
```https://gitlab.kitware.com/cmake/cmake/-/issues/25731CMake does not support C++20 modules with clang-cl.exe2024-03-05T06:02:25-05:00Sharadh RajaramanCMake does not support C++20 modules with clang-cl.exeSupplying `CMAKE_CXX_COMPILER=clang-cl` with a target containing `FILE_SET CXX_MODULES` does not work, and during configuration, CMake errors with:
```
CMake Error in CMakeLists.txt:
The target named "main" has C++ sources that may us...Supplying `CMAKE_CXX_COMPILER=clang-cl` with a target containing `FILE_SET CXX_MODULES` does not work, and during configuration, CMake errors with:
```
CMake Error in CMakeLists.txt:
The target named "main" has C++ sources that may use modules, but the
compiler does not provide a way to discover the import graph dependencies.
See the cmake-cxxmodules(7) manual for details. Use the
CMAKE_CXX_SCAN_FOR_MODULES variable to enable or disable scanning.
```
`clang-cl.exe` is in fact _exactly_ (read: bit-for-bit equal, and therefore have equal file checksums) the same binary as `clang.exe` in the official LLVM distribution for Windows, with only differing file names. It is able to [forward arguments to the GNU-style driver with `/clang:`](https://github.com/llvm/llvm-project/blob/051e910b8b6c59fc94d019fa01ae4507b1c81498/clang/docs/UsersManual.rst#L4397), and therefore [straightforwardly supports C++20 module compilation](https://discourse.llvm.org/t/clang-cl-exe-support-for-c-modules/72257/28) equally as well as the latter.