CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-05-30T22:02:04-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/24952cmake include_directories(<path>) can't be resolve in clangd correctly2023-05-30T22:02:04-04:00Caleb_Ducmake include_directories(<path>) can't be resolve in clangd correctlyi use clangd extension in vscode. and i include some header-only 3party libraries in c++ project by include_directories(`<path>`).
cmake generate compiler_commands.json withuot -I `<path>`. so clangd can't resolve these paths. after i a...i use clangd extension in vscode. and i include some header-only 3party libraries in c++ project by include_directories(`<path>`).
cmake generate compiler_commands.json withuot -I `<path>`. so clangd can't resolve these paths. after i add "-I `<path>`" in compiler_commands.json. clangd works.
so how to let cmake add "-I `<paths>`" in compiler_commands.json automaticly?https://gitlab.kitware.com/cmake/cmake/-/issues/24031CMake 3.24 FindThreads adds -lpthread to link args for MSVC2022-10-19T11:21:40-04:00Gavin KinseyCMake 3.24 FindThreads adds -lpthread to link args for MSVCWe recently had a problem with our builds using CMake 3.24.2 and MSVC.
```
LINK : warning LNK4044: unrecognized option '/lpthreads'; ignored [X.vcxproj]
LINK : error LNK1218: warning treated as error; no output file generated [X.vcxproj...We recently had a problem with our builds using CMake 3.24.2 and MSVC.
```
LINK : warning LNK4044: unrecognized option '/lpthreads'; ignored [X.vcxproj]
LINK : error LNK1218: warning treated as error; no output file generated [X.vcxproj]
```
It looks like the issue has been encountered before and resolved in #23829 but we are still having the issue.
For now, I've created a modified version of FindThreads.cmake with lines commented out. Hopefully this should give you the info needed to resolve properly.
```
--- C:/Program Files/CMake/share/cmake-3.24/Modules/FindThreads.cmake Thu Oct 6 11:07:14 2022
+++ C:/Users/gavinkinsey/Documents/src/X/scripts/cmake/CMakeModules/FindThreads.cmake Thu Oct 6 10:58:28 2022
@@ -176,8 +176,8 @@
if(CMAKE_SYSTEM MATCHES "GHS-MULTI")
_threads_check_lib(posix pthread_create CMAKE_HAVE_PTHREADS_CREATE)
endif()
-_threads_check_lib(pthreads pthread_create CMAKE_HAVE_PTHREADS_CREATE)
-_threads_check_lib(pthread pthread_create CMAKE_HAVE_PTHREAD_CREATE)
+#_threads_check_lib(pthreads pthread_create CMAKE_HAVE_PTHREADS_CREATE)
+#_threads_check_lib(pthread pthread_create CMAKE_HAVE_PTHREAD_CREATE)
if (NOT THREADS_PREFER_PTHREAD_FLAG)
_threads_check_flag_pthread()
```
If you need any more info or tests running please let me know, happy to help.Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23038CUDArt link order regression with 3.22.02022-01-28T13:46:29-05:00Florian BerchtoldCUDArt link order regression with 3.22.0With the upgrade from 3.21.3 to 3.22.0, the static build of a library depending on CUDA symbols does not work anymore. It fails with:
```
/home/fberchtold/.conan/data/lum_platform_system_gpu/1.0.0/_/_/package/305be889d357f53551516450d8ab...With the upgrade from 3.21.3 to 3.22.0, the static build of a library depending on CUDA symbols does not work anymore. It fails with:
```
/home/fberchtold/.conan/data/lum_platform_system_gpu/1.0.0/_/_/package/305be889d357f53551516450d8abe1ab5b425f1e/lib/liblum_platform_system_gpu.a(gpu_nvidia.cpp.o): In function `lum::platform::system::gpu::nvidia::GpuDataManager::getGpuMemory()':
gpu_nvidia.cpp:(.text+0x1d8): undefined reference to `cudaGetDeviceCount'
gpu_nvidia.cpp:(.text+0x1fe): undefined reference to `cudaSetDevice'
gpu_nvidia.cpp:(.text+0x209): undefined reference to `cudaMemGetInfo'
```
Relevant CMake:
```
enable_language(CUDA)
find_package(CUDAToolkit REQUIRED)
add_library(lum_platform_system_gpu src/gpu_nvidia.cpp)
target_include_directories(lum_platform_system_gpu PUBLIC include)
target_link_libraries(lum_platform_system_gpu PUBLIC CUDA::cudart)
add_executable(gpu_test gpu_nvidia_test.cpp)
target_link_libraries(gpu_test PRIVATE lum_platform_system_gpu)
```
I found out that one of the differences between the two versions is the link order in `link.txt`:
- `3.21.3 - working`: `/usr/local/cuda/lib64/libcudart.so` is last to be linked
- `3.22.0 - fails`: `/usr/local/cuda/lib64/libcudart.so` is linked before the library using its symbols
FYI: shared builds of the library still seem to work.https://gitlab.kitware.com/cmake/cmake/-/issues/22894Build fails on missing depfile, but only on some machines2022-05-16T17:16:37-04:00Craig ScottBuild fails on missing depfile, but only on some machinesI have a rather difficult to follow issue that I've been unable to track down the cause of. It reproduces only on a couple of machines (both Ubuntu 18 LTS as far as I'm aware), but the same project on other Ubuntu 18 LTS machines doesn't...I have a rather difficult to follow issue that I've been unable to track down the cause of. It reproduces only on a couple of machines (both Ubuntu 18 LTS as far as I'm aware), but the same project on other Ubuntu 18 LTS machines doesn't exhibit the problem (same GCC, `make` and `ninja` versions too). It is 100% reproducible on the machines where it does occur. The error message from the compiler has the following form (sorry for the brevity, I can't share details about this particular project):
```
cc1: fatal error: CMakeFiles/somewhere.dir/src/main.c.d: No such file or directory
```
After various investigations, I have narrowed down the situation to the following:
* It only started with CMake 3.20, and it occurs with Ninja or Unix Makefiles as the generator.
* I can't reproduce it with CMake 3.19.8 with any generator.
* Setting `CMAKE_DEPENDS_USE_COMPILER` to false works around the problem for now.
* The file being complained about isn't mentioned anywhere in the Makefile or Ninja project files. Instead of `main.c.d`, there's only `main.c.o.d`. I haven't been able to find any trace of where the `main.c.d` file name is coming from.
I don't have direct access to the problematic machines, but their owners are responsive and motivated to help work out the cause. If you have ideas for further things to try to track down the problem, I'd be very interested. I'd say this is a fairly clear regression, since it only started with CMake 3.20 for an otherwise working project.https://gitlab.kitware.com/cmake/cmake/-/issues/22784Include guards added to Check...SourceCompiles modules lock in policy setting...2023-12-27T01:51:46-05:00Craig ScottInclude guards added to Check...SourceCompiles modules lock in policy settings of first inclusionSplitting this out of https://gitlab.kitware.com/cmake/cmake/-/issues/22766#note_1049936, see there for a scenario where this came up.
The include guards were added by !1327, which was part of an effort to improve CMake's performance. #...Splitting this out of https://gitlab.kitware.com/cmake/cmake/-/issues/22766#note_1049936, see there for a scenario where this came up.
The include guards were added by !1327, which was part of an effort to improve CMake's performance. #22766 shows an example where that has led to a change in behavior - the policies associated with the function defined in those files are no longer controlled by the last thing to include them, but instead by the first. We also saw an example of a very similar thing for the `CheckIPOSupported` module back in that MR (see [Brad's comment](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1327#note_348658)).
Projects are no longer able to influence the behavior of the functions these modules define after they have been included once. Since this wasn't the case before !1327, we should consider this a regression. But that change was in CMake 3.11, so we've had many releases since then. Reverting it now could be considered another regression, but the original behavior would seem to be the more correct.https://gitlab.kitware.com/cmake/cmake/-/issues/22298TI toolchain: Location of .map file changed since CMake 3.18.02023-05-09T19:36:08-04:00Craig ScottTI toolchain: Location of .map file changed since CMake 3.18.0In !4422, commit 5a0fc68312e9b5dd3f341660504d69220647437c, the value of `CMAKE_C_LINK_EXECUTABLE` changed from specifying `--map_file=<TARGET>.map` to `--map_file=<TARGET_NAME>.map`. The effect of this is that when the target has its out...In !4422, commit 5a0fc68312e9b5dd3f341660504d69220647437c, the value of `CMAKE_C_LINK_EXECUTABLE` changed from specifying `--map_file=<TARGET>.map` to `--map_file=<TARGET_NAME>.map`. The effect of this is that when the target has its output directory specified, the `.map` file no longer honors that and always gets written out to `${CMAKE_CURRENT_BINARY_DIR}` instead of the same directory as the target's executable. This broke a project I'm currently updating from using CMake 3.17.https://gitlab.kitware.com/cmake/cmake/-/issues/20535CCMake performance regression [MacOS Only]2020-05-05T09:20:43-04:00Robert MaynardCCMake performance regression [MacOS Only]ccmake for 3.17 looks to have a performance regression on projects that generate lots of output text on MacOS.
Given the following sample `CMakeLists.txt`, when run under `ccmake` you can watch the linear slowdown with each subsequent
`...ccmake for 3.17 looks to have a performance regression on projects that generate lots of output text on MacOS.
Given the following sample `CMakeLists.txt`, when run under `ccmake` you can watch the linear slowdown with each subsequent
`message`
```cmake
project(sample)
foreach(v RANGE 150)
message(STATUS "${v}")
endforeach()
```
Benchmark
| version | cmake | ccmake |
| ------ | ------ | ------ |
| 3.16 | ~3ms | ~2sec |
| 3.17 | ~4ms | ~32sec |3.17.1Sylvain JoubertSylvain Jouberthttps://gitlab.kitware.com/cmake/cmake/-/issues/19442MACOSX_BUNDLE_INFO_PLIST regression?2019-09-19T14:41:38-04:00Sander StoksMACOSX_BUNDLE_INFO_PLIST regression?The MACOSX_BUNDLE_INFO_PLIST override doesn't seem to work anymore in CMake 3.14. I noticed that after upgrading my local CMake from 3.9.1 to 3.14, the Mac app I wrote using Qt suddenly had awful font rendering. This is solved by addin...The MACOSX_BUNDLE_INFO_PLIST override doesn't seem to work anymore in CMake 3.14. I noticed that after upgrading my local CMake from 3.9.1 to 3.14, the Mac app I wrote using Qt suddenly had awful font rendering. This is solved by adding
<key>NSPrincipalClass</key>
<string>NSApplication</string>
to the info.plist file. (see also https://stackoverflow.com/questions/34465506/retina-support-in-qt5-on-os-x).
However, info.plist is generated from MacOSXBundleInfo.plist.in, which I had already added to my own source archive and pointed MACOSX_BUNDLE_INFO_PLIST to it. This no longer works. I verified this by renaming the MacOSXBundleInfo.plist.in in /Applications/CMake.app/Contents/share/cmake-3.14/Modules/, after which I got the error that it could no longer be found.
I was able to work around the issue by editing the template directly in the CMake install location (since I'm admin on my own machine), but this is obviously not ideal.
I'm not sure in which version between 3.9.1 and 3.14 this functionality broke.