CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-11-30T09:08:56-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25416LINK_LIBRARY:feature causes INTERFACE_LINK_LIBRARIES_DIRECT to be linked with...2023-11-30T09:08:56-05:00Balázs OrosziLINK_LIBRARY:feature causes INTERFACE_LINK_LIBRARIES_DIRECT to be linked with that featureOriginal discussion: https://discourse.cmake.org/t/link-library-whole-archive-affects-interface-link-libraries-direct-is-that-intentional/9420
Given the following minimal project:
```cmake
cmake_minimum_required(VERSION 3.25)
project(w...Original discussion: https://discourse.cmake.org/t/link-library-whole-archive-affects-interface-link-libraries-direct-is-that-intentional/9420
Given the following minimal project:
```cmake
cmake_minimum_required(VERSION 3.25)
project(watest)
add_library(lib1 STATIC lib1.cpp)
add_library(lib2 STATIC lib2.cpp)
#target_link_libraries(lib2 PRIVATE lib1) # case 1: <-- use this OR the line below ONLY
set_property(TARGET lib2 PROPERTY INTERFACE_LINK_LIBRARIES_DIRECT lib1) # case 2: <-- use this OR the line above ONLY
add_executable(app main.cpp)
target_link_libraries(app PRIVATE $<LINK_LIBRARY:WHOLE_ARCHIVE,lib2>)
```
Using **case 1**: `target_link_libraries(lib2 PRIVATE lib1)` it works normally as expected, link line from compiling:
```
link.exe ... /WHOLEARCHIVE:Debug\lib2.lib Debug\lib1.lib ...
```
However using **case 2**: `set_property(TARGET lib2 PROPERTY INTERFACE_LINK_LIBRARIES_DIRECT lib1)`, and comment case 1 of course, then I get:
```
link.exe ... /WHOLEARCHIVE:Debug\lib1.lib /WHOLEARCHIVE:Debug\lib2.lib ...
```
Now `lib1.lib` also gets `WHOLEARCHIVE`-d, even though it’s not specified anywhere as such.
A reply from the discussion indicates that this is a bug.https://gitlab.kitware.com/cmake/cmake/-/issues/25415CMake's copy command does not follow symlinks on macOS2023-11-15T04:45:09-05:00Tommy SmithCMake's copy command does not follow symlinks on macOS<!--
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/
-->
# Summary
According to the documentation, CMake states that it does follow symlinks, but it does not on macOS.
# Steps to reproduce
```bash
touch theFile
ln -s theFile theSymlink
cmake -E copy theSymlink theSymlinkCopy
```
# Expected behavior
`theSymlinkCopy` is a copy of `theFile`
# Observed behavior
`theSymlinkCopy` is a copy of `theSymlink`.
# System information
* macOS Ventura 13.0
* CMake 3.27.7https://gitlab.kitware.com/cmake/cmake/-/issues/25414macOS PowerPC and 10.5 x86: Regression: CMake 3.28 fails at configure with so...2024-03-26T09:06:32-04:00Sergey FedorovmacOS PowerPC and 10.5 x86: Regression: CMake 3.28 fails at configure with some ports conditional on env PATH: `Can't fork a new process to execute (Resource temporarily unavailable)`UPD 2024.01.08. It seems that the problem is caused by environment variables during configure stage: specifically, if the PATH has `/opt/local/sbin` **or even `/opt/local/abcd`** (pointing to non-existing folder) prior to system director...UPD 2024.01.08. It seems that the problem is caused by environment variables during configure stage: specifically, if the PATH has `/opt/local/sbin` **or even `/opt/local/abcd`** (pointing to non-existing folder) prior to system directories, CMake fails to work correctly. If the PATH does not have `/opt/local/sbin` or it is placed after system directories, CMake works correctly.
Notice, having `/opt/local/bin` in front works perfectly fine.
Contents of `/opt/local/sbin` is inconsequential: even if it is empty, the error persists, conditional on the PATH being set as described.
Outcomes so far are reproducible locally with no deviations, and do not depend on Macports build system (i.e., running CMake manually succeeds or fails depending on the PATH).
See below for details and logs.
_______________________________________________
Could someone please help with addressing this?
Something has broken down in 3.28.x branch, since this error did not occur with any of the earlier versions (I have 3.24 and 3.27 installed, both work fine, everything else being identical).
The problem shows up only with a few select ports: so far, `c-ares` and `libical`. AFAICT, however, it is clearly a CMake issue, since earlier versions build named ports with no problem.
The errors happen at configure stage, and look like this:
```
-- Looking for include file assert.h
-- Looking for include file assert.h - not found
-- Looking for include file errno.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_c4da1/fast
-- Looking for include file errno.h - not found
-- Looking for include file fcntl.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_c671c/fast
-- Looking for include file fcntl.h - not found
-- Looking for include file inttypes.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_328ec/fast
-- Looking for include file inttypes.h - not found
-- Looking for include file limits.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_c3809/fast
-- Looking for include file limits.h - not found
-- Looking for include file malloc.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_8370c/fast
-- Looking for include file malloc.h - not found
-- Looking for include file memory.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_8a69d/fast
-- Looking for include file memory.h - not found
-- Looking for include file netdb.h
-- Looking for include file netdb.h - not found
-- Looking for include file netinet/in.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_1960f/fast
-- Looking for include file netinet/in.h - not found
-- Looking for include file net/if.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_d2bb0/fast
-- Looking for include file net/if.h - not found
-- Looking for include file signal.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_9bfbd/fast
-- Looking for include file signal.h - not found
-- Looking for include file socket.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_d127a/fast
-- Looking for include file socket.h - not found
-- Looking for include file stdbool.h
CMake Error: Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_57d80/fast
-- Looking for include file stdbool.h - not found
```
CMake log has the following:
```
kind: "try_compile-v1"
backtrace:
- "/opt/local/share/cmake-3.28/Modules/CheckIncludeFiles.cmake:132 (try_compile)"
- "CMakeLists.txt:195 (CHECK_INCLUDE_FILES)"
checks:
- "Looking for include file assert.h"
directories:
source: "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/build/CMakeFiles/CMakeScratch/TryCompile-4WB5tV"
binary: "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/build/CMakeFiles/CMakeScratch/TryCompile-4WB5tV"
cmakeVariables:
CMAKE_C_FLAGS: "-pipe -Os -DNDEBUG -I/opt/local/include -Wall -Wextra -Wcast-align -Wconversion -Wdeclaration-after-statement -Wfloat-equal -Wformat-security -Winit-self -Wmissing-braces -Wmissing-declarations -Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-overflow -Wstrict-prototypes -Wundef -Wunused -Wvariadic-macros -Wwrite-strings -Werror=implicit-int -Werror=implicit-function-declaration -Qunused-arguments"
CMAKE_EXE_LINKER_FLAGS: "-L/opt/local/lib -Wl,-headerpad_max_install_names"
CMAKE_MODULE_PATH: "/opt/local/share/cmake/Modules;/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/c-ares-1.21.0/cmake/"
CMAKE_OSX_ARCHITECTURES: "ppc"
CMAKE_OSX_DEPLOYMENT_TARGET: "10.6"
CMAKE_OSX_SYSROOT: "/"
CMAKE_WARN_DEPRECATED: "FALSE"
buildResult:
variable: "HAVE_ASSERT_H"
cached: true
stdout: |
Change Dir: '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/build/CMakeFiles/CMakeScratch/TryCompile-4WB5tV'
Run Build Command(s): /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_73ded/fast
/usr/bin/make -f CMakeFiles/cmTC_73ded.dir/build.make CMakeFiles/cmTC_73ded.dir/build
make: posix_spawn: /usr/bin/make: Resource temporarily unavailable
exitCode: 2
-
kind: "try_compile-v1"
backtrace:
- "/opt/local/share/cmake-3.28/Modules/CheckIncludeFiles.cmake:132 (try_compile)"
- "CMakeLists.txt:196 (CHECK_INCLUDE_FILES)"
checks:
- "Looking for include file errno.h"
directories:
source: "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/build/CMakeFiles/CMakeScratch/TryCompile-A8w3xO"
binary: "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/build/CMakeFiles/CMakeScratch/TryCompile-A8w3xO"
cmakeVariables:
CMAKE_C_FLAGS: "-pipe -Os -DNDEBUG -I/opt/local/include -Wall -Wextra -Wcast-align -Wconversion -Wdeclaration-after-statement -Wfloat-equal -Wformat-security -Winit-self -Wmissing-braces -Wmissing-declarations -Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-overflow -Wstrict-prototypes -Wundef -Wunused -Wvariadic-macros -Wwrite-strings -Werror=implicit-int -Werror=implicit-function-declaration -Qunused-arguments"
CMAKE_EXE_LINKER_FLAGS: "-L/opt/local/lib -Wl,-headerpad_max_install_names"
CMAKE_MODULE_PATH: "/opt/local/share/cmake/Modules;/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/c-ares-1.21.0/cmake/"
CMAKE_OSX_ARCHITECTURES: "ppc"
CMAKE_OSX_DEPLOYMENT_TARGET: "10.6"
CMAKE_OSX_SYSROOT: "/"
CMAKE_WARN_DEPRECATED: "FALSE"
buildResult:
variable: "HAVE_ERRNO_H"
cached: true
stdout: |
Change Dir: '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_c-ares/c-ares/work/build/CMakeFiles/CMakeScratch/TryCompile-A8w3xO'
Run Build Command(s): /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_68d2c/fast
resource temporarily unavailable
Generator: execution of make failed. Make command was: /opt/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_68d2c/fast
exitCode: 1
-
```
This is not a compiler problem (happened both with up-to-date `gcc-13` and old Apple `gcc-4.2`), since the only scenario to get the breakage is with CMake 3.28. Same compilers, same versions, everything identical, but with CMake 3.27 or earlier – everything works fine.
P. S. Before someone says that old macOS is not supported – this is not a request for some feature or specific support, but merely to fix a regression. I do not know if it currently shows up on other platforms, but potentially it can; and it is desirable to have a healthy code. Whether supported officially or not, CMake has been working on every macOS from 10.5+ very reliably – until 3.28.3.29.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/254132 issues with Windows SDK version selection2023-11-20T09:09:28-05:00Mark Callow2 issues with Windows SDK version selection# Issue 1
According to the documentation for [WINDOWS_TARGET_PLATFORM_VERSION](https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html) if [CMP0149](https://cmake.org/cmake/help/latest/policy/CMP0149.h...# Issue 1
According to the documentation for [WINDOWS_TARGET_PLATFORM_VERSION](https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html) if [CMP0149](https://cmake.org/cmake/help/latest/policy/CMP0149.html#policy:CMP0149) is set CMake will choose the latest SDK available, provided [CMAKE_GENERATOR_PLATFORM](https://cmake.org/cmake/help/latest/variable/CMAKE_GENERATOR_PLATFORM.html#variable:CMAKE_GENERATOR_PLATFORM "CMAKE_GENERATOR_PLATFORM") does not have a `version=` field. This is not working in my GitHub Actions CI builds using Windows. For example the windows-latest image has these SDKs installed:
* 10.0.17763.0
* 10.0.19041.0
* 10.0.20348.0
* 10.0.22000.0
* 10.0.22621.0
CMake always selects 20348 even though CMP0149 is set. I printed ${CMAKE_GENERATOR_PLATFORM}. The value I see is "arm64" with no `version=` as you can see in the following so no overriding should be happening.
`CMAKE_GENERATOR_PLATFORM="arm64" ; CMAKE_SYSTEM_VERSION="10.0.20348" ; CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION="10.0.20348.0"`
This may be a GitHub Actions rather than a CMake problem. I opened [issue 8781](https://github.com/actions/runner-images/issues/8781) in the runner-images repo in case it is.
CMake _is_ picking the latest on my local Windows machine. v3.26 was also doing that.
# Issue 2
According to [WINDOWS_TARGET_PLATFORM_VERSION](https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html) if CMP0149 is "enabled" the `WindowsSDKVersion` environment variable can be set to an available SDK version which will be selected. This is not working either on Actions CI or on my local machine. Note that the documentation for [CMP0149](https://cmake.org/cmake/help/latest/policy/CMP0149.html#policy:CMP0149) does not mention this environment variable. Note also the differing language: "enabled" in the former doc vs "new" and "old" used in CMP0149. I am assuming "enabled" == "new".
On my local Windows 11 machine I use the CMake GUI. I used it to add `WindowsSDKVersion` to the environment with the value `10.0.22000.0`, deleted the cache and ran configure and generate. CMake still selects `10.0.22621.0` which is the latest on my machine.
On the CI machine I set the variable in the workflow's environment with the value `10.0.22621.0` because there I am trying to work around issue no. 1 and get the latest SDK. Configure is done with CMake on the command line with a new build directory being created. The variable setting has no effect, 20348 is still selected.
## Local machine config
CMake: v3.27.7, Windows 11, Generating for Visual Studio 2022 Community Edition.
## CI machine config
CMake v3.27.7, Windows Server 2022, Generating for Visual Studio 2022 Enterprise Edition.3.27.9https://gitlab.kitware.com/cmake/cmake/-/issues/25412$<AND:...> does not short-circuit2023-11-14T09:07:15-05:00Craig Scott$<AND:...> does not short-circuitStarting with CMake 3.28, the `$<AND:...>` generator expression is meant to short-circuit. Once it knows the result after processing some items (i.e. once it encounters an item that evaluates to 0), it should skip evaluating the rest of ...Starting with CMake 3.28, the `$<AND:...>` generator expression is meant to short-circuit. Once it knows the result after processing some items (i.e. once it encounters an item that evaluates to 0), it should skip evaluating the rest of the items. The following example demonstrates that this isn't being done, at least not for the case shown:
```
add_executable(genex main.cpp
$<$<AND:1,0,$<NOT_A_VALID_GENEX>>:>
)
```
Instead of skipping the `$<NOT_A_VALID_GENEX>`, it still gets processed, even though the preceding item is 0, and therefore all later items should be skipped. The error generated with CMake 3.28.0-rc4 is the following (note the extra spurious error message at the end about no sources, which is also wrong):
```
CMake Error at CMakeLists.txt:6 (add_executable):
Error evaluating generator expression:
$<NOT_A_VALID_GENEX>
Expression did not evaluate to a known generator expression
CMake Error at CMakeLists.txt:6 (add_executable):
Error evaluating generator expression:
$<NOT_A_VALID_GENEX>
Expression did not evaluate to a known generator expression
CMake Error at CMakeLists.txt:6 (add_executable):
Error evaluating generator expression:
$<NOT_A_VALID_GENEX>
Expression did not evaluate to a known generator expression
CMake Error at CMakeLists.txt:6 (add_executable):
No SOURCES given to target: genex
```
The `$<IF:...>`, `$<OR:...>` and `$<0:...>` generator expressions do not have this weakness, it only seems to be `$<AND:...>` which doesn't short-circuit in the expected way.3.28.0Martin DuffyMartin Duffyhttps://gitlab.kitware.com/cmake/cmake/-/issues/25408CMake does not provide the run/test launcher in the file api2024-02-28T17:57:38-05:00rhabackerCMake does not provide the run/test launcher in the file apiCMake offers the file API for integration in IDEs. In order to be able to execute cross-compiled applications there directly, for example, the start or test starter specified with CMAKE_CROSSCOMPILING_EMULATOR is currently missing. See h...CMake offers the file API for integration in IDEs. In order to be able to execute cross-compiled applications there directly, for example, the start or test starter specified with CMAKE_CROSSCOMPILING_EMULATOR is currently missing. See https://bugreports.qt.io/browse/QTCREATORBUG-29880 for a corresponding request for Qt Creator.
The idea is to extend the ["target"](https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html#codemodel-version-2-target-object) object of the code model of the cmake file api with a corresponding attribute that can be queried by the IDEs.https://gitlab.kitware.com/cmake/cmake/-/issues/25406OpenACC + CUDA + CMake2023-11-13T08:58:07-05:00Mihaly SisakOpenACC + CUDA + CMake[CMakeLists.txt](/uploads/a4b69d8e798f3db617a753aa2f47d93a/CMakeLists.txt)
[Makefile.txt](/uploads/43be424ee524352e38f9d45a8e6715ea/Makefile.txt)
[openacc_c_main.c.txt](/uploads/8ffa5f21714733624fee04199d6480bf/openacc_c_main.c.txt)
[...[CMakeLists.txt](/uploads/a4b69d8e798f3db617a753aa2f47d93a/CMakeLists.txt)
[Makefile.txt](/uploads/43be424ee524352e38f9d45a8e6715ea/Makefile.txt)
[openacc_c_main.c.txt](/uploads/8ffa5f21714733624fee04199d6480bf/openacc_c_main.c.txt)
[saxpy_cuda.cu.txt](/uploads/928e3f619e39125a5f8b554026271473/saxpy_cuda.cu.txt)
We would like to use C with OpenACC pragmas and CUDA kernels in some hotspots.
With `make` everything is fine. However we would like to build with CMake.
We started with this repo:
https://github.com/jefflarkin/openacc-interoperability
We needed to remove `<LINK_LIBRARIES>` from `CMAKE_CUDA_LINK_EXECUTABLE` because it tries to link cuda libraries in the `nvc++` link step, causing errors at runtime. This way however we can not link external libraries, which we want to do.
The CMake line with added `LINK_LIBRARIES`:
```cmake
set(CMAKE_CUDA_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
```
It would be preferable to have an elegant solution work, without the cmake list mangling for example. Is it possible?https://gitlab.kitware.com/cmake/cmake/-/issues/25405UseSWIG swig_add_library -dllmodule parameter incorrect for csharp2023-11-17T08:20:27-05:00ChristopheUseSWIG swig_add_library -dllmodule parameter incorrect for csharpHi,
this is kind of a follow-up to https://gitlab.kitware.com/cmake/cmake/-/issues/21542
I only recently noticed there is an issue with the `-dllimport` flag generated by `swig_add_library` for csharp (I noticed since I generated the .c...Hi,
this is kind of a follow-up to https://gitlab.kitware.com/cmake/cmake/-/issues/21542
I only recently noticed there is an issue with the `-dllimport` flag generated by `swig_add_library` for csharp (I noticed since I generated the .cs files from macOS and not from windows, so I noticed a difference in the generated PINVOKE files).
As I described in https://gitlab.kitware.com/cmake/cmake/-/issues/21542 `global::System.Runtime.InteropServices.DllImport` expects the library name without prefix and postfix.
See https://www.mono-project.com/docs/advanced/pinvoke or just this part of the article:
![image](/uploads/aa9bc36fb6b27c3eb80daa6ecffb63cb/image.png)
Currently the automatically generated `-dllimport` parameter adds `$<TARGET_FILE_PREFIX:${target_name}>` while it shouldn't according to `global::System.Runtime.InteropServices.DllImport` documentation.https://gitlab.kitware.com/cmake/cmake/-/issues/25404CPackDeb: file utility is not available. CPACK_DEBIAN_PACKAGE_SHLIBDEPS an...2023-11-09T20:36:15-05:00paulbourelly999CPackDeb: file utility is not available. CPACK_DEBIAN_PACKAGE_SHLIBDEPS and CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS options are not availableWhen installing CMake via the github release artifact as follows:
```plaintext
CMAKE_VERSION="3.27.7"
echo "Installing CMake ${CMAKE_VERSION}"
wget https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/cmake-${CMAKE_VERS...When installing CMake via the github release artifact as follows:
```plaintext
CMAKE_VERSION="3.27.7"
echo "Installing CMake ${CMAKE_VERSION}"
wget https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/cmake-${CMAKE_VERSION}-linux-x86_64.sh
wget https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/cmake-${CMAKE_VERSION}-linux-x86_64.tar.gz
chmod u+x cmake-${CMAKE_VERSION}-linux-x86_64.sh
./cmake-${CMAKE_VERSION}-linux-x86_64.sh --skip-license --exclude-subdir --prefix=/usr/local
rm cmake-${CMAKE_VERSION}-linux-x86_64.sh
rm cmake-${CMAKE_VERSION}-linux-x86_64.tar.gz
```
and then attempting to use cpack to build a library into a debian package I get the following error:
```plaintext
cpack -G DEB
CPack: Create package using DEB
CPack: Install projects
CPack: - Run preinstall target for: carma-clock
CPack: - Install project: carma-clock []
CPack: Create package
CMake Error at /usr/local/share/cmake-3.22/Modules/Internal/CPack/CPackDeb.cmake:165 (message):
CPackDeb: file utility is not available. CPACK_DEBIAN_PACKAGE_SHLIBDEPS
and CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS options are not available.
Call Stack (most recent call first):
/usr/local/share/cmake-3.22/Modules/Internal/CPack/CPackDeb.cmake:793 (cpack_deb_prepare_package_vars)
CPack Error: Error while execution CPackDeb.cmake
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: carma-clock-1
Error: Process completed with exit code 1.
```
The build process is as follows
```plaintext
cmake -Bbuild -DCMAKE_CXX_FLAGS= -DCMAKE_BUILD_TYPE=Release -DPACKAGE_VERSION_SUFFIX=20231110.git38.d03b666
cd build
cmake --build .
cpack -G DEB
```
Any help is greatly appreciated. Seems to work fine for CMAKE installed via apt. Not sure why there would be any difference. For more build output see github action CI output https://github.com/usdot-fhwa-stol/carma-time-lib/actions/runs/6818897376/job/18545340990https://gitlab.kitware.com/cmake/cmake/-/issues/25403Incorrect LINK_LIBRARIES queried when using CMP00792023-11-10T14:11:05-05:00Maciej DziubanIncorrect LINK_LIBRARIES queried when using CMP0079When trying to dump value of `LINK_LIBRARIES` via `file(GENERATE)` for my project, I noticed very weird output. I narrowed it down to a minimal example. It seems the problem appears when any link libraries are added in a different direct...When trying to dump value of `LINK_LIBRARIES` via `file(GENERATE)` for my project, I noticed very weird output. I narrowed it down to a minimal example. It seems the problem appears when any link libraries are added in a different directory than `add_library` call. This is regulated with CMP0079.
When I add a dependency named `SubLib` to my library, the output is as below. The hex value, probably an address, will be different each run.
```
::@(000001F6B709E8D0);SubLib;::@
```
When `target_link_libraries` call is moved to root `CMakeLists.txt`, the output is as expected.
```
SubLib
```
Minimal reproducible example is provided here: https://github.com/PlaygroundMD/CmakeGenexBughttps://gitlab.kitware.com/cmake/cmake/-/issues/25402target_sources() BASE_DIRS for CXX_MODULES have no effect2023-11-09T12:06:20-05:00sthlm58target_sources() BASE_DIRS for CXX_MODULES have no effectWhen calling `target_sources()` and specifying `BASE_DIRS` e.g.
```plaintext
target_sources(foo
PUBLIC
FILE_SET CXX_MODULES
BASE_DIRS
bar
FILES
foo.cxx
)
```
I'm expecting that the file `foo.cxx` will be s...When calling `target_sources()` and specifying `BASE_DIRS` e.g.
```plaintext
target_sources(foo
PUBLIC
FILE_SET CXX_MODULES
BASE_DIRS
bar
FILES
foo.cxx
)
```
I'm expecting that the file `foo.cxx` will be searched in `${CMAKE_CURRENT_SOURCE_DIR}/bar/foo.cxx`
This is however not the case (tested with **CMake 3.28-rc4**) and fails the configuration step:
```Log
[cmake] CMake Error at CMakeLists.txt:11 (target_sources):
[cmake] File:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/foo.cxx
[cmake]
[cmake] must be in one of the file set's base directories:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/bar
[cmake]
[cmake]
```
I'm using the modified CMake example called `simple` and putting my foo.cxx inside a subdirectory:
![image.png](/uploads/9b276ce1e736ef9108cd38da5b2e06f7/image.png)
Error I'm receiving:
```cmake
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.exe" --no-warn-unused-cli -DCMAKE_INSTALL_PREFIX:STRING=c:/Users/user/dev/cpp/modules-hello-world-install/Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -SC:/Users/user/dev/cpp/modules-hello-world -Bc:/Users/user/dev/cpp/modules-hello-world-build/Debug -G "Visual Studio 17 2022" -T host=x64 -A x64
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22631.
[cmake] -- The CXX compiler identification is MSVC 19.37.32825.0
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] -- Configuring done (4.6s)
[cmake] CMake Error at CMakeLists.txt:11 (target_sources):
[cmake] File:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/foo.cxx
[cmake]
[cmake] must be in one of the file set's base directories:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/bar
[cmake]
[cmake]
[cmake] CMake Error at CMakeLists.txt:11 (target_sources):
[cmake] File:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/foo.cxx
[cmake]
[cmake] must be in one of the file set's base directories:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/bar
[cmake]
[cmake]
[cmake] CMake Error at CMakeLists.txt:11 (target_sources):
[cmake] File:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/foo.cxx
[cmake]
[cmake] must be in one of the file set's base directories:
[cmake]
[cmake] C:/Users/user/dev/cpp/modules-hello-world/bar
[cmake]
[cmake]
[cmake] CMake Error at CMakeLists.txt:8 (add_library):
[cmake] No SOURCES given to target: foo
[cmake]
[cmake]
[cmake] CMake Generate step failed. Build files cannot be regenerated correctly.
[proc] The command: "C:\Program Files\CMake\bin\cmake.exe" --no-warn-unused-cli -DCMAKE_INSTALL_PREFIX:STRING=c:/Users/user/dev/cpp/modules-hello-world-install/Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -SC:/Users/user/dev/cpp/modules-hello-world -Bc:/Users/user/dev/cpp/modules-hello-world-build/Debug -G "Visual Studio 17 2022" -T host=x64 -A x64 exited with code: 1
[visual-studio] Patch Windows SDK path from C:\Program Files (x86)\Windows Kits\10\bin\x64 to C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64 for C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsall.bat
```https://gitlab.kitware.com/cmake/cmake/-/issues/25400Multi-config generators fail to link per-config OBJECT library using a genex2023-11-14T09:09:19-05:00Dennis PatollaMulti-config generators fail to link per-config OBJECT library using a genexEDIT: A simplified example appears in https://gitlab.kitware.com/cmake/cmake/-/issues/25400#note_1443987
---
Hi, I'm facing an oddity when using an object library as part of a generator expression in target_link_libraries.
Below is the...EDIT: A simplified example appears in https://gitlab.kitware.com/cmake/cmake/-/issues/25400#note_1443987
---
Hi, I'm facing an oddity when using an object library as part of a generator expression in target_link_libraries.
Below is the root CMakeLists.txt of an example I built.
```cmake
cmake_minimum_required(VERSION 3.24)
project(cmake_bug VERSION 1.0
DESCRIPTION "Test project for possible cmake bug"
LANGUAGES C CXX
)
add_executable(${PROJECT_NAME}
test_runner_test_sample.c
)
target_link_libraries(${PROJECT_NAME}
PUBLIC
c_test_lib
$<$<CONFIG:Release>:obj_lib>
)
add_subdirectory(unity)
add_subdirectory(c_static_lib)
add_subdirectory(c_test_lib)
add_subdirectory(obj_lib)
```
`c_test_lib` is configured as a regular library, whereas `obj_lib` is configured as an OBJECT library.
My expaction would be, that - for a Release configuration at least - `obj_lib` is used when building the executable. Curiously though it isn't, even though the source file of `obj_lib` is **still** getting compiled. This results in undefined references.
If `obj_lib` is linked **without** the generator expression, this works as expected.
Also switching the approach from target_link_libraries to using `$<$<CONFIG:Release>:$<TARGET_OBJECTS:obj_lib>>` in the `add_executable` call works as expected and can be used as a workaround.
This behaviour has been tested using CMake 3.24.2, 3.27.7 and 3.28RC4.
Am I missing something in the generator expression, or why is this oddly misbehaving? Adding the same generator expression for a regular lib like `$<$<CONFIG:Release>:c_test_lib>` works like that too, so I'm not sure what needs to be changed.3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25398FindCUDAToolkit doesn't find CUDA::cuFile (case issue with library libcufile....2023-11-09T09:25:32-05:00Marcus D. HanwellFindCUDAToolkit doesn't find CUDA::cuFile (case issue with library libcufile.so from conda-forge/Arch Linux)I was debugging an issue with `FindCUDAToolkit.cmake` provided by CMake not finding `libcufile.so`. After debugging it looks like the case has changed or is inconsistently used. I am looking at the cuda package installed on Arch Linux th...I was debugging an issue with `FindCUDAToolkit.cmake` provided by CMake not finding `libcufile.so`. After debugging it looks like the case has changed or is inconsistently used. I am looking at the cuda package installed on Arch Linux that provides `libcufile*.so.*` in `lib`, and also the conda-forge package that provides for example `libcufile.so` and all alternatives such as `libcufile_static.a`, `libcufile_rdma.so`, `libcufile_rdma_static.a`.
A simple hack creating some symlinks enables me to use it in the short-term, or creating a local copy of the file in my project with updated case. I haven't investigated the case used in other places but the current file searches for `libcuFile.so` and alternatives marking them as not found if the capitalized 'F' is not used.3.28.0Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/25394"Unix Makefiles" generator available in Windows2023-11-08T10:24:58-05:00Kyle Edwards"Unix Makefiles" generator available in WindowsI'm not sure if this is intentional or not, but the "Unix Makefiles" generator is available on Windows. Is there any scenario where this actually works? If not, is it available in Windows by mistake? Should it be removed?I'm not sure if this is intentional or not, but the "Unix Makefiles" generator is available on Windows. Is there any scenario where this actually works? If not, is it available in Windows by mistake? Should it be removed?https://gitlab.kitware.com/cmake/cmake/-/issues/25389Extend `CMAKE_SIZEOF_VOID_P` to work when only a C++ compiler is provided2023-11-06T11:21:38-05:00Chris ThrasherExtend `CMAKE_SIZEOF_VOID_P` to work when only a C++ compiler is providedhttps://github.com/SFML/SFML/actions/runs/6748785142/job/18347866816
Above is a link to a CI pipeline for a C++ project which only specifies `CXX` as a language and thus only provides a C++ compiler during configuration. Use of `CMAKE_S...https://github.com/SFML/SFML/actions/runs/6748785142/job/18347866816
Above is a link to a CI pipeline for a C++ project which only specifies `CXX` as a language and thus only provides a C++ compiler during configuration. Use of `CMAKE_SIZEOF_VOID_P` fails because it's trying to compile a .c file for which it cannot find a suitable compiler. Because of this limitation I have to provide a C compiler even though no C code is compiled in this project.
As far as I can tell there is no reason the size of `void*` couldn't be checked with a C++ compiler. I'd appreciate it if `CMAKE_SIZEOF_VOID_P` was extended to work in projects where `CXX` is the only enabled language.https://gitlab.kitware.com/cmake/cmake/-/issues/25388cmake fails to build as C++23 (error: invalid application of 'sizeof' to an i...2023-11-08T10:32:31-05:00Sean McBridecmake fails to build as C++23 (error: invalid application of 'sizeof' to an incomplete type)With clang 17.0.2 on macOS, building with `std=c++20` works, but with `std=c++23` I get:
```
/usr/local/latestclang/bin/../include/c++/v1/__memory/unique_ptr.h:66:19: error: invalid application of 'sizeof' to an incomplete type 'cmGloba...With clang 17.0.2 on macOS, building with `std=c++20` works, but with `std=c++23` I get:
```
/usr/local/latestclang/bin/../include/c++/v1/__memory/unique_ptr.h:66:19: error: invalid application of 'sizeof' to an incomplete type 'cmGlobalGenerator'
66 | static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
| ^~~~~~~~~~~
/usr/local/latestclang/bin/../include/c++/v1/__memory/unique_ptr.h:300:7: note: in instantiation of member function 'std::default_delete<cmGlobalGenerator>::operator()' requested here
300 | __ptr_.second()(__tmp);
| ^
/usr/local/latestclang/bin/../include/c++/v1/__memory/unique_ptr.h:266:75: note: in instantiation of member function 'std::unique_ptr<cmGlobalGenerator>::reset' requested here
266 | _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
| ^
/Users/builder/external/CMake/Source/cmGlobalGeneratorFactory.h:62:14: note: in instantiation of member function 'std::unique_ptr<cmGlobalGenerator>::~unique_ptr' requested here
62 | return std::unique_ptr<cmGlobalGenerator>();
| ^
/Users/builder/external/CMake/Source/cmTarget.h:27:7: note: forward declaration of 'cmGlobalGenerator'
27 | class cmGlobalGenerator;
| ^
```3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25383Windows cmake 3.28-rc3 no longer passes stdin through with -E env2024-01-23T12:50:31-05:00Edward LamWindows cmake 3.28-rc3 no longer passes stdin through with -E envIn the latest release candidate, the Windows cmake -E env no longer passes through stdin.
```
D:\cmake-3.28.0-rc3-windows-x86_64>echo ayy lmao| bin\cmake.exe -E env ayy=lmao cmd /S /C ^"cat -^"
D:\cmake-3.28.0-rc3-windows-x86_64>echo ay...In the latest release candidate, the Windows cmake -E env no longer passes through stdin.
```
D:\cmake-3.28.0-rc3-windows-x86_64>echo ayy lmao| bin\cmake.exe -E env ayy=lmao cmd /S /C ^"cat -^"
D:\cmake-3.28.0-rc3-windows-x86_64>echo ayy lmao| cmake -E env ayy=lmao cmd /S /C ^"cat -^"
ayy lmao
```
Second command is cmake 3.27 installed into the path. The "cat" is from having git in the path but you can imagine what it does.
Original Cpplang Slack #cmake link: https://cpplang.slack.com/archives/C5Y2GDECX/p16989308210135993.28.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/25382CUDA/NVCC: CMakeCUDACompilerId.cu fails to compile with nvcc 12.3 and gcc 132024-01-20T20:18:05-05:00Pierre TalbotCUDA/NVCC: CMakeCUDACompilerId.cu fails to compile with nvcc 12.3 and gcc 13Hi,
I've updated nvcc and CMake to version V12.3.52 and 3.27.7 respectively and my project doesn't build anymore due to `CMakeCUDACompilerId.cu` failing to compile.
Is it a bug or an issue on my side? FYI, the project is https://github...Hi,
I've updated nvcc and CMake to version V12.3.52 and 3.27.7 respectively and my project doesn't build anymore due to `CMakeCUDACompilerId.cu` failing to compile.
Is it a bug or an issue on my side? FYI, the project is https://github.com/ptal/turbo
The error message is below.
Thanks!
```plaintext
CMake Error at /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:753 (message):
Compiling the CUDA compiler identification source file
"CMakeCUDACompilerId.cu" failed.
Compiler: /opt/cuda/bin/nvcc
Build flags:
Id flags: --keep;--keep-dir;tmp -v
The output was:
2
#$ _NVVM_BRANCH_=nvvm
#$ _SPACE_=
#$ _CUDART_=cudart
#$ _HERE_=/opt/cuda/bin
#$ _THERE_=/opt/cuda/bin
#$ _TARGET_SIZE_=
#$ _TARGET_DIR_=
#$ _TARGET_DIR_=targets/x86_64-linux
#$ TOP=/opt/cuda/bin/..
#$ NVVMIR_LIBRARY_DIR=/opt/cuda/bin/../nvvm/libdevice
#$ LD_LIBRARY_PATH=/opt/cuda/bin/../lib:
#$
PATH=/opt/cuda/bin/../nvvm/bin:/opt/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/cuda/bin:/opt/cuda/nsight_compute:/opt/cuda/nsight_systems/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/ptalbot/.rvm/bin
#$ INCLUDES="-I/opt/cuda/bin/../targets/x86_64-linux/include"
#$ LIBRARIES= "-L/opt/cuda/bin/../targets/x86_64-linux/lib/stubs"
"-L/opt/cuda/bin/../targets/x86_64-linux/lib"
#$ CUDAFE_FLAGS=
#$ PTXAS_FLAGS=
#$ rm tmp/a_dlink.reg.c
#$ gcc -D__CUDA_ARCH_LIST__=520 -E -x c++ -D__CUDACC__ -D__NVCC__
"-I/opt/cuda/bin/../targets/x86_64-linux/include" -D__CUDACC_VER_MAJOR__=12
-D__CUDACC_VER_MINOR__=3 -D__CUDACC_VER_BUILD__=52
-D__CUDA_API_VER_MAJOR__=12 -D__CUDA_API_VER_MINOR__=3
-D__NVCC_DIAG_PRAGMA_SUPPORT__=1 -include "cuda_runtime.h" -m64
"CMakeCUDACompilerId.cu" -o "tmp/CMakeCUDACompilerId.cpp4.ii"
#$ cudafe++ --c++17 --gnu_version=130201 --display_error_number
--orig_src_file_name "CMakeCUDACompilerId.cu" --orig_src_path_name
"/home/ptalbot/repositories/lattice-land/turbo/build/gpu-release-local/CMakeFiles/3.27.7/CompilerIdCUDA/CMakeCUDACompilerId.cu"
--allow_managed --m64 --parse_templates --gen_c_file_name
"tmp/CMakeCUDACompilerId.cudafe1.cpp" --stub_file_name
"CMakeCUDACompilerId.cudafe1.stub.c" --gen_module_id_file
--module_id_file_name "tmp/CMakeCUDACompilerId.module_id"
"tmp/CMakeCUDACompilerId.cpp4.ii"
/usr/include/bits/floatn.h(86): error: invalid combination of type
specifiers
typedef __float128 _Float128;
^
/usr/include/bits/floatn-common.h(214): error: invalid combination of type
specifiers
typedef float _Float32;
^
/usr/include/bits/floatn-common.h(251): error: invalid combination of type
specifiers
typedef double _Float64;
^
/usr/include/bits/floatn-common.h(268): error: invalid combination of type
specifiers
typedef double _Float32x;
^
/usr/include/bits/floatn-common.h(285): error: invalid combination of type
specifiers
typedef long double _Float64x;
^
5 errors detected in the compilation of "CMakeCUDACompilerId.cu".
# --error 0x2 --
Call Stack (most recent call first):
/usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:8 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
/usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:53 (__determine_compiler_id_test)
/usr/share/cmake/Modules/CMakeDetermineCUDACompiler.cmake:307 (CMAKE_DETERMINE_COMPILER_ID)
CMakeLists.txt:9 (project)
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
CMake Error at /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:753 (message):
Compiling the CUDA compiler identification source file
"CMakeCUDACompilerId.cu" failed.
Compiler: /opt/cuda/bin/nvcc
Build flags:
Id flags: --keep;--keep-dir;tmp -v
The output was:
2
#$ _NVVM_BRANCH_=nvvm
#$ _SPACE_=
#$ _CUDART_=cudart
#$ _HERE_=/opt/cuda/bin
#$ _THERE_=/opt/cuda/bin
#$ _TARGET_SIZE_=
#$ _TARGET_DIR_=
#$ _TARGET_DIR_=targets/x86_64-linux
#$ TOP=/opt/cuda/bin/..
#$ NVVMIR_LIBRARY_DIR=/opt/cuda/bin/../nvvm/libdevice
#$ LD_LIBRARY_PATH=/opt/cuda/bin/../lib:
#$
PATH=/opt/cuda/bin/../nvvm/bin:/opt/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/cuda/bin:/opt/cuda/nsight_compute:/opt/cuda/nsight_systems/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/ptalbot/.rvm/bin
#$ INCLUDES="-I/opt/cuda/bin/../targets/x86_64-linux/include"
#$ LIBRARIES= "-L/opt/cuda/bin/../targets/x86_64-linux/lib/stubs"
"-L/opt/cuda/bin/../targets/x86_64-linux/lib"
#$ CUDAFE_FLAGS=
#$ PTXAS_FLAGS=
#$ rm tmp/a_dlink.reg.c
#$ gcc -D__CUDA_ARCH_LIST__=520 -E -x c++ -D__CUDACC__ -D__NVCC__
"-I/opt/cuda/bin/../targets/x86_64-linux/include" -D__CUDACC_VER_MAJOR__=12
-D__CUDACC_VER_MINOR__=3 -D__CUDACC_VER_BUILD__=52
-D__CUDA_API_VER_MAJOR__=12 -D__CUDA_API_VER_MINOR__=3
-D__NVCC_DIAG_PRAGMA_SUPPORT__=1 -include "cuda_runtime.h" -m64
"CMakeCUDACompilerId.cu" -o "tmp/CMakeCUDACompilerId.cpp4.ii"
#$ cudafe++ --c++17 --gnu_version=130201 --display_error_number
--orig_src_file_name "CMakeCUDACompilerId.cu" --orig_src_path_name
"/home/ptalbot/repositories/lattice-land/turbo/build/gpu-release-local/CMakeFiles/3.27.7/CompilerIdCUDA/CMakeCUDACompilerId.cu"
--allow_managed --m64 --parse_templates --gen_c_file_name
"tmp/CMakeCUDACompilerId.cudafe1.cpp" --stub_file_name
"CMakeCUDACompilerId.cudafe1.stub.c" --gen_module_id_file
--module_id_file_name "tmp/CMakeCUDACompilerId.module_id"
"tmp/CMakeCUDACompilerId.cpp4.ii"
/usr/include/bits/floatn.h(86): error: invalid combination of type
specifiers
typedef __float128 _Float128;
^
/usr/include/bits/floatn-common.h(214): error: invalid combination of type
specifiers
typedef float _Float32;
^
/usr/include/bits/floatn-common.h(251): error: invalid combination of type
specifiers
typedef double _Float64;
^
/usr/include/bits/floatn-common.h(268): error: invalid combination of type
specifiers
typedef double _Float32x;
^
/usr/include/bits/floatn-common.h(285): error: invalid combination of type
specifiers
typedef long double _Float64x;
^
5 errors detected in the compilation of "CMakeCUDACompilerId.cu".
# --error 0x2 --
Call Stack (most recent call first):
/usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:8 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
/usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:53 (__determine_compiler_id_test)
/usr/share/cmake/Modules/CMakeDetermineCUDACompiler.cmake:307 (CMAKE_DETERMINE_COMPILER_ID)
CMakeLists.txt:9 (project)
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
```https://gitlab.kitware.com/cmake/cmake/-/issues/25381Allow building without `curl` and `nghttp2`2023-11-01T12:56:21-04:00Raul RangelAllow building without `curl` and `nghttp2`I'm trying to bootstrap a system from a very small set of packages. I would like the ability to build `cmake` without `curl` or `nghttp2`. The reason being that `cmake` DEPENDs on `nghttp2`, and `nghttp2` needs `cmake` to build. So I end...I'm trying to bootstrap a system from a very small set of packages. I would like the ability to build `cmake` without `curl` or `nghttp2`. The reason being that `cmake` DEPENDs on `nghttp2`, and `nghttp2` needs `cmake` to build. So I end up with a circular dependency. `curl` can also depend on `nghttp2`, so this can cause another circular dependency. For my use case I don't need `cmake` performing any network access.
I'm aware of the `-DCMAKE_USE_SYSTEM_LIBRARY_NGHTTP2=OFF` flag, but that just uses a bundled version. It breaks the dependency, but it makes auditing the version of nghttp2/curl for CVEs difficult because it's bundled in the binary.
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/25379Visual Studio Generator: Setting Unicode character-set is inconsistent2023-11-07T09:10:04-05:00Deniz BahadirVisual Studio Generator: Setting Unicode character-set is inconsistentI am using the _Visual Studio (2022) Generator_ and noticed that in the generated `*.vcxproj` files the tag `CharacterSet` has value `MultiByte`, although I wanted it to have `Unicode`.
I know that MSVC respects the macros `_UNICODE` a...I am using the _Visual Studio (2022) Generator_ and noticed that in the generated `*.vcxproj` files the tag `CharacterSet` has value `MultiByte`, although I wanted it to have `Unicode`.
I know that MSVC respects the macros `_UNICODE` and `UNICODE` and I was already setting these via `add_compile_definitions`:
```cmake
add_compile_definitions(_UNICODE=1 UNICODE=1)
```
By some googling, I found the following CMake issue: https://gitlab.kitware.com/cmake/cmake/-/issues/12189
From that I learned, that settings `_UNICODE` via `add_definitions` should result in the tag `CharacterSet` in the generated `*.vcxproj` files to contain the value `Unicode`.
And indeed, using `add_definitions(-D_UNICODE)` results in the generated `*.vcxproj` file to set Unicode as character-set.
However, using `add_compile_definitions(-D_UNICODE)` or `add_compile_definitions(_UNICODE=1)` does not have the same effect. Interestingly `add_compile_definitions(_UNICODE)` works again.
---
I would suggest to unify the behavior so that it does not matter if `_UNICODE` is set with or without value, with or without `-D` prefix and with `add_compile_definitions` or `add_definitions`.