CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-11-13T18:38:11-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25407Allow configuring installation path of object libraries2023-11-13T18:38:11-05:00alcroitoAllow configuring installation path of object librariesThe installation path of object library targets currently is not very configurable.
For the following project
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj)
set(obj_path ".some_hidden_folder/my_static_initializer.cpp")
fil...The installation path of object library targets currently is not very configurable.
For the following project
```cmake
cmake_minimum_required(VERSION 3.16)
project(proj)
set(obj_path ".some_hidden_folder/my_static_initializer.cpp")
file(WRITE "${obj_path}" "void foo() {}")
add_library(my_long_object_library_target_name OBJECT "${obj_path}")
install(TARGETS my_long_object_library_target_name DESTINATION lib)
```
configured with
`cmake .. -DCMAKE_INSTALL_PREFIX=$PWD/installed -DCMAKE_CONFIGURATION_TYPES=Release -G 'Ninja Multi-Config'`
the installed file path is
```
installed/lib/objects-Release/my_long_object_library_target_name/.some_hidden_folder/my_static_initializer.cpp.o
```
This leads to quite a long file path, which can cause issues on Windows due to path length restrictions.
There are a few things a project could tweak: like the target name and the cpp file name / source file path.
But in some cases due to project restrictions it is difficult to do: target names are public API and can't be changed, same for source file names.
the `objects-Release` can be considered entirely hardcoded (aside from using a differently named configuration, which is not feasible):
```cpp
std::string computeInstallObjectDir(cmGeneratorTarget* gt,
std::string const& config)
{
std::string objectDir = "objects";
if (!config.empty()) {
objectDir += "-";
objectDir += config;
}
objectDir += "/";
objectDir += gt->GetName();
return objectDir;
}
```
Simply renaming the installed file and moving it into a different folder is also not feasible, because `install(EXPORT) ` hardcodes the paths where to look up the object files.
It would be great if the installation path could be tweaked regardless of target name and source file name and location.
One part could likely be achieved by making the `OUTPUT_NAME` (source file?) property work for the object files.
And we'd need something additional:
- to configure the `objects-Release/` part
- the target name part `my_long_object_library_target_name`
- a way to avoid including the object file parent dir `.some_hidden_folder`
Ideally this would also apply to build time file paths as well.
Assuming that this feature is ok, what do you think would be good knobs to configure the last 3 parts?
Would an `OBJECT_FILE_OUTPUT_PATH` source file property make sense, with a value that looks like
`objs-$<CONFIG>/$<TARGET_FILE_NAME>/$<TARGET_OBJECT_FILE_NAME>.$<TARGET_FILE_SUFFIX>`?
Where `$<TARGET_OBJECT_FILE_NAME>` would be a new generator expression.https://gitlab.kitware.com/cmake/cmake/-/issues/25401`feature_summary(FATAL_ON_MISSING_REQUIRED_PACKAGES)` clashes with `FILENAME`...2023-11-09T08:20:48-05:00Cristian Le`feature_summary(FATAL_ON_MISSING_REQUIRED_PACKAGES)` clashes with `FILENAME` and/or `VAR`Basically in the current form, throwing `FATAL_ERROR` means that there is no chance to report the missing packages when we are using either `FILENAME` or `VAR`. If this is switched to `SEND_ERROR` that should still give meaningful output.Basically in the current form, throwing `FATAL_ERROR` means that there is no chance to report the missing packages when we are using either `FILENAME` or `VAR`. If this is switched to `SEND_ERROR` that should still give meaningful output.https://gitlab.kitware.com/cmake/cmake/-/issues/25399CUDA: clang-tidy support via CUDA_CLANG_TIDY?2023-11-08T12:08:14-05:00Tom JamesCUDA: clang-tidy support via CUDA_CLANG_TIDY?The documentation for \<LANG\>\_CLANG_TIDY says `This property is implemented only when <LANG> is C, CXX, OBJC or OBJCXX` . However, you can use clang-tidy on CUDA code outside of CMake. It would be extremely convenient to be able to s...The documentation for \<LANG\>\_CLANG_TIDY says `This property is implemented only when <LANG> is C, CXX, OBJC or OBJCXX` . However, you can use clang-tidy on CUDA code outside of CMake. It would be extremely convenient to be able to set the CUDA_CLANG_TIDY property, and have it work in the same way as CXX_CLANG_TIDY.
I would also like to see HIP support for clang-tidy, but I imagine the initial conversation will be very similar. We can always split out a separate ticket for that later, if necessary.https://gitlab.kitware.com/cmake/cmake/-/issues/25397Inspecting the host system for what generators will work2023-11-08T15:51:46-05:00Maciej DziubanInspecting the host system for what generators will workIs there a way to check available CMake generators? Some argument to query it from CMake? I cannot find a way to do this.
I tried to workaround by just calling `cmake -G <generator_name>` and parsing output to find "CMake Error: Could n...Is there a way to check available CMake generators? Some argument to query it from CMake? I cannot find a way to do this.
I tried to workaround by just calling `cmake -G <generator_name>` and parsing output to find "CMake Error: Could not create named generator" message. This works fine on Linux. I don't even have to create CMakeLists.txt, the response is pretty fast. The problem with this approach is on Windows. For some reason I have to create CMakeLists.txt, otherwise it won't check the availability of generator. And generating project files take a really long time - about 3 seconds. Too long for checking that many generators.https://gitlab.kitware.com/cmake/cmake/-/issues/25396Debugger: doesn't detect client exit2023-11-10T11:46:23-05:00Dmitry NeverovDebugger: doesn't detect client exitTo reproduce:
- debug and stop on a breakpoint on windows
- kill the client process (activity monitor -> force quit)
Client process terminates, cmake keeps looping in the SessionThread (payload is empty).To reproduce:
- debug and stop on a breakpoint on windows
- kill the client process (activity monitor -> force quit)
Client process terminates, cmake keeps looping in the SessionThread (payload is empty).https://gitlab.kitware.com/cmake/cmake/-/issues/25395find_package: allow to specify value of cmake variables2023-11-09T01:29:22-05:00Luca Bertagnafind_package: allow to specify value of cmake variables<!--
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/
-->
I think it would be nice to be able to pass requested cmake variables to `find_package`. That is, doing something like
```
find_package (MyLib REQUIRED REQUIRED_VARIABLES option1 ON option2 OFF var1 "a;b;c" var2 "foo")
```
If an installation is found with `option1=OFF` or `option2=ON` or `var1`/`var2` different from the specified values, it should be rejected.
Some context: I tried to do something like
```
find_package (MyLib QUIET)
if (MyLib_FOUND)
# Check if certain vars have a value that is compatible with my needs.
# If not, set MyLIB_FOUND=FALSE, to trigger code below
endif()
if (NOT MyLib_FOUND)
# Use FetchContent to build locally
endif()
```
The problem with this is that `find_package` creates imported targets for `MyLib` as soon as it finds it, so when `FetchContent` would try to add the subdirectory, I would get errors because of a redefined target.
My workaround was to use `ExternalProject`, but I don't like that it runs at build time (forcing me to choose between hard-coding MyLib targets specs or running a separate cmake project on the fly at config time, to config/build/install MyLib). I really want to stick with FetchContent.
Note: I tried to pass `OVERRIDE_FIND_PACKAGE` to `FetchContent_Declare`, hoping that it would allow to "throw away" the imported targets, but that's not what it was designed for (and in fact, it doesn't work, b/c declared targets can never be "discarded").
Note: while it's true that "if you need a different install, set `MyLib_ROOT` to point to the specific installation you need", I've seen people (which may or may not be me) accidentally update an installation of a package on a production machine, because they copy/pasted a config script without changing the installation folder. Finding out why some test failed was complicated, until I added the checks on the tpl vars right after the successful `find_package` call.
I looked at find_package documentation, and I don't think this is currently possible. I was wondering if this feature could be of general interest, or if it's too specific and/or too complicated to add.https://gitlab.kitware.com/cmake/cmake/-/issues/25393Feature request: Include exit code in CTest's JUnit output2023-11-07T13:35:08-05:00Dimitrios ApostolouFeature request: Include exit code in CTest's JUnit outputCurrently using `ctest --output-junit` reports only whether a test is a "run" or a "fail", see the status attribute in the testcase tag:
<testcase name="yah" classname="yah" time="0.0100318" status="run">
<system...Currently using `ctest --output-junit` reports only whether a test is a "run" or a "fail", see the status attribute in the testcase tag:
<testcase name="yah" classname="yah" time="0.0100318" status="run">
<system-out></system-out>
</testcase>
<testcase name="nope" classname="nope" time="0.00910038" status="fail">
<failure message="Failed"/>
<system-out></system-out>
Apparently
* status="run" means that the exitcode == 0
* status="fail" means that the exitcode != 0
It would be useful if we could add this information in its own attribute, because we could differentiate between different failure types.
For example, the following would indicate a segfault:
<testcase name="nope" classname="nope" time="0.00910038" status="fail" exitcode=139>
<failure message="Failed"/>
<system-out></system-out>
</testcase>https://gitlab.kitware.com/cmake/cmake/-/issues/25392target_precompile_headers REUSE_FROM does not play well with CMAKE_OPTIMIZE_D...2023-11-06T19:51:42-05:00Shel Zuuztarget_precompile_headers REUSE_FROM does not play well with CMAKE_OPTIMIZE_DEPENDENCIESIf you have 2 C++ static libraries, Bar_Lib and Foo_Lib where you want to use Foo_Lib headers from Bar_Lib, you can create a target_link_libraries dependency:
`target_link_libraries(Bar_Lib PUBLIC Foo_Lib)`
but if you don't want them bu...If you have 2 C++ static libraries, Bar_Lib and Foo_Lib where you want to use Foo_Lib headers from Bar_Lib, you can create a target_link_libraries dependency:
`target_link_libraries(Bar_Lib PUBLIC Foo_Lib)`
but if you don't want them build-order sequenced you can specify:
`set(CMAKE_OPTIMIZE_DEPENDENCIES 1)`
So far so good.
However, if you also add a PCH to each static lib, i.e.: `target_precompile_headers(Foo_Lib REUSE_FROM Precompiled_Lib)` and `target_precompile_headers(Bar_Lib REUSE_FROM Precompiled_Lib)` it causes Bar_Lib to pick up a build-time dependency on Foo_Lib. (They get build-time dependencies on Precompiled_Lib as well, but that's obviously wanted. But Bar_Lib shouldn't depend on Foo_Lib to be built.)
When I look at `GLOBAL_DEPENDS_DEBUG_MODE` I see that without the precompiled header, there is no dependency between Bar_Lib and Foo_Lib. When I specify the Precompiled_Lib it gains a (weak) dependency, which apparently is enough to add it to the project dependency list (Visual Studio).
```
target 62 is [Bar_Lib]
depends on target 60 [Foo_Lib] (weak)
depends on target 3 [Precompiled_Lib] (strong)
```
The following self-contained cmake repros this issue. Comment out the target_precompile_headers to see the effect in action.
```
cmake_minimum_required(VERSION 3.20)
set(CMAKE_OPTIMIZE_DEPENDENCIES 1)
project(ProjectName)
add_library(pch STATIC EXCLUDE_FROM_ALL)
target_sources(pch PRIVATE pch.c)
target_precompile_headers(pch PUBLIC pch.h)
add_library(foo STATIC EXCLUDE_FROM_ALL)
target_sources(foo PRIVATE foo.c)
target_precompile_headers(foo REUSE_FROM pch)
add_library(bar STATIC EXCLUDE_FROM_ALL)
target_sources(bar PRIVATE bar.c)
target_link_libraries(bar PRIVATE foo)
target_precompile_headers(bar REUSE_FROM pch)
add_executable(main)
target_sources(main PRIVATE main.c)
target_link_libraries(main PRIVATE foo bar)
target_precompile_headers(main REUSE_FROM pch)
```https://gitlab.kitware.com/cmake/cmake/-/issues/25391Doc: Restructering the documentation page2023-11-06T16:45:59-05:00Cristian LeDoc: Restructering the documentation pageMoving the discussion from !8868.
I want to discuss some potential improvements to the `CMake` documentation. First a few issues that I see
## Some issues
- Top-level help directory (https://cmake.org/cmake/help/latest/index.html) is a...Moving the discussion from !8868.
I want to discuss some potential improvements to the `CMake` documentation. First a few issues that I see
## Some issues
- Top-level help directory (https://cmake.org/cmake/help/latest/index.html) is a bit wordy for new-comers. First-time visitors could be classified in: Project users, Project developers and Advanced/CMake developers. In principle there are sections to guide each type of users [1], but it is in a text body. I believe it is more helpful to add some sections for these individual sections like `User guide`, `Project developer guide`, `Advanced guide` or something similar
- There is little distinction between the reference pages and guide pages. I think this is more due to the theme, but some reordering of the headings and TOC could also help visualize where you are and how to get back
- The CMake sphinx theme is a bit old-looking when we compare with the ones in https://sphinx-themes.org/, e.g. `furo` (no dark-mode, quick-navigation etc.)
- The sphinx theme can be ambiguous. E.g. when rendering `versionadded`, it is not made clear which section of the text corresponds to that block
- Guides are comprehensive. It is nice that there is so much information, but it could use a `tldr` section, a `how-to`/`faq` section, etc.
- We should highlight the current recommended standards for `Project developers` so they can have a place to get up to speed. E.g. the `FetchContent`-`find_package` interoperability
## Suggested actions
- Try out other sphinx themes
- Restructure the TOC. We can add [`sphinx-redirects`](https://pypi.org/project/sphinx-reredirects/) to maintain the old documentation links
- Add `tldr` and other quick-referencing navigations. Something like [this](https://packit.dev/docs/configuration/examples) where you have a quick access to the common tasks for `User guide` could be helpful
[1]: https://gitlab.kitware.com/cmake/cmake/-/blob/530deed998a363e6e8ef5e1275c03320fe4d9e06/Help/index.rst#L14-19
CC: @craig.scott @brad.kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25390`check_c_compiler_flag` approves some flags despite compiler warnings.2023-11-06T09:57:55-05:00SH`check_c_compiler_flag` approves some flags despite compiler warnings.For example, this command:
clang-18 --target=arm64 -msse4.2 -c -xc /dev/null
produces this diagnostic:
clang-18: warning: argument unused during compilation: '-msse4' [-Wunused-command-line-argument]
but with `CC=clang-18 CFL...For example, this command:
clang-18 --target=arm64 -msse4.2 -c -xc /dev/null
produces this diagnostic:
clang-18: warning: argument unused during compilation: '-msse4' [-Wunused-command-line-argument]
but with `CC=clang-18 CFLAGS=--target=arm64` [check_c_compiler_flag](https://cmake.org/cmake/help/latest/module/CheckCCompilerFlag.html) will still interpret `-msse4` as a valid flag.
Apparently this quirky diagnostic example is a workaround for something else going on in LLVM and it may not persist forever (it should be promoted to an error), but the point is that there is diagnostic output yet the test still passes.
Adding `-Werror=unused-command-line-argument` to `CFLAGS` works around the problem.https://gitlab.kitware.com/cmake/cmake/-/issues/25387Please provide fully statically linked binaries of CMake2023-11-03T08:03:01-04:00John DoePlease provide fully statically linked binaries of CMakeAs per [this Discourse thread](https://discourse.cmake.org/t/please-provide-fully-statically-linked-binaries-of-cmake/9299) I'm opening an issue here.
The [CMake binaries for linux](https://github.com/Kitware/CMake/releases/download/v3....As per [this Discourse thread](https://discourse.cmake.org/t/please-provide-fully-statically-linked-binaries-of-cmake/9299) I'm opening an issue here.
The [CMake binaries for linux](https://github.com/Kitware/CMake/releases/download/v3.27.7/cmake-3.27.7-linux-x86_64.tar.gz) provided on the website have no dependencies except on GLIBC, which is linked dynamically...
Is it possible to instead provide linux binaries that are **fully statically linked** to [MUSL](https://musl.libc.org)? Such binaries will work out of the box on both GLIBC and MUSL distros, and also work on distros with a GLIBC that is too old/new.
The `cmake-gui` binary is the only exception, because it has other dependencies (Qt), however Qt can be built on MUSL and linked statically. Void Linux (musl version) offers working copies of Qt5 and Qt6, with patches:
[void-packages/tree/master/srcpkgs/qt5](https://github.com/void-linux/void-packages/tree/master/srcpkgs/qt5)
[void-packages/tree/master/srcpkgs/qt6-base](https://github.com/void-linux/void-packages/tree/master/srcpkgs/qt6-base)
Full list of qt5-\* and qt6-\* packages provided by Void are searchable on [this page](https://voidlinux.org/packages/?arch=x86_64-musl&q=qt5).https://gitlab.kitware.com/cmake/cmake/-/issues/25386cmake-gui: crash on macOS after pasting string containing newline2023-11-03T12:46:06-04:00Sean McBridecmake-gui: crash on macOS after pasting string containing newlineI pasted a string that contained a newline into the CXXFLAGS field, then pressed Return, then clicked 'Configure', then it crashes.
It reproduces even.I pasted a string that contained a newline into the CXXFLAGS field, then pressed Return, then clicked 'Configure', then it crashes.
It reproduces even.https://gitlab.kitware.com/cmake/cmake/-/issues/25385cmake-gui: black theme, unreadable red background with gray text2023-11-04T19:50:36-04:00Crystal Hammercmake-gui: black theme, unreadable red background with gray text![06_15-30-08_](/uploads/299cfec8c1a8168becd04239bd199027/06_15-30-08_.jpg)
Hi. I've had this issue since many years.
It happens on Windows 10, with a black theme (based on high contrast one). If needed, theme is [on my website](https:...![06_15-30-08_](/uploads/299cfec8c1a8168becd04239bd199027/06_15-30-08_.jpg)
Hi. I've had this issue since many years.
It happens on Windows 10, with a black theme (based on high contrast one). If needed, theme is [on my website](https://cryham.tuxfamily.org/themes/#Windows_10).
It also happens on Debian with KDE. Probably any black theme, even Breeze Dark I think.
Two places are very annoying to read.
First, unreadable is the changed settings background, your red color. With gray text from system I think.
And second is that red text in messages area bottom. BTW, can I change the Courier font there on Windows?
As a general rule we should either set background and text colors or none of them. Or allow full program theme customization for all used colors.
I see no options for theme, colors or fonts in cmake-gui.https://gitlab.kitware.com/cmake/cmake/-/issues/25384FindVulkan: check CMake config file of each library first and follow their ta...2024-01-19T11:38:45-05:00SpaceImFindVulkan: check CMake config file of each library first and follow their target name conventionFindVulkan tends to assume that Vulkan libraries have been installed through Vulkan SDK of LunarG, which is just one way to install Vulkan libraries, but not the only way. When you build each library yourself from sources, you can ends u...FindVulkan tends to assume that Vulkan libraries have been installed through Vulkan SDK of LunarG, which is just one way to install Vulkan libraries, but not the only way. When you build each library yourself from sources, you can ends up with libraries installed in different locations, with CMake config files (they have been added progressively to each library).
These CMake config files should have precedence in FindVulkan, because it's more robust. Moreover they may not define the same target names than the one defined in FindVulkan. So it would be nice to deprecate several target names in favor of target names of these config files to avoid a mess of inconsistent target names in projects depending on Vulkan.
- vulkan-headers:
- config file: `VulkanHeadersConfig.cmake`
- targets in config file: `Vulkan::Headers`, `Vulkan::Registry`
- targets in module file: `Vulkan::Headers`
- vulkan-loader:
- config file: `VulkanLoaderConfig.cmake`
- targets in config file: `Vulkan::Loader`
- targets in module file: `Vulkan::Vulkan`
- glslang:
- config file: `glslangConfig.cmake`
- targets in config file: `glslang::glslang`, `glslang::SPIRV`, `glslang::HLSL`, `glslang::SPVRemapper`, `glslang::glslang-standalone`, `glslang::spirv-remap`
- targets in module file: `Vulkan::glslang`, `Vulkan::glslangValidator`
- SPIRV-Headers:
- config file: `SPIRV-HeadersConfig.cmake`
- targets in config file: `SPIRV-Headers::SPIRV-Headers`
- targets in module file: ?
- SPIRV-Tools (config files are not very neat, some coordination with library maintainers would be wise):
- config files: `SPIRV-ToolsConfig.cmake`, `SPIRV-Tools-optConfig.cmake`, `SPIRV-Tools-linkConfig.cmake`, `SPIRV-Tools-reduceConfig.cmake`, `SPIRV-Tools-lintConfig.cmake`, `SPIRV-Tools-diffConfig.cmake`
- targets in config file: `SPIRV-Tools-shared` if shared else `SPIRV-Tools-static`, `SPIRV-Tools-opt`, `SPIRV-Tools-link`, `SPIRV-Tools-reduce`, `SPIRV-Tools-lint`, `SPIRV-Tools-diff`
- targets in module file: `Vulkan::SPIRV-Tools`
- volk:
- config file: `volkConfig.cmake`
- targets in config file: `volk::volk`, `volk::volk_headers`
- targets in module file: `Vulkan::volk`https://gitlab.kitware.com/cmake/cmake/-/issues/25380Makefiles: Fortran module dependency named via preprocessor DEFINE variable2023-11-07T01:53:41-05:00Jeff HoleMakefiles: Fortran module dependency named via preprocessor DEFINE variableHere is a simple example to show the problem. This is possibly related to #16853.
I am using CMake 3.20.2, GCC toolchain 10 (gfortran 10.3.1), on Rocky Linux 8.8. GNU Make version is 4.2.1.
main.f90:
```fortran
1 #define MODULE_NAME ...Here is a simple example to show the problem. This is possibly related to #16853.
I am using CMake 3.20.2, GCC toolchain 10 (gfortran 10.3.1), on Rocky Linux 8.8. GNU Make version is 4.2.1.
main.f90:
```fortran
1 #define MODULE_NAME MyConstants
2
3 module MODULE_NAME
4 implicit none
5 real(8) :: pi = 3.1415926535897932d0
6 end module
7
8 program main
9 use MODULE_NAME
10 implicit none
11 print *, 'pi = ', pi
12 end program
```
CMakeLists.txt:
```cmake
1 project(test LANGUAGES Fortran)
2 set(CMAKE_Fortran_PREPROCESS YES)
3 add_executable(main.out main.f90)
```
I have both these files in a directory alone, and run:
```bash
cmake -B build
cd build
make
```
And I get the following output:
```bash
Scanning dependencies of target main.out
[ 50%] Building Fortran object CMakeFiles/main.out.dir/main.f90.o
Error copying Fortran module "module_name.mod". Tried "MODULE_NAME.mod" and "module_name.mod".
make[2]: *** [CMakeFiles/main.out.dir/depend.make:7: CMakeFiles/main.out.dir/module_name.mod.stamp] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/main.out.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
```
It appears when CMake determines module dependencies, it doesn't preprocess the file (at least not fully, as suggested in #16853), and it thinks the module name is "MODULE_NAME" instead of "MyConstants".https://gitlab.kitware.com/cmake/cmake/-/issues/25376cmake_parse_arguments() should have a PARSE_ARGN mode2023-11-01T10:55:49-04:00Kyle Edwardscmake_parse_arguments() should have a PARSE_ARGN mode`cmake_parse_arguments()` currently has a `PARSE_ARGV` mode, where you start at a specified index in the argument list. I think we should also have a `PARSE_ARGN` mode, where it does the obvious thing and starts parsing after the last na...`cmake_parse_arguments()` currently has a `PARSE_ARGV` mode, where you start at a specified index in the argument list. I think we should also have a `PARSE_ARGN` mode, where it does the obvious thing and starts parsing after the last named argument.https://gitlab.kitware.com/cmake/cmake/-/issues/25375target_link_options() should work on static libraries2023-11-04T17:55:15-04:00Kyle Edwardstarget_link_options() should work on static librariesFrom the documentation of [`target_link_options()`](https://cmake.org/cmake/help/latest/command/target_link_options.html):
> **Note:** This command cannot be used to add options for static library targets, since they do not use a linker...From the documentation of [`target_link_options()`](https://cmake.org/cmake/help/latest/command/target_link_options.html):
> **Note:** This command cannot be used to add options for static library targets, since they do not use a linker. To add archiver or MSVC librarian flags, see the `STATIC_LIBRARY_OPTIONS` target property.
It seems to me that if someone is trying to call `target_link_options()` on a static library, it's fairly obvious that they mean to set `STATIC_LIBRARY_OPTIONS`. CMake should do the obvious thing here.
This does become more complicated when you take scope into account. If the scope is `PRIVATE` then it should set `STATIC_LIBRARY_OPTIONS`. If it's `INTERFACE` then it should still set `INTERFACE_LINK_OPTIONS`. If it's `PUBLIC` then should it set both of these?https://gitlab.kitware.com/cmake/cmake/-/issues/25373Querying target properties with generator expressions - LINK_LIBRARIES incosi...2023-11-09T19:57:44-05:00Maciej DziubanQuerying target properties with generator expressions - LINK_LIBRARIES incosistencyI wanted to dump various CMake target properties to a file. These properties can contain generator expressions, which I expected to be resolved to actual values. I used `file(GENERATE)` command.
```
cmake_minimum_required(VERSION 3.10.0...I wanted to dump various CMake target properties to a file. These properties can contain generator expressions, which I expected to be resolved to actual values. I used `file(GENERATE)` command.
```
cmake_minimum_required(VERSION 3.10.0)
project(Test)
add_executable(Exec main.cpp)
target_link_libraries(Exec PRIVATE Lib0 $<IF:$<CONFIG:Debug>,Lib1,Lib2>)
target_include_directories(Exec PRIVATE /Dir0 $<IF:$<CONFIG:Debug>,/Dir1,/Dir2>)
target_compile_definitions(Exec PRIVATE -DVALUE=Val0 -DVALUE=$<IF:$<CONFIG:Debug>,Val1,Val2>)
target_compile_options(Exec PRIVATE Opt0 $<IF:$<CONFIG:Debug>,Opt1,Opt2>)
set(EXPR "\
$<TARGET_PROPERTY:Exec,LINK_LIBRARIES>
$<TARGET_PROPERTY:Exec,INCLUDE_DIRECTORIES>
$<TARGET_PROPERTY:Exec,COMPILE_DEFINITIONS>
$<TARGET_PROPERTY:Exec,COMPILE_OPTIONS>
")
file(GENERATE OUTPUT output$<CONFIG>.txt CONTENT "${EXPR}")
```
This works great for all properties I tried except for `LINK_LIBRARIES` - generator expressions are not resolved. See output for debug config:
```
Lib0;$<IF:$<CONFIG:Debug>,Lib1,Lib2>
/Dir0;/Dir1
VALUE=Val0;VALUE=Val1
Opt0;Opt1
```
The behaviour is incosistent. After adding `$<GENEX_EVAL>` around `$<TARGET_PROPERTY:Exec,LINK_LIBRARIES>` it starts to work as expected. Why is it different for `LINK_LIBRARIES` (and `INTERFACE_LINK_LIBRARIES`)? Is this behaviour documented? I cannot find anything about it, looks like a bug.
I am using current cmake from Arch repositories, which is 3.27.7.https://gitlab.kitware.com/cmake/cmake/-/issues/25370Support marking source files as "independent"2023-12-15T06:20:27-05:00Ben BoeckelSupport marking source files as "independent"This would allow CMake to optimize dependencies to indicate that the compilation of *other* sources in the same target do not need to depend on the independent source itself. As an example, if we generate `gen.cxx` and it is in the same ...This would allow CMake to optimize dependencies to indicate that the compilation of *other* sources in the same target do not need to depend on the independent source itself. As an example, if we generate `gen.cxx` and it is in the same target as `not_gen.cxx`, `non_gen.cxx.o` will wait for `gen.cxx` to exist before compiling `non_gen.cxx`. If there were a way to mark generated sources as "independent", CMake could break this
Initial implementation was performed in !8904. It was observed that in a VTK build of the `CMakeFiles/vtkCommonCorePython.dir/CMakeFiles/vtkCommonCorePython/vtkABIPython.cxx.o` object that:
- without any file sets, 869 tasks needed to be performed from a clean build
- utilizing CMP0154 and header filesets reduced this to 541 tasks
- using `SOURCES` file sets from !8904 reduced it further to 343 tasks
By pruning these unnecessary dependencies, builds will be able to have more work available to utilize available parallelism and complete builds sooner.
The `SOURCES` name of the file set is not accurate for this behavior; or at least the behavior that is intended. Instead, it is probably beneficial to have `SOURCES` file sets and utilize a way to set properties on the file sets (rather than the sources because the sources can be shared between targets) to indicate that this is the state of the build.
Cc: @craig.scott @brad.kingBen BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25364SYSTEM target property doesn't affect building the target itself2023-10-26T04:17:45-04:00Craig ScottSYSTEM target property doesn't affect building the target itselfOriginally reported in the context of FetchContent in this forum post: https://discourse.cmake.org/t/fetchcontent-declare-system-property-for-hierarchical-dependencies/9198 (but the underlying problem isn't specific to FetchContent).
Th...Originally reported in the context of FetchContent in this forum post: https://discourse.cmake.org/t/fetchcontent-declare-system-property-for-hierarchical-dependencies/9198 (but the underlying problem isn't specific to FetchContent).
The `SYSTEM` target property only affects consumers that link to that target, not when building the target itself. This is also made clear by the `SYSTEM` property's documentation. However, it could be argued that the `SYSTEM` behavior should also apply when building that target too, at least in some situations. As the linked forum post demonstrates, there are scenarios where users will intuitively expect this to be the case.
Not sure what's the right way forward with this, but I'm opening this issue to discuss potential options.