CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-13T05:21:50-04:00https://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/17330Ninja + Clang generator causes unnecessary rebuilds in some cases2024-03-09T14:14:21-05:00Peter Wupeter@lekensteyn.nlNinja + Clang generator causes unnecessary rebuilds in some casesAs discovered in #17271, Ninja incorrectly parses dependency files generated by Clang if those dependencies contain relative paths (containing `A/..`) where the parent directory `A` is a symlink that changes the directory level.
Three c...As discovered in #17271, Ninja incorrectly parses dependency files generated by Clang if those dependencies contain relative paths (containing `A/..`) where the parent directory `A` is a symlink that changes the directory level.
Three components can be blamed:
1. Ninja: does not correctly expand paths containing `..`, it assumes `"a/b/.." == "a"` which is not the case if there is a symlink `"b" -> "c/d"`. See https://github.com/ninja-build/ninja/issues/1330
2. Clang: produces depfiles containing `..` which GCC does not do. See https://reviews.llvm.org/D37954 for a patch. **NOTE**: the root cause turns out to be missing prefix canonicalization. That is, if `PATH` contains `/bin` before `/usr/bin`, and `/bin` is a symlink to `usr/bin`, then Clang *should* use `/usr/bin`. Instead it uses `/bin`. See the discussion on the linked patch.
3. CMake: assumes that Clang behaves like GCC and passes its depfile to Ninja.
Minimal reproducer which works on Arch Linux: [CMakeLists.txt](/uploads/634001cb11ceec2a855cd8752b8df828/CMakeLists.txt)
Reproduce with `cmake -GNinja . && ninja && ninja`. The second command should show "nothing to do", but it simply executes the command again. The reason for that:
```
$ clang++ -MD -MF - -fsyntax-only reproducer.cpp
reproducer.o: reproducer.cpp \
/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/cstdio \
/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/x86_64-pc-linux-gnu/bits/c++config.h \
...
$ ninja -t deps
CMakeFiles/reproducer.dir/reproducer.cpp.o: #deps 25, deps mtime 1507299627 (VALID)
reproducer.cpp
/include/c++/7.2.0/cstdio
/include/c++/7.2.0/x86_64-pc-linux-gnu/bits/c++config.h
...
$ readlink -f /bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/cstdio
/usr/include/c++/7.2.0/cstdio
$ readlink /bin
usr/bin
```
Suggestion:
Test whether Clang* is in use with the Ninja generator, and if so, run another command that resolves the relative paths.
*) Hopefully the issue is solved in Clang 6 with the <del>above patch, but I am still waiting for reviews on that one</del> (that patch is a no-go, a different approach is needed).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.https://gitlab.kitware.com/cmake/cmake/-/issues/25590cxxmodules: clang-scan-deps needs -resource-dir when cross compiling2024-02-22T08:24:24-05:00Shuang Liucxxmodules: clang-scan-deps needs -resource-dir when cross compilingwith the latest cmake 3.28 with module support enabled, when cross compiling with clang, it's better to supply the rsult of `clang++ -print-resource-dir` as `-resource-dir` otherwise might run into this:
https://clang.llvm.org/docs/Stand...with the latest cmake 3.28 with module support enabled, when cross compiling with clang, it's better to supply the rsult of `clang++ -print-resource-dir` as `-resource-dir` otherwise might run into this:
https://clang.llvm.org/docs/StandardCPlusPlusModules.html#possible-issues-failed-to-find-system-headers3.28.4Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25511Issue with C++ modules and gcc2024-02-16T09:33:23-05:00FVIssue with C++ modules and gccHello, the following behaves as expected with clang but not with gcc trunk.
I had a look at what ninja is doing but I am not able to figure out if this a ninja or cmake or gcc issue.
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3....Hello, the following behaves as expected with clang but not with gcc trunk.
I had a look at what ninja is doing but I am not able to figure out if this a ninja or cmake or gcc issue.
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28) # With 3.28, no need for set(CMAKE_CXX_SCAN_FOR_MODULES ON).
project(std_module_example CXX)
set(CMAKE_CXX_STANDARD 20)
# Default to C++ extensions being off. Clang's modules support have trouble
# with extensions right now and it is not required for any other compiler
set(CMAKE_CXX_EXTENSIONS OFF)
add_library(foo)
target_sources(foo
PRIVATE
foo_impl.cxx
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES FILES
foo.cxx
)
add_executable(hello main.cxx)
target_link_libraries(hello PRIVATE foo)
```
main.cxx:
```
import foo;
int main() {
foo f;
f.helloworld();
return 0;
}
```
foo.cxx:
```
module;
#include <iostream>
export module foo;
export class foo {
public:
foo();
~foo();
void helloworld();
};
export void fun() {
std::cout << "abc" << std::endl;
}
```
foo_impl.cxx:
```
module; // Start of the globl module fragment where #includes can happen
#include <iostream>
module foo;
foo::foo() = default;
foo::~foo() = default;
void foo::helloworld() { std::cout << "hello worldad \n"; }
```
The issue is that the second ninja invocation below rebuilds main.o and foo.o with gcc (clang handles this correctly):
```
rm -rf CMakeFiles/ CMakeCache.txt build.ninja libfoo.a hello cmake_install.cmake
cmake -DCMAKE_BUILD_TYPE=Debug -GNinja
ninja
touch foo_impl.cxx
ninja -v -d explain
```
Versions:
```
cmake --version
cmake version 3.28.0
ninja --version
1.12.0.git
# Build from source...
g++ -v
gcc version 14.0.0 20231211 (experimental) (GCC)
clang -v
clang version 16.0.0
```
I attached the ninja outputs for [clang](/uploads/4693b18c2c2ce07861386d679483c987/clang_build.txt) and [gcc](/uploads/60a4bef80a0fe92cfc79caa5741d3e5a/gcc_build.txt).3.28.4Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25637CMake fails to configure CUDA using clang++-142024-01-26T08:10:49-05:00Eyal Rozenbergeyalroz1@gmx.comCMake fails to configure CUDA using clang++-14<sub>(Filed following [this SO answer](https://stackoverflow.com/a/77879291/1593077).)</sub>
I'm trying to configure a build with the following list file:
```
cmake_minimum_required(VERSION 3.24)
project(vector_addition_with_clang CUDA)...<sub>(Filed following [this SO answer](https://stackoverflow.com/a/77879291/1593077).)</sub>
I'm trying to configure a build with the following list file:
```
cmake_minimum_required(VERSION 3.24)
project(vector_addition_with_clang CUDA)
add_executable(vectorAdd vectorAdd.cu)
set_target_properties(vectorAdd PROPERTIES CUDA_ARCHITECTURES native)
```
and with the following command-line:
```
cmake -B build -DCMAKE_CUDA_HOST_COMPILER=clang++-14 -DCMAKE_CUDA_COMPILER=clang++-14
```
Now, if I replace clang++-14 with clang++-16, everything works fine. But with clang++-14 (and with `--debug-output`), I get:
```
-- The CUDA compiler identification is unknown
Called from: [3] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCompilerId.cmake
[2] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake
[1] /tmp/1_vector_addition/CMakeLists.txt
CMake Error at /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake:270 (message):
Failed to detect a default CUDA architecture.
Compiler output:
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
Called from: [2] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake
[1] /tmp/1_vector_addition/CMakeLists.txt
-- Configuring incomplete, errors occurred!
```
I get the same output if I replace the `native` architecture choice with a concrete value, e.g. `61`, corresponding to that of a GPU on my system.
Artifacts:
* Project source file and CMake list file: [bug_25637.tar.gz](/uploads/005559aa43ff689857481c6dc7d71e69/bug_25637.tar.gz)
* Trace file: [`trace.log.gz`](/uploads/1a3fd8e4cce07af9709eb87ca9d2421d/trace.log.gz)
* Build dir: [build_dir.tar.gz](/uploads/104e516554028d6f168ca6c7e362e853/build_dir.tar.gz)
System info:
* Devuan GNU/Linux Excalibur (like Debian Trixie but without systemd)
* CMake 3.28.1 binary distribution
* X86_64 machine
* CUDA 12.2 installed under /usr/local/cudahttps://gitlab.kitware.com/cmake/cmake/-/issues/20751Clang CUDA on Windows doesn't build without manual flags and standard paths2024-01-23T14:56:25-05:00Corentin SchreiberClang CUDA on Windows doesn't build without manual flags and standard pathsI have just tried to use CMake 3.17.20200520-g81e8f62 and clang to compile a CUDA project we normally build with nvcc. I bumped into a few issues:
- [x] ~~CMake seems to ignore the ``CMAKE_CUDA_COMPILER_WORKS`` option, so the compiler c...I have just tried to use CMake 3.17.20200520-g81e8f62 and clang to compile a CUDA project we normally build with nvcc. I bumped into a few issues:
- [x] ~~CMake seems to ignore the ``CMAKE_CUDA_COMPILER_WORKS`` option, so the compiler check is always performed.~~ This is [intended](https://gitlab.kitware.com/cmake/cmake/-/issues/20751#note_764869).
- [x] ~~At least during the compiler test, CMake does not seem to forward the ``CMAKE_CUDA_ARCHITECTURES`` values to clang, I have to set it manually using ``CMAKE_CUDA_FLAGS=--cuda-gpu-arch=XXX``. Otherwise it tries to compile for ``sm_20``, which apparently my CUDA installation (CUDA 10.1) doesn't support.~~ This was because ``cuda-path`` wasn't set, see below.
- [x] ~~Related to the above, I don't know how to make CMake compile for multiple GPU architectures at once. ``CMAKE_CUDA_ARCHITECTURES`` can contain an array of architectures (since nvcc can compile for multiple architectures at once), but since clang can only compile for one architecture at a time with ``--cuda-gpu-arch``, I cannot build multiple architectures with the trick above.~~ Trick no longer required.
- [x] CMake does not seem to forward the path to the CUDA runtime to clang, I have to set it manually using ``CMAKE_CUDA_FLAGS=--cuda-path=XXX``.
- [x] When linking the test program, the clang linker cannot find the CUDA lib files because the linker include path is set to just ``<CUDA_PATH>/lib`` (which is empty) instead of ``<CUDA_PATH>/lib/x64`` (which contains the 64bit lib files). I copied the lib files manually into the ``lib`` folder.
After that last step, CMake decided the compiler was working.
Then I went on to compile our project, a shared library, in ``CMAKE_BUILD_TYPE=RelWithDebInfo``. Generator is MinGW Makefiles. Compilation went fine, however at link time there were inconsistencies in the runtime libraries being used. CXX files correctly used ``MD_DynamicRelease``, but CU files used ``MT_StaticRelease``. This can be seen below.
With ``VERBOSE=1``, ``mingw32-make`` reports the following CXX compiler command being used:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE <CUSTOM_PREPROCESSOR> <CUSTOM_INCLUDE_PATHS> -O2 -g -DNDEBUG -Xclang -gcodeview -D_DLL -D_MT -Xclang --dependent-lib=msvcrt <CUSTOM_COMPILER_OPTS> -o <OUTPUT_FILE> -c <CXX_FILE>
```
and the following CU compiler command:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE <CUSTOM_PREPROCESSOR> <CUSTOM_INCLUDE_PATHS> --cuda-gpu-arch=sm_30 --cuda-path=C:/mingw/cuda --cuda-gpu-arch=sm_30 <CUSTOM_COMPILER_OPTS> -std=gnu++14 -x cuda -c <CUDA_FILE> -o <OUTPUT_FILE>
```
and for the linker:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -O2 -g -DNDEBUG -Xclang -gcodeview -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -shared -o <OUTPUT_DLL> -Xlinker /implib:<LIBRARY>.lib -Xlinker /pdb:<LIBRARY>.pdb -Xlinker /version:0.0 <OBJECTS> <LINK_LIBS>
```
Notice how ``-D_DLL -D_MT`` are missing for the CU compilation command, but also other important compilation flags, like ``-O2 -g``. Notice also how there are now two ``--cuda-gpu-arch=sm_30``; I guess one of them is the one I added manually in ``CMAKE_CUDA_FLAGS`` (to make the compiler test pass) and the other was added by CMake somehow.https://gitlab.kitware.com/cmake/cmake/-/issues/20776CUDA: Support Clang on Windows2024-01-23T14:56:21-05:00Raul Tambreraul@tambre.eeCUDA: Support Clang on WindowsCMake must set correct flags on Windows for Clang. Originally reported in #20751.CMake must set correct flags on Windows for Clang. Originally reported in #20751.https://gitlab.kitware.com/cmake/cmake/-/issues/20851Introduce <LANG>_STANDARD_LIBRARY2023-12-27T14:14:35-05:00Raul Tambreraul@tambre.eeIntroduce <LANG>_STANDARD_LIBRARY## Motivation
With the diversification of standard libraries implementations for C and C++ it has become desirable to be able to detect and change the used standard library from CMake in an easy and portable manner.
## Implementation
...## Motivation
With the diversification of standard libraries implementations for C and C++ it has become desirable to be able to detect and change the used standard library from CMake in an easy and portable manner.
## Implementation
CMake will add additional compiler flags pertaining to the standard library if `<LANG>_STANDARD_LIBRARY` differs from the detected default.
* If the default standard library is false/`"NOTFOUND"` setting `<LANG>_STANDARD_LIBRARY` to non-false values is an error due to possible problems stemming from duplicate or conflicting options with the compiler's default standard library.
* If the `<LANG>_STANDARD_LIBRARY_<LIBRARY>` is false or not set, setting `<LANG>_STANDARD_LIBRARY` to `<LIBRARY>` is an error. False values would be reported as "unsupported", unset as "unknown".
The handling of default standard libraries allows introducing this functionality without requiring a policy.
The false/`"NOTFOUND"` value will allow adding support for new platforms and standard libraries without backwards compatibility concerns.
Compiler modules would set the following variables:
* `CMAKE_<LANG>_STANDARD_LIBRARY_<LIBRARY>`
* `CMAKE_<LANG>_STANDARD_LIBRARY_<LIBRARY>_COMPILE_OPTIONS`
* `CMAKE_<LANG>_STANDARD_LIBRARY_<LIBRARY>_LINK_OPTIONS`
##### `CMAKE_<LANG>_STANDARD_LIBRARY`
Contains the value of the detected default standard library for the current language's compiler. May be modified by user.
Special values:
* false/`"NOTFOUND"` if the standard library is unknown.
* `none` for no standard library.
##### `CMAKE_<LANG>_STANDARD_LIBRARY_DEFAULT`
Set to the detected default standard library. Stored in `CMake<LANG>Compiler.cmake`. Read-only.
Used internally for detecting if the user changed `CMAKE_<LANG>_STANDARD_LIBRARY` from the default.
##### `CMAKE_<LANG>_STANDARD_LIBRARY_<LIBRARY>`
Set to true if supported by the current compiler. False if not supported (e.g. compiler version too old). Unset if compiler module is unaware of such a standard library.
##### `<LANG>_STANDARD_LIBRARY`
Initialized by `CMAKE_<LANG>_STANDARD_LIBRARY`.
##### `CXX_STANDARD_LIBRARY`
* `libstdc++` – GNU C++ standard library
* `libc++` – LLVM C++ standard library
* `msvc` – Microsoft C++ standard library
#### Custom standard libraries
Custom or exotic default standard libraries not known by CMake would be detected as false/`"NOTFOUND"` and thus CMake won't mess with standard library options. The new mechanism won't introduce backwards incompatibility in such cases.
It would be possible for users to add support for custom standard libraries not known by CMake by setting `<LANG>_STANDARD_LIBRARY_<LIBRARY>`, `<LANG>_STANDARD_LIBRARY_<LIBRARY>_COMPILE_OPTIONS`, `<LANG>_STANDARD_LIBRARY_<LIBRARY>_LINK_OPTIONS`, etc.
However, it seems advisable to avoid documenting and explicitly supporting custom standard libraries for a while to allow revising these variables in future versions to better support various combinations of compilers and standard libraries.
## Steps
Initial:
1. [ ] Default C++ standard library detection of `none`, `libstdc++`, `libc++` on Clang.
2. [ ] Ability to choose between `none`, `libstdc++`, `libc++` on Clang.
3. [ ] GCC support.
Future:
1. [ ] Extend support to MSVC with `none`, `msvc`, `libc++`.
2. [ ] Extend support to C with at least `none`, `glibc` on GCC, MSVC and Clang.
3. [ ] Custom standard library support once there's enough real-world experience with adding support for standard libraries on various compilers.https://gitlab.kitware.com/cmake/cmake/-/issues/25465C++20 module is broken (missing transitive usage) when the files are listed i...2023-12-06T08:51:25-05:00Tan S. B.C++20 module is broken (missing transitive usage) when the files are listed in a certain orderCMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28.0)
project(MyLib LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)
add_library(my-lib)
target_sources(my-lib PRIVATE FILE_SET CXX_MODULES FILES
mod1.cpp
mod3.cpp # import mod2
...CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28.0)
project(MyLib LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)
add_library(my-lib)
target_sources(my-lib PRIVATE FILE_SET CXX_MODULES FILES
mod1.cpp
mod3.cpp # import mod2
mod4.cpp # import mod2
mod2.cpp # import mod1
mod5.cpp # import mod4
mod6.cpp # import mod5
)
```
All module units are empty except for the imports as indicated in the comments above.
When compiling this project against Clang, I got
```
[13/14] Building CXX object CMakeFiles/my-lib.dir/mod6.cpp.o
/mnt/d/test/test-module/mod6.cpp:2:1: warning: it is deprecated to read module 'mod1' implicitly; it is going to be removed in clang 18; consider to specify the dependencies explicitly [-Wread-modules-implicitly]
2 | import mod5;
| ^
1 warning generated.
warning: it is deprecated to read module 'mod1' implicitly; it is going to be removed in clang 18; consider to specify the dependencies explicitly [-Wread-modules-implicitly]
1 warning generated.
```
It seems that CMake forgets to tell Clang the location of `mod1.pcm` when compiling `mod6.cpp`.
Note that the order of files in `target_souces` is significant. The warning might not occur if the files are listed in a different order.
For the reference, here's the project in a zip file: [test-module.zip](/uploads/bd15f05a571c875d3bf1bd5fef844dd7/test-module.zip)3.28.0Namniav WNamniav Whttps://gitlab.kitware.com/cmake/cmake/-/issues/25449macOS: CMake uses a mix of tools provided by LLVM and Apple while compile wit...2023-11-29T10:41:03-05:00Kuntal MajumdermacOS: CMake uses a mix of tools provided by LLVM and Apple while compile with vanilla LLVMWhile compiling blender on macOS (m1 pro) with llvm-17 installed via homebrew, it complained that the static library could not be recognised.
Here is the warning during compilation which hints about using a wrong format for the static li...While compiling blender on macOS (m1 pro) with llvm-17 installed via homebrew, it complained that the static library could not be recognised.
Here is the warning during compilation which hints about using a wrong format for the static library,
```
ld: warning: ld: warning: ignoring file lib/libbf_dna.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
```
After a bit of digging, I found out, while CMake used the 'llvm-ranlib' for CMAKE_RANLIB, for CMAKE_AR it was using '/usr/bin/ar' and not 'llvm-ar'. Which after [those](https://github.com/blender/blender/blob/01a2bd03695f217616acc2581fe8746f5cd226d7/build_files/cmake/platform/platform_apple.cmake#L431) particular flags, produce an archive which can't be read by LLVM.
On further looking into CMake, I ran into the commit which disable loading of llvm-ar on apple platforms, which cited issues with the Apple linker. But according to [this](https://discourse.llvm.org/t/how-stable-is-ld64-lld/69628/8) comment, ld64.lld should be a drop in replacement for the Apple linker.https://gitlab.kitware.com/cmake/cmake/-/issues/23269macOS: CMake may generate invalid static libraries using Clang2023-11-28T17:21:53-05:00Saleem AbdulrasoolmacOS: CMake may generate invalid static libraries using ClangWhen `llvm-ar` is available in `PATH`, CMake will prefer that over `ar` (assuming a LLVM based toolchain IIRC). On Darwin platforms, there is no `llvm-ar` available by default so this is unlikely to occur. However, should it occur, the...When `llvm-ar` is available in `PATH`, CMake will prefer that over `ar` (assuming a LLVM based toolchain IIRC). On Darwin platforms, there is no `llvm-ar` available by default so this is unlikely to occur. However, should it occur, the use of a different librarian causes issues as `llvm-ar` does not generate a symbol table which `ld64` deems cromulent. Attempting to link with the resulting library will fail with an obscure error message:
```
ld: warning: ignoring file ..., building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
```
Ideally, we should be using `libtool` to generate the static library on Darwin as that is the officially supported librarian in cctools.3.21.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25429CMake Error: -E cmake_ninja_dyndep failed to parse CMakeFiles/main.dir/main.c...2023-11-22T07:20:10-05:00Namniav WCMake Error: -E cmake_ninja_dyndep failed to parse CMakeFiles/main.dir/main.cpp.o.ddi: expected 1 source entryRepro steps:
0. Versions
```
$ cmake --version
cmake version 3.28.20231118-gee3e050
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ninja --version
1.11.1
$ clang++ --version
Homebrew clang version 17.0.4
Target: ...Repro steps:
0. Versions
```
$ cmake --version
cmake version 3.28.20231118-gee3e050
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ninja --version
1.11.1
$ clang++ --version
Homebrew clang version 17.0.4
Target: arm64-apple-darwin23.1.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
```
1. CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.28)
project(demo CXX)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
if(MESSING)
add_compile_options(-fsanitize=nosupport)
add_link_options(-fsanitize=nosupport)
endif()
add_executable(main main.cpp) # main.cpp's content is "int main() {}"
```
2. Configure and build without defined `MESSING`. This succeeds as expected.
```
$ rm -rf build
$ CXX=`which clang++` cmake -GNinja -S . -B build && cmake --build build
-- The CXX compiler identification is Clang 17.0.4
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/homebrew/opt/llvm/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-test/build
[4/4] Linking CXX executable main
```
3. Reconfigure and build with defined `MESSING`. This fails as expected.
```
$ cmake -DMESSING=1 build && cmake --build build
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-test/build
[1/4] Scanning /tmp/cmake-test/main.cpp for CXX dependencies
FAILED: CMakeFiles/main.dir/main.cpp.o.ddi
"/opt/homebrew/Cellar/llvm/17.0.4/bin/clang-scan-deps" -format=p1689 -- /opt/homebrew/opt/llvm/bin/clang++ -fsanitize=nosupport -std=c++20 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -x c++ /tmp/cmake-test/main.cpp -c -o CMakeFiles/main.dir/main.cpp.o -MT CMakeFiles/main.dir/main.cpp.o.ddi -MD -MF CMakeFiles/main.dir/main.cpp.o.ddi.d > CMakeFiles/main.dir/main.cpp.o.ddi
error: unsupported argument 'nosupport' to option '-fsanitize='
Error while scanning dependencies for /tmp/cmake-test/main.cpp:
error: unsupported argument 'nosupport' to option '-fsanitize='
ninja: build stopped: subcommand failed.
```
4. Reconfigure and build without defined `MESSING`. **This fails as UN-expected.**
```
$ cmake -DMESSING=0 build && cmake --build build
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-test/build
[1/1] Generating CXX dyndep file CMakeFiles/main.dir/CXX.dd
FAILED: CMakeFiles/main.dir/CXX.dd /tmp/cmake-test/build/CMakeFiles/main.dir/CXXModules.json CMakeFiles/main.dir/main.cpp.o.modmap
/opt/homebrew/Cellar/cmake/HEAD-ee3e050/bin/cmake -E cmake_ninja_dyndep --tdi=CMakeFiles/main.dir/CXXDependInfo.json --lang=CXX --modmapfmt=clang --dd=CMakeFiles/main.dir/CXX.dd @CMakeFiles/main.dir/CXX.dd.rsp
CMake Error: -E cmake_ninja_dyndep failed to parse CMakeFiles/main.dir/main.cpp.o.ddi: expected 1 source entry
CMake Error: -E cmake_ninja_dyndep failed to parse ddi file CMakeFiles/main.dir/main.cpp.o.ddi
ninja: build stopped: subcommand failed.
$ cat build/CMakeFiles/main.dir/main.cpp.o.ddi
{
"revision": 0,
"rules": [],
"version": 1
}
```
5. After `cmake --build build --target clean`, it succeeds as expected.
```
$ cmake --build build --target clean && cmake --build build
[1/1] Cleaning all built files...
Cleaning... 8 files.
[4/4] Linking CXX executable main
$ cat build/CMakeFiles/main.dir/main.cpp.o.ddi
{
"revision": 0,
"rules": [
{
"primary-output": "CMakeFiles/main.dir/main.cpp.o"
}
],
"version": 1
}
```
Edited: fixed wrong copied command output.3.28.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/22668clang-cl: Use new value "ClangCl" for CMAKE_<LANG>_COMPILER_ID2023-11-17T07:07:17-05:00Deniz Bahadirclang-cl: Use new value "ClangCl" for CMAKE_<LANG>_COMPILER_IDWith the introduction of `clang-cl` on Windows (conditionally) setting compiler-options in CMake became more difficult.
While `clang` accepts traditional Clang/GCC options, `clang-cl` is a frontend which accepts MSVC options but no lon...With the introduction of `clang-cl` on Windows (conditionally) setting compiler-options in CMake became more difficult.
While `clang` accepts traditional Clang/GCC options, `clang-cl` is a frontend which accepts MSVC options but no longer directly accepts traditional Clang/GCC options.
Now, one not only has to check the `CMAKE_<LANG>_COMPILER_ID` variable but additionally `CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT`. (See: #22666)
Even worse, CMake-code that originally worked perfectly fine on different operating systems with different compilers now fails on Windows because it can no longer differentiate between `clang` and `clang-cl`. This is particularly true when using the generator-expression `$<COMPILE_LANG_AND_ID:...>` or `$<CXX_COMPILER_ID:...>` etc. (See: #22432)
---
I therefore suggest to introduce a new value for `CMAKE_<LANG>_COMPILER_ID` called "`ClangCl`" (similar to "`AppleClang`") which shall be used when `clang-cl` is used, to simply differentiate between `clang` and `clang-cl`.
Of course, that should also work with the associated generator-expressions.https://gitlab.kitware.com/cmake/cmake/-/issues/25180[clang-scan-deps] [C++] [modules] Calculate resouce_directoty in case the use...2023-10-29T22:42:18-04:00Chuanqi Xu[clang-scan-deps] [C++] [modules] Calculate resouce_directoty in case the users pass compiler executable by symlink<!--
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/
-->
By default, the clang-scan-deps have problems to find headers from the resource dir like (`stddef.h`) if the provided compiler exectuable is a symlink instead of a real compiler. (See https://github.com/llvm/llvm-project/issues/61006 for history).
Then we updated the corresponding solution in https://clang.llvm.org/docs/StandardCPlusPlusModules.html#possible-issues-failed-to-find-system-headers but it doesn't work automatically. The solution requires the build systems to update the ways the invoke `clang-scan-deps`.
If we don't fix the issue, the user may have a bad experience since in many distributions the compiler `clang++` is a symlink.https://gitlab.kitware.com/cmake/cmake/-/issues/24235Clang on Windows does not show color diagnostics unless -fansi-escape-codes i...2023-10-23T12:06:38-04:00Alvin WongClang on Windows does not show color diagnostics unless -fansi-escape-codes is addedOn Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes...On Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes` to the C/CXX flags. I tested two different scenarios:
- Windows console (cmd.exe) + ninja + [llvm-mingw](https://github.com/mstorsjo/llvm-mingw)
- GitHub Actions Windows runner + mingw32-make + llvm-mingw
I am not sure if this counts as a CMake issue or Clang's, but Clang always uses the Windows console API by default unless -fansi-escape-codes is given, and I guess it doesn't have direct access to the Windows console when run under make or ninja.https://gitlab.kitware.com/cmake/cmake/-/issues/24021clang-cl.exe compiler test fails with --coverage flag2023-09-27T10:01:47-04:00gatkinsoclang-cl.exe compiler test fails with --coverage flagWindows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
```
C:\Users\me\source\scratch\build>cmake -T ClangCL -D CMAKE_CXX_FLAGS="--coverage" ..
-- Building for: Visual Studio 17 2022
-- ...Windows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
```
C:\Users\me\source\scratch\build>cmake -T ClangCL -D CMAKE_CXX_FLAGS="--coverage" ..
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is Clang 14.0.5 with MSVC-like command-line
-- The CXX compiler identification is Clang 14.0.5 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.23/Modules/CMakeTestCXXCompiler.cmake:62 (message):
The C++ compiler
"C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/me/source/scratch/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/Program Files/Microsoft Visual Studio/2022/Community/MSBuild/Current/Bin/amd64/MSBuild.exe cmTC_3dd07.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=17.0 /v:m && MSBuild version 17.3.1+2badb37d1 for .NET Framework
lld-link : error : undefined symbol: llvm_gcda_start_file [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_emit_function [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_emit_arcs [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_summary_info [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_end_file [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcov_init [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_init)
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
-- Configuring incomplete, errors occurred!
See also "C:/Users/me/source/scratch/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/me/source/scratch/build/CMakeFiles/CMakeError.log".
```
CMakeLists.txt
```
cmake_minimum_required (VERSION 3.20)
project (test1)
set (CMAKE_CXX_STANDARD 11)
add_executable(test1 main.cpp)
```
main.cpp
```
#include <iostream>
int main()
{
std::cout << "hello World" << std::endl;
return 0;
}
```
Possibly related to: https://bugs.llvm.org/show_bug.cgi?id=40877https://gitlab.kitware.com/cmake/cmake/-/issues/24025VS: Use ClangCL toolset with coverage flag2023-09-27T09:51:55-04:00gatkinsoVS: Use ClangCL toolset with coverage flagWindows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
It appears that cmake generates an invalid MSVC solution/project file(s) when using the integrated LLVM
toolkit. Resultant coverag...Windows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
It appears that cmake generates an invalid MSVC solution/project file(s) when using the integrated LLVM
toolkit. Resultant coverage files have no file name only a suffix, resulting in errors generating coverage data.
While searching for workaround for issue in https://gitlab.kitware.com/cmake/cmake/-/issues/24021
I ran the following:
```
PS C:\Users\me\source\scratch\build> cmake -T ClangCL -D COVERAGE:BOOL=ON ..
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is Clang 14.0.5 with MSVC-like command-line
-- The CXX compiler identification is Clang 14.0.5 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/me/source/scratch/build
PS C:\Users\me\source\scratch\build> cmake --build . --config Debug
(builds)
```
Running the generated executable results in
```
PS C:\Users\me\source\scratch\build> .\Debug\test1.exe
it is smaller
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: mismatched number of counters (2)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous run count: corrupt object tag (0x00000000)
```
I note the following coverage files are generated:
```
PS C:\Users\me\source\scratch\build> dir C:\Users\me\source\scratch\build\test1.dir\Debug
Directory: C:\Users\me\source\scratch\build\test1.dir\Debug
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10/4/2022 9:23 AM test1.tlog
-a---- 10/4/2022 9:24 AM 76 .gcda << there should be a test1.gcda and a main.gcda
-a---- 10/3/2022 4:00 PM 3268 .gcno << there should be a test1.gcno and a main.gcno
-a---- 10/3/2022 4:00 PM 7224 main.obj
-a---- 10/4/2022 9:23 AM 428 test1.exe.recipe
-a---- 10/3/2022 4:00 PM 34668 test1.obj
```
CMakeLists.txt
```
cmake_minimum_required (VERSION 3.20)
project (test1)
set (CMAKE_CXX_STANDARD 14)
option(COVERAGE "Generate Coverage Data" OFF)
add_executable(test1 main.cpp test1.cpp)
if(COVERAGE)
set(MY_DEBUG_OPTIONS "--coverage")
target_compile_options(test1 PUBLIC "${MY_DEBUG_OPTIONS}")
target_link_libraries(test1 "clang_rt.profile-x86_64.lib")
endif(COVERAGE)
```
test1.h
```
#pragma once
bool iffy(int i);
```
test1.cpp
```
#include <iostream>
#include "test1.h"
bool iffy(int i)
{
auto ret = true;
if( i > 100 ) {
std::cout << "it is larger" << std::endl;
}
else {
std::cout << "it is smaller" << std::endl;
ret = false;
}
return ret;
}
```
main.cpp
```
#include "test1.h"
int main()
{
iffy(1);
return 0;
}
```
Possibly related to:
https://bugs.llvm.org/show_bug.cgi?id=40877
https://gitlab.kitware.com/cmake/cmake/-/issues/24021https://gitlab.kitware.com/cmake/cmake/-/issues/25277VS: custom LLVM location and version for ClangCL toolset2023-09-27T09:30:24-04:00yuryburaVS: custom LLVM location and version for ClangCL toolsetHow to let CMake know to use custom LLVM location and version for ClangCL toolset?
MS provides the following solution:
https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170#custom_llvm_location
But this is no ...How to let CMake know to use custom LLVM location and version for ClangCL toolset?
MS provides the following solution:
https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170#custom_llvm_location
But this is no good because during CMake generation the LLVM path will be incorrect (default for VS).https://gitlab.kitware.com/cmake/cmake/-/issues/21133Add support for new clang flags for PCH in `target_precompile_headers()`2023-08-23T07:01:46-04:00Tobias HietaAdd support for new clang flags for PCH in `target_precompile_headers()`In Clang 11 (in RC2 right now) there a few new options for the PCH added that will speed up compilation even more:
```
-fpch-instantiate-templates tries to instantiate templates already while generating a precompiled header. Such templa...In Clang 11 (in RC2 right now) there a few new options for the PCH added that will speed up compilation even more:
```
-fpch-instantiate-templates tries to instantiate templates already while generating a precompiled header. Such templates do not need to be instantiated every time the precompiled header is used, which saves compile time. This may result in an error during the precompiled header generation if the source header file is not self-contained. This option is enabled by default for clang-cl.
-fpch-codegen and -fpch-debuginfo generate shared code and/or debuginfo for contents of a precompiled header in a separate object file. This object file needs to be linked in, but its contents do not need to be generated for other objects using the precompiled header. This should usually save compile time. If not using clang-cl, the separate object file needs to be created explicitly from the precompiled header. Example of use:
$ clang++ -x c++-header header.h -o header.pch -fpch-codegen -fpch-debuginfo
$ clang++ -c header.pch -o shared.o
$ clang++ -c source.cpp -o source.o -include-pch header.pch
$ clang++ -o binary source.o shared.o
Using -fpch-instantiate-templates when generating the precompiled header usually increases the amount of code/debuginfo that can be shared.
In some cases, especially when building with optimizations enabled, using -fpch-codegen may generate so much code in the shared object that compiling it may be a net loss in build time.
Since headers may bring in private symbols of other libraries, it may be sometimes necessary to discard unused symbols (such as by adding -Wl,–gc-sections on ELF platforms to the linking command, and possibly adding -fdata-sections -ffunction-sections to the command generating the shared object).
```
It would be very neat if CMake supported these options.
The first option `-fpch-instantiate-templates` can be set by just adding it to the CMAKE_CXX_FLAGS - but the codegen option needs to have more logic that can build the shared object and link it to the target. This can probably be done with custom logic - but I am not sure if we can currently set CXXFLAGS specifically for the PCH compilation.