CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-01-17T08:02:34-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25602BYPASS_PROVIDER is not forwarded through multiple calls2024-01-17T08:02:34-05:00Luc TourailleBYPASS_PROVIDER is not forwarded through multiple callsIn a dependency provider, I want to use the `FindBoost` provided by cmake, so I call
```
find_package(Boost BYPASS_PROVIDER)
```
However, `FindBoost` does a `find_package(Boost)` on its own, which re-enters my dependency provider, result...In a dependency provider, I want to use the `FindBoost` provided by cmake, so I call
```
find_package(Boost BYPASS_PROVIDER)
```
However, `FindBoost` does a `find_package(Boost)` on its own, which re-enters my dependency provider, resulting in an infinite loop. Would it makes sense for `find_package(X BYPASS_PROVIDER)` to forward `BYPASS_PROVIDER` to all sub-calls to `find_package(X)`?https://gitlab.kitware.com/cmake/cmake/-/issues/25521Ninja Multi-Config: Unexpected build through order-only dependency2023-12-26T14:21:54-05:00Geert JansenNinja Multi-Config: Unexpected build through order-only dependencyIn my project, I have a library called “Library” and a library called “LibraryTest”. They both compile from the same sources. The former is exported, the latter is compiled with address sanitation and linked against the test suite.
To g...In my project, I have a library called “Library” and a library called “LibraryTest”. They both compile from the same sources. The former is exported, the latter is compiled with address sanitation and linked against the test suite.
To get faster builds, I want to link the test suite against “Library” in the “Devel” configuration, with the intention/expectation that “LibraryTest” would not have to be compiled. In Release mode, both are compiled and the test suite is run. I’m using the Ninja Multi-Config generator. My list file looks like this:
```
cmake_minimum_required(VERSION 3.27)
project(Example LANGUAGES CXX)
add_library(Library lib.cc)
add_library(LibraryTest lib.cc)
target_compile_options(LibraryTest PUBLIC -fsanitize=address)
target_link_libraries(LibraryTest PUBLIC -fsanitize=address)
add_executable(test test.cc)
target_link_libraries(test Library$<$<CONFIG:Release>:Test>)
```
The list file works as expected, and the correct library is linked depending on the configuration. However, both libraries are always compiled. I am building with `ninja -f build-Devel.ninja test` so in this case I would expect only the regular library to get built.
Looking at the generated Ninja file for “Devel”, the “Devel/test” target has an order-only dependency on the test library:
```
build Devel/test: CXX_EXECUTABLE_LINKER__test_Devel CMakeFiles/test.dir/Devel/test.cc.o | Devel/libLibrary.a || Devel/libLibrary.a Devel/libLibraryTest.a
```
Removing this order-only dependency stops building the test library.
I reported this on the [discourse](https://discourse.cmake.org/t/unexpected-build-of-unused-target/9626) and it was suggested to create an issue for this.
My tests we done with CMake 3.27.8 and Ninja 1.11.1https://gitlab.kitware.com/cmake/cmake/-/issues/25236Some source specific compiler flags prevent using ninja as a toolchain for MS...2023-09-08T09:57:30-04:00Björn RogetzkySome source specific compiler flags prevent using ninja as a toolchain for MSVC builds when using them to override project wide flagsSummary: It's impossible with Ninja to override /Gz with /Gd for single files if /Gz is set for the target. Visual Studio toolchains handle this fine.
Result: Command line error D8016: '/Gz' and '/Gd' command-line options are incompatib...Summary: It's impossible with Ninja to override /Gz with /Gd for single files if /Gz is set for the target. Visual Studio toolchains handle this fine.
Result: Command line error D8016: '/Gz' and '/Gd' command-line options are incompatible
When using Visual Studio 2019 I am running into the problem of it (apparently) using Ninja as the default toolchain. Normally that would be fine. However in some cases when compiler flags are set project wide with target_compile_options and then I want them overwritten for a few specific files it will fail to compile. This works fine (even without warnings) when using a Visual Studio toolchain. Tested with Visual Studio 16 2019 and Visual Studio 16 2019 Win64.
This is extra annoying because of the fact that it works fine when running CMake from the VS Native Tools command line, (seems to default to a different generator), but not when run from within Visual studio itself. It can be "solved" by changing the CMakeSettings.json file to specify the different toolchains, however that is slightly hidden as a advanced setting, and would require users to be aware of this.
There are a few issues I could find with related problems, but in those cases it only caused warnings, and I have "solved" such a problem myself previously, by having CMake find and replace the optimization flags in each of the CMAKE_CXX_FLAGS_RELEASE_INIT etc... Perhaps there was a cleaner solution in that case, but even then it doesn't solve this case, as here I want the default project/target wide setting, then specific overridden files.
My suggested solution would be to instead of trying to fix each problem individually, to instead add a function that allows the "stripping" of compiler flags from a target/file/something in the same way they can be added.
If it's wanted to only fix this specific issue, then however the Visual studio toolchain handles it should be a possible solution. However that risks other similar issues appearing in the future again.
A couple examples of similar issues I could find:
cmake/cmake#19084
cmake/cmake#19108
And code that replicates this issue:
`cmake_minimum_required(VERSION 3.26 FATAL_ERROR)`
`project (hello_cmake)`
`add_executable(hello_cmake main.cpp Secondary.cpp)`
`target_compile_options(hello_cmake PRIVATE /Gz)`
`set_source_files_properties(${CMAKE_CURRENT_SOURCE_DIR}/Secondary.cpp PROPERTIES COMPILE_OPTIONS /Gd)`
Output from failed build:
> \------ Build All started: Project: NinjaFails, Configuration: x64-Debug ------ \[1/2\] C:\\PROGRA~~2\\MICROS~~2\\2019\\PROFES~~1\\VC\\Tools\\MSVC\\1429~~1\.301\\bin\\Hostx64\\x64\\cl.exe /TP /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od /RTC1 -MDd /Gz /Gd /showIncludes /FoCMakeFiles\\hello_cmake.dir\\Secondary.cpp.obj /FdCMakeFiles\\hello_cmake.dir\\ /FS -c ......\\Secondary.cpp FAILED: CMakeFiles/hello_cmake.dir/Secondary.cpp.obj C:\\PROGRA~~2\\MICROS~~2\\2019\\PROFES~~1\\VC\\Tools\\MSVC\\1429~~1\.301\\bin\\Hostx64\\x64\\cl.exe /TP /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od /RTC1 -MDd /Gz /Gd /showIncludes /FoCMakeFiles\\hello_cmake.dir\\Secondary.cpp.obj /FdCMakeFiles\\hello_cmake.dir\\ /FS -c ......\\Secondary.cpp Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30151 for x64 Copyright (C) Microsoft Corporation. All rights reserved.
>
> C:\\Users\\username\\Desktop\\NinjaFails\\out\\build\\x64-Debug\\cl : Command line error D8016: '/Gz' and '/Gd' command-line options are incompatible ninja: build stopped: subcommand failed.
>
> Build All failed.https://gitlab.kitware.com/cmake/cmake/-/issues/25148Language: arguments split around unquoted `(` characters2024-02-06T15:00:33-05:00Craig ScottLanguage: arguments split around unquoted `(` charactersThe docs for `foreach()` state the following:
>```cmake
>foreach(<loop_var> <items>)
> <commands>
>endforeach()
>```
>where <items> is a list of items that are separated by semicolon or whitespace.
However, it appears that other charac...The docs for `foreach()` state the following:
>```cmake
>foreach(<loop_var> <items>)
> <commands>
>endforeach()
>```
>where <items> is a list of items that are separated by semicolon or whitespace.
However, it appears that other characters also end up acting as list separators if `<items>` is an unquoted value. Consider the following example:
```cmake
# Same behavior if we use the old form without "IN ITEMS" too
foreach(url IN ITEMS https://ecss.nl/wp-content/uploads/2020/04/ECSS_SMP_Issue1(2March2020).zip)
message(STATUS "url = ${url}")
endforeach()
```
The output from the above shows the surprising result:
```
CMake Warning (dev) at checker.cmake:3:
Syntax Warning in cmake code at column 92
Argument not separated from preceding token by whitespace.
This warning is for project developers. Use -Wno-dev to suppress it.
-- url = https://ecss.nl/wp-content/uploads/2020/04/ECSS_SMP_Issue1
-- url = (
-- url = 2March2020
-- url = )
-- url = .zip
```
The warning gives a clue as to what is happening. The example can be easily modified to give the desired result by quoting the URL, but since the `foreach()` docs don't mention this case, it isn't obvious that one needs to protect against this sort of problem. See [this forum post](https://discourse.cmake.org/t/fetchcontent-does-not-support-properly-urls-with-brackets/8650) where this was first noticed in an example involving FetchContent/ExternalProject.https://gitlab.kitware.com/cmake/cmake/-/issues/25103MSVC: _CMAKE_INCLUDE_SYSTEM_FLAG_${lang}_WARNING should be configurable from ...2024-01-31T16:27:09-05:00Patrick H.MSVC: _CMAKE_INCLUDE_SYSTEM_FLAG_${lang}_WARNING should be configurable from outsideHello!
would it be possible to make this option externally configurable instead of hard coding it to "-external:W0". Currently it has the _ prefix which means it should be a private variable and is not really documented. So changing it t...Hello!
would it be possible to make this option externally configurable instead of hard coding it to "-external:W0". Currently it has the _ prefix which means it should be a private variable and is not really documented. So changing it this way I have a bit of a bad feeling.
For background, we have a larger C++ project that runs on multiple platforms (Windows, macOS, Linux, cell phones). We collect our dependencies through Conan, which accounts for internal libraries and third-party libraries. Currently, all are marked as external and therefore get an /external:W0, which is suboptimal. The default value when enabling system includes via compile flags is currently even W1. Some of our problems would be solved by enabling NO_SYSTEM_FROM_IMPORTED, but depending on the build configuration, other stuff is also flagged as system. So I would like to avoid passing W0 there.
Another problem is that /W0 also deactivates parts of /SDL e.g. the warnings as error for security relevant compile checks.
See https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170
The default could still be W0, but this would make things more flexible for everyone.
Best,
Patrickhttps://gitlab.kitware.com/cmake/cmake/-/issues/24961set_source_files_properties | set_target_properties has no APPEND2023-06-07T00:18:22-04:00Nick Papiorset_source_files_properties | set_target_properties has no APPEND<!--
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/
-->
When creating only some compile definitions for some sub-sources it would be nice if one could fine tune these a bit more.
For instance the current way of appending source file compile definitions would be:
```cmake
set_property(
SOURCE file1.c file2.c
APPEND PROPERTY COMPILE_DEFINITIONS FOO_BAR
)
```
I would like the methods to be more similar, for instance the `APPEND` does not exist for the `set_source_files_properties`.
Same for `set_target_properties`https://gitlab.kitware.com/cmake/cmake/-/issues/23953Ninja: Add prefix/suffix variable for internal target names2022-09-19T17:50:50-04:00Klaus NeuschwanderNinja: Add prefix/suffix variable for internal target namesWhen combining multiple builds using `CMAKE_NINJA_OUTPUT_PATH_PREFIX` and including them with `subninja`, it can happen that both sub-builds can contain targets with the same name. When internal targets are generated (e.g. `cmake_object_...When combining multiple builds using `CMAKE_NINJA_OUTPUT_PATH_PREFIX` and including them with `subninja`, it can happen that both sub-builds can contain targets with the same name. When internal targets are generated (e.g. `cmake_object_order_depends_target_{target}`), those target definitions collide and the build can fail.
Therefore, I propose a variable, e.g. `CMAKE_INTERNAL_TARGET_PREFIX` which is added to all internal targets. This variable can then be set to different values for different invocations of CMake.
It may also be possible to use `CMAKE_NINJA_OUTPUT_PATH_PREFIX` for these targets as well, but I am not sure how well this plays with potential slashes in non-file targets.
See also https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296https://gitlab.kitware.com/cmake/cmake/-/issues/23787Investigate build times of CMake2022-09-19T11:56:16-04:00friendlyanonInvestigate build times of CMakeI have seen people bringing up the build times of CMake as a pain point and I have also noticed that during my contributions, however for me it's an infrequent occurence, so I don't mind all that much.
I think source based distribution...I have seen people bringing up the build times of CMake as a pain point and I have also noticed that during my contributions, however for me it's an infrequent occurence, so I don't mind all that much.
I think source based distributions are affected for one here.
I have compiled CMake via the bootstrap script on an Ubuntu VM with 2 cores, CMake being at commit ad2e7f3c537dc88ea8140bab67c43d25695637f1 with the following command:
```
CPP=clang-cpp-12 \
LD=ld.lld-12 \
CC=clang-12 \
CXX=clang++-12 \
CFLAGS="-ftime-trace -isystem /usr/include/c++/10 -isystem /usr/include/x86_64-linux-gnu/c++/10" \
CXXFLAGS="-ftime-trace -isystem /usr/include/c++/10 -isystem /usr/include/x86_64-linux-gnu/c++/10 -stdlib=libstdc++" \
LDFLAGS="-L/usr/lib/gcc/x86_64-linux-gnu/10" \
time sh -ec '.../cmake/bootstrap --system-libs --bootstrap-system-libuv --bootstrap-system-jsoncpp --bootstrap-system-librhash --generator=Ninja --parallel=2 -- -DBUILD_TESTING=0 && ninja'
```
`time` output:
```
1473.50user 70.72system 13:19.68elapsed 193%CPU (0avgtext+0avgdata 357652maxresident)k
273376inputs+745440outputs (7633major+14968114minor)pagefaults 0swaps
```
Analysis of the traces:
<details>
<summary>ClangBuildAnalyzer output</summary>
```
Analyzing build trace from '.../out'...
**** Time summary:
Compilation (1330 times):
Parsing (frontend): 1425.5 s
Codegen & opts (backend): 675.2 s
**** Files that took longest to parse (compiler frontend):
9339 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGeneratorTarget.cxx.o
7424 ms: .../Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o
7164 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalNinjaGenerator.cxx.o
6971 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalGenerator.cxx.o
6872 ms: .../Source/CMakeFiles/CMakeLib.dir/cmQtAutoGenInitializer.cxx.o
6680 ms: .../Source/CMakeFiles/CTestLib.dir/CTest/cmCTestTestHandler.cxx.o
6380 ms: .../Source/CMakeFiles/CMakeLib.dir/cmLocalGenerator.cxx.o
6324 ms: .../Source/CMakeFiles/CMakeLib.dir/cmMakefileTargetGenerator.cxx.o
6290 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGeneratorExpressionNode.cxx.o
6157 ms: .../Source/CMakeFiles/CMakeLib.dir/cmFileCommand.cxx.o
**** Files that took longest to codegen (compiler backend):
32903 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGeneratorTarget.cxx.o
15247 ms: .../Source/CMakeFiles/CMakeLib.dir/cmLocalGenerator.cxx.o
14481 ms: .../Source/CMakeFiles/CMakeLib.dir/cmMakefile.cxx.o
13265 ms: .../Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o
12786 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalNinjaGenerator.cxx.o
12148 ms: .../Source/CMakeFiles/CTestLib.dir/CTest/cmCTestTestHandler.cxx.o
11985 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalGenerator.cxx.o
11581 ms: .../Source/CMakeFiles/CTestLib.dir/cmCTest.cxx.o
11339 ms: .../Source/CMakeFiles/CMakeLib.dir/cmTarget.cxx.o
11086 ms: .../Source/CMakeFiles/CTestLib.dir/CTest/cmCTestCoverageHandler.cxx.o
**** Templates that took longest to instantiate:
8396 ms: std::_Rb_tree<std::basic_string<char>, std::pair<const std::basic_st... (682 times, avg 12 ms)
6939 ms: std::unique_ptr<cmTargetInternals> (360 times, avg 19 ms)
6884 ms: std::set<std::basic_string<char>>::insert (211 times, avg 32 ms)
6827 ms: std::unique_ptr<cmCustomCommand> (341 times, avg 20 ms)
6679 ms: std::make_shared<cmListFileFunction::Implementation, std::basic_stri... (414 times, avg 16 ms)
6524 ms: std::_Rb_tree<std::basic_string<char>, std::pair<const std::basic_st... (341 times, avg 19 ms)
6521 ms: std::unique_ptr<cmMakefile::DeferCommands> (338 times, avg 19 ms)
6331 ms: std::unordered_map<int, int> (353 times, avg 17 ms)
5611 ms: std::allocate_shared<cmListFileFunction::Implementation, std::alloca... (414 times, avg 13 ms)
5601 ms: std::__uniq_ptr_data<cmTargetInternals, std::default_delete<cmTarget... (360 times, avg 15 ms)
5539 ms: std::__uniq_ptr_impl<cmTargetInternals, std::default_delete<cmTarget... (360 times, avg 15 ms)
5537 ms: std::__uniq_ptr_data<cmCustomCommand, std::default_delete<cmCustomCo... (341 times, avg 16 ms)
5487 ms: std::__uniq_ptr_impl<cmCustomCommand, std::default_delete<cmCustomCo... (341 times, avg 16 ms)
5422 ms: std::shared_ptr<cmListFileFunction::Implementation>::shared_ptr<std:... (414 times, avg 13 ms)
5254 ms: std::__shared_ptr<cmListFileFunction::Implementation, __gnu_cxx::_S_... (414 times, avg 12 ms)
5254 ms: std::__uniq_ptr_data<cmMakefile::DeferCommands, std::default_delete<... (338 times, avg 15 ms)
5187 ms: std::basic_string<char16_t>::_M_construct<const char16_t *> (1300 times, avg 3 ms)
5178 ms: std::basic_string<char32_t>::_M_construct<const char32_t *> (1300 times, avg 3 ms)
5178 ms: std::__uniq_ptr_impl<cmMakefile::DeferCommands, std::default_delete<... (338 times, avg 15 ms)
5007 ms: std::unordered_map<std::basic_string<char>, std::vector<cmSourceFile... (338 times, avg 14 ms)
4930 ms: std::_Hashtable<int, std::pair<const int, int>, std::allocator<std::... (353 times, avg 13 ms)
4898 ms: std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<cmListFile... (414 times, avg 11 ms)
4736 ms: std::unordered_map<std::basic_string<char>, cmTarget> (338 times, avg 14 ms)
4702 ms: __gnu_cxx::__to_xstring<std::basic_string<wchar_t>, wchar_t> (650 times, avg 7 ms)
4638 ms: std::basic_string<wchar_t>::_M_construct<wchar_t *> (1300 times, avg 3 ms)
4637 ms: std::unique_ptr<cmSourceGroupInternals> (205 times, avg 22 ms)
4537 ms: std::unique_ptr<cmCustomCommand>::~unique_ptr (338 times, avg 13 ms)
4533 ms: std::_Rb_tree<std::basic_string<char>, std::basic_string<char>, std:... (176 times, avg 25 ms)
4516 ms: std::unordered_map<std::basic_string<char>, cmTarget *> (357 times, avg 12 ms)
4463 ms: std::_Hashtable<std::basic_string<char>, std::pair<const std::basic_... (338 times, avg 13 ms)
**** Template sets that took longest to instantiate:
71362 ms: std::unique_ptr<$> (3545 times, avg 20 ms)
69927 ms: std::__and_<$> (44084 times, avg 1 ms)
57320 ms: std::__uniq_ptr_data<$> (3545 times, avg 16 ms)
56637 ms: std::__uniq_ptr_impl<$> (3545 times, avg 15 ms)
50846 ms: std::_Hashtable<$> (4722 times, avg 10 ms)
48097 ms: std::unordered_map<$> (3430 times, avg 14 ms)
43853 ms: std::vector<$> (13551 times, avg 3 ms)
40290 ms: std::map<$> (6183 times, avg 6 ms)
31260 ms: std::optional<$> (2275 times, avg 13 ms)
28617 ms: std::tuple<$> (3779 times, avg 7 ms)
27139 ms: std::__or_<$> (20659 times, avg 1 ms)
25785 ms: std::_Rb_tree<$> (7729 times, avg 3 ms)
23284 ms: std::_Vector_base<$> (13340 times, avg 1 ms)
22182 ms: std::pair<$> (6727 times, avg 3 ms)
20258 ms: std::__detail::_Hashtable_alloc<$> (4129 times, avg 4 ms)
17808 ms: std::is_convertible<$> (13898 times, avg 1 ms)
17115 ms: std::allocator<$> (14786 times, avg 1 ms)
12374 ms: std::is_move_constructible<$> (6027 times, avg 2 ms)
12314 ms: std::_Optional_base<$> (2275 times, avg 5 ms)
12174 ms: std::basic_string<$> (2600 times, avg 4 ms)
11933 ms: std::__detail::_Hash_node<$> (3490 times, avg 3 ms)
11797 ms: std::__detail::_Hash_node_value_base<$> (3466 times, avg 3 ms)
11497 ms: __gnu_cxx::__aligned_buffer<$> (3459 times, avg 3 ms)
11230 ms: std::_TupleConstraints<$>::__is_implicitly_constructible<$> (6863 times, avg 1 ms)
10898 ms: std::basic_string<$>::_M_construct<$> (3877 times, avg 2 ms)
10218 ms: std::basic_string<$>::basic_string (4022 times, avg 2 ms)
10053 ms: std::basic_string<$>::_M_construct_aux<$> (3759 times, avg 2 ms)
10022 ms: std::chrono::duration<$> (6040 times, avg 1 ms)
9742 ms: std::set<$>::insert (317 times, avg 30 ms)
8944 ms: std::vector<$>::~vector (2570 times, avg 3 ms)
**** Functions that took longest to compile:
2593 ms: cmCTestCoverageHandler::HandleGCovCoverage(cmCTestCoverageHandlerCon... (.../Source/CTest/cmCTestCoverageHandler.cxx)
2551 ms: (anonymous namespace)::HandleTargetsMode(std::vector<std::__cxx11::b... (.../Source/cmInstallCommand.cxx)
2304 ms: cmMakefileTargetGenerator::WriteObjectRuleFiles(cmSourceFile const&) (.../Source/cmMakefileTargetGenerator.cxx)
2153 ms: cmNinjaNormalTargetGenerator::WriteLinkStatement(std::__cxx11::basic... (.../Source/cmNinjaNormalTargetGenerator.cxx)
1907 ms: cmTarget::cmTarget(std::__cxx11::basic_string<char, std::char_traits... (.../Source/cmTarget.cxx)
1657 ms: (anonymous namespace)::Target::Dump() (.../Source/cmFileAPICodemodel.cxx)
1641 ms: cmCTestCoverageHandler::HandleLCovCoverage(cmCTestCoverageHandlerCon... (.../Source/CTest/cmCTestCoverageHandler.cxx)
1627 ms: main (.../Source/CPack/cpack.cxx)
1423 ms: cmake::SetArgs(std::vector<std::__cxx11::basic_string<char, std::cha... (.../Source/cmake.cxx)
1410 ms: cmcmd::ExecuteCMakeCommand(std::vector<std::__cxx11::basic_string<ch... (.../Source/cmcmd.cxx)
1384 ms: cmCPackNSISGenerator::PackageFiles() (.../Source/CPack/cmCPackNSISGenerator.cxx)
1352 ms: cmCoreTryCompile::TryCompileCode(std::vector<std::__cxx11::basic_str... (.../Source/cmCoreTryCompile.cxx)
1271 ms: cmNinjaTargetGenerator::WriteObjectBuildStatement(cmSourceFile const... (.../Source/cmNinjaTargetGenerator.cxx)
1262 ms: cmFindPackageCommand::InitialPass(std::vector<std::__cxx11::basic_st... (.../Source/cmFindPackageCommand.cxx)
1228 ms: (anonymous namespace)::HandleTransformCommand(std::vector<std::__cxx... (.../Source/cmListCommand.cxx)
1186 ms: cmCTestCoverageHandler::ProcessHandler() (.../Source/CTest/cmCTestCoverageHandler.cxx)
1134 ms: cmFindPackageCommand::SearchPrefix(std::__cxx11::basic_string<char, ... (.../Source/cmFindPackageCommand.cxx)
1102 ms: cmMakefileLibraryTargetGenerator::WriteLibraryRules(std::__cxx11::ba... (.../Source/cmMakefileLibraryTargetGenerator.cxx)
1056 ms: cmNinjaTargetGenerator::WriteCompileRule(std::__cxx11::basic_string<... (.../Source/cmNinjaTargetGenerator.cxx)
1029 ms: (anonymous namespace)::cmQtAutoMocUicT::InitFromInfo(cmQtAutoGenerat... (.../Source/cmQtAutoMocUic.cxx)
990 ms: cmCTestSubmitHandler::SubmitUsingHTTP(std::__cxx11::basic_string<cha... (.../Source/CTest/cmCTestSubmitHandler.cxx)
982 ms: cmQtAutoGenInitializer::InitAutogenTarget() (.../Source/cmQtAutoGenInitializer.cxx)
978 ms: cmCMakeLanguageCommand(std::vector<cmListFileArgument, std::allocato... (.../Source/cmCMakeLanguageCommand.cxx)
907 ms: (anonymous namespace)::HandleDownloadCommand(std::vector<std::__cxx1... (.../Source/cmFileCommand.cxx)
893 ms: cmCTestMemCheckHandler::InitializeMemoryChecking() (.../Source/CTest/cmCTestMemCheckHandler.cxx)
847 ms: cmQtAutoGenInitializer::InitScanFiles() (.../Source/cmQtAutoGenInitializer.cxx)
845 ms: cmCPackGenerator::InstallCMakeProject(bool, std::__cxx11::basic_stri... (.../Source/CPack/cmCPackGenerator.cxx)
831 ms: cmCTestSubmitHandler::HandleCDashUploadFile(std::__cxx11::basic_stri... (.../Source/CTest/cmCTestSubmitHandler.cxx)
806 ms: cmCPackGenerator::DoPackage() (.../Source/CPack/cmCPackGenerator.cxx)
804 ms: cmGlobalGenerator::EnableLanguage(std::vector<std::__cxx11::basic_st... (.../Source/cmGlobalGenerator.cxx)
**** Function sets that took longest to compile / optimize:
5057 ms: void std::vector<$>::_M_range_insert<$>(__gnu_cxx::__normal_iterator... (78 times, avg 64 ms)
4243 ms: std::_Rb_tree<$>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_... (179 times, avg 23 ms)
4238 ms: void std::vector<$>::_M_realloc_insert<$>(__gnu_cxx::__normal_iterat... (137 times, avg 30 ms)
4053 ms: std::_Rb_tree<$>::_M_get_insert_unique_pos(std::__cxx11::basic_strin... (247 times, avg 16 ms)
3110 ms: std::_Rb_tree<$>::_M_erase(std::_Rb_tree_node<$>*) (469 times, avg 6 ms)
3091 ms: std::_Rb_tree_iterator<$> std::_Rb_tree<$>::_M_emplace_hint_unique<$... (201 times, avg 15 ms)
2563 ms: (anonymous namespace)::HandleTargetsMode(std::vector<$> const&, cmEx... (2 times, avg 1281 ms)
2537 ms: void std::vector<$>::_M_realloc_insert<$>(__gnu_cxx::__normal_iterat... (88 times, avg 28 ms)
2169 ms: cmNinjaNormalTargetGenerator::WriteLinkStatement(std::__cxx11::basic... (2 times, avg 1084 ms)
1950 ms: std::_Function_handler<$>::_M_manager(std::_Any_data&, std::_Any_dat... (424 times, avg 4 ms)
1934 ms: std::vector<$>::~vector() (733 times, avg 2 ms)
1925 ms: std::__cxx11::basic_string<$>* std::__uninitialized_copy<$>::__unini... (113 times, avg 17 ms)
1911 ms: cmTarget::cmTarget(std::__cxx11::basic_string<$> const&, cmStateEnum... (2 times, avg 955 ms)
1548 ms: __gnu_cxx::__normal_iterator<$> std::__find_if<$>(__gnu_cxx::__norma... (83 times, avg 18 ms)
1435 ms: cmcmd::ExecuteCMakeCommand(std::vector<$> const&, std::unique_ptr<$>) (2 times, avg 717 ms)
1429 ms: cmake::SetArgs(std::vector<$> const&) (2 times, avg 714 ms)
1373 ms: cmCoreTryCompile::TryCompileCode(std::vector<$> const&, bool) (2 times, avg 686 ms)
1305 ms: void std::_Rb_tree<$>::_M_construct_node<$>(std::_Rb_tree_node<$>*, ... (192 times, avg 6 ms)
1277 ms: cmNinjaTargetGenerator::WriteObjectBuildStatement(cmSourceFile const... (2 times, avg 638 ms)
1269 ms: cmFindPackageCommand::InitialPass(std::vector<$> const&) (2 times, avg 634 ms)
1238 ms: (anonymous namespace)::HandleTransformCommand(std::vector<$> const&,... (2 times, avg 619 ms)
1135 ms: cmFindPackageCommand::SearchPrefix(std::__cxx11::basic_string<$> con... (2 times, avg 567 ms)
1133 ms: void std::__merge_sort_with_buffer<$>(std::reverse_iterator<$>, std:... (2 times, avg 566 ms)
1114 ms: cmMakefileLibraryTargetGenerator::WriteLibraryRules(std::__cxx11::ba... (2 times, avg 557 ms)
1102 ms: void cmComputeLinkDepends::AddLinkEntries<$>(int, std::vector<$> con... (4 times, avg 275 ms)
1082 ms: cmNinjaTargetGenerator::WriteCompileRule(std::__cxx11::basic_string<... (2 times, avg 541 ms)
1055 ms: std::_Hashtable<$>::_M_insert_unique_node(std::__cxx11::basic_string... (53 times, avg 19 ms)
1047 ms: std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,... (39 times, avg 26 ms)
1009 ms: void std::__insertion_sort<$>(__gnu_cxx::__normal_iterator<$>, __gnu... (28 times, avg 36 ms)
996 ms: cmCTestSubmitHandler::SubmitUsingHTTP(std::__cxx11::basic_string<$> ... (2 times, avg 498 ms)
*** Expensive headers:
199497 ms: .../Source/cmMakefile.h (included 338 times, avg 590 ms), included via:
cmMakefile.cxx.o (2095 ms)
cmSetCommand.cxx.o (1769 ms)
cmSetDirectoryPropertiesCommand.cxx.o (1729 ms)
cmGetTestPropertyCommand.cxx.o (1653 ms)
cmAddDependenciesCommand.cxx.o (1643 ms)
cmIncludeGuardCommand.cxx.o (1629 ms)
...
195757 ms: /usr/include/c++/10/string (included 650 times, avg 301 ms), included via:
cmParseCoberturaCoverage.cxx.o cmParseCoberturaCoverage.h (658 ms)
cmSetPropertyCommand.cxx.o cmSetPropertyCommand.h (624 ms)
cmSetTargetPropertiesCommand.cxx.o cmSetTargetPropertiesCommand.h (611 ms)
cmSubdirDependsCommand.cxx.o cmSubdirDependsCommand.h (610 ms)
cmFileLockPool.cxx.o cmFileLockPool.h (598 ms)
cmCTestBuildCommand.cxx.o cmCTestBuildCommand.h (594 ms)
...
94589 ms: .../Source/cmListFileCache.h (included 413 times, avg 229 ms), included via:
cmListFileCache.cxx.o (1234 ms)
cmComputeComponentGraph.cxx.o cmComputeComponentGraph.h cmGraphAdjacencyList.h (1094 ms)
cmMessenger.cxx.o cmMessenger.h (876 ms)
cmGeneratorExpressionDAGChecker.cxx.o cmGeneratorExpressionDAGChecker.h (852 ms)
cmTest.cxx.o cmTest.h (819 ms)
cmFunctionBlocker.cxx.o cmFunctionBlocker.h (805 ms)
...
93187 ms: .../Source/cmSystemTools.h (included 503 times, avg 185 ms), included via:
cmSystemTools.cxx.o (1145 ms)
cmHexFileConverter.cxx.o (898 ms)
cmWorkingDirectory.cxx.o (811 ms)
cmFileLockUnix.cxx (760 ms)
bindexplib.cxx.o (615 ms)
cmLoadCommandCommand.cxx.o cmListFileCache.h (588 ms)
...
88748 ms: /usr/include/c++/10/functional (included 548 times, avg 161 ms), included via:
cmDependsCompiler.cxx.o cmDependsCompiler.h (735 ms)
cmDefinitions.cxx.o cmDefinitions.h (690 ms)
cmCMakePresetsGraphReadJSONTestPresets.cxx.o (653 ms)
cmCustomCommandGenerator.cxx.o cmCustomCommandGenerator.h (634 ms)
cmCMakePresetsGraphReadJSONBuildPresets.cxx.o (628 ms)
cmCMakePresetsGraphReadJSONConfigurePresets.cxx.o (622 ms)
...
86814 ms: .../Source/cmGlobalGenerator.h (included 149 times, avg 582 ms), included via:
cmGlobalGenerator.cxx.o (2357 ms)
cmSourceFileLocation.cxx.o (1677 ms)
cmTargetPropCommandBase.cxx.o (1664 ms)
cmBuildCommand.cxx.o (1642 ms)
cmInstallTargetsCommand.cxx.o (1598 ms)
cmGetDirectoryPropertyCommand.cxx.o (1589 ms)
...
80512 ms: .../Source/cmake.h (included 119 times, avg 676 ms), included via:
cmake.cxx.o (2722 ms)
cmWhileCommand.cxx.o (1419 ms)
cmVariableWatchCommand.cxx.o (1238 ms)
cmFileSet.cxx.o (1216 ms)
cmGeneratorExpressionDAGChecker.cxx.o (1209 ms)
cmIfCommand.cxx.o (1205 ms)
...
66818 ms: /usr/include/c++/10/memory (included 560 times, avg 119 ms), included via:
cmBinUtilsWindowsPELinker.cxx.o cmBinUtilsWindowsPELinker.h (560 ms)
cmCommandArgumentParserHelper.cxx.o cmCommandArgumentParserHelper.h (504 ms)
cmSourceFile.cxx.o cmSourceFile.h (497 ms)
cmCTestSubmitCommand.cxx.o cmCTestSubmitCommand.h (495 ms)
cmQtAutoGen.cxx.o cmQtAutoGen.h (468 ms)
cmFileTimes.cxx.o cmFileTimes.h (463 ms)
...
65322 ms: .../Source/cmAlgorithms.h (included 376 times, avg 173 ms), included via:
cmTarget.cxx.o cmTarget.h (749 ms)
cmNinjaLinkLineComputer.cxx.o cmNinjaLinkLineComputer.h cmLinkLineComputer.h cmStateDirectory.h (743 ms)
cmMSVC60LinkLineComputer.cxx.o cmMSVC60LinkLineComputer.h cmLinkLineComputer.h cmStateDirectory.h (687 ms)
cmLinkLineComputer.cxx.o cmLinkLineComputer.h cmStateDirectory.h (662 ms)
cmOSXBundleGenerator.cxx.o cmGeneratorTarget.h (655 ms)
cmGlobalWatcomWMakeGenerator.cxx.o cmGlobalWatcomWMakeGenerator.h cmGlobalUnixMakefileGenerator3.h cmGeneratorTarget.h (634 ms)
...
65092 ms: /usr/include/c++/10/istream (included 522 times, avg 124 ms), included via:
cmCTestBuildAndTestHandler.cxx.o cmCTestBuildAndTestHandler.h sstream (723 ms)
cmStringAlgorithms.cxx.o cmStringAlgorithms.h sstream (642 ms)
cmQtAutoGenerator.cxx.o cmQtAutoGenerator.h (590 ms)
cmCPackNuGetGenerator.cxx.o cmCPackNuGetGenerator.h cmCPackGenerator.h sstream (540 ms)
cmCPackGenerator.cxx.o cmCPackGenerator.h sstream (499 ms)
cmCTest.cxx.o cmCTest.h sstream (402 ms)
...
done in 0.8s.
```
</details>
It's worth noting that CMake is bootstrapped with PCH support, so that might be a low hanging fruit to look into.https://gitlab.kitware.com/cmake/cmake/-/issues/23660Genex: $<CONFIG:...> true for multiple MAP_IMPORTED_CONFIG_XXX entries2022-11-18T18:48:42-05:00Gerhard DGenex: $<CONFIG:...> true for multiple MAP_IMPORTED_CONFIG_XXX entriesMy project links an IMPORTED target **utils** that has an **other** library in its INTERFACE_LINK_LIBRARIES.
Both libraries are available for the _Debug_ and _Release_ config, but the indirect **other** library has been linked with the o...My project links an IMPORTED target **utils** that has an **other** library in its INTERFACE_LINK_LIBRARIES.
Both libraries are available for the _Debug_ and _Release_ config, but the indirect **other** library has been linked with the old-style **"optimized other.lib debug otherd.lib"** notation.
CMake incorrectly links **utils** and **otherd** in the Release config, if I specify _CMAKE_MAP_IMPORTED_CONFIG_XXX_ mappings. It works correctly without the mappings.
Tested with CMake 3.23.2 and the Visual Studio 15 2017 generator.
I have attached a minimal CMakeLists.txt that demonstrates the issue.[CMakeLists.txt](/uploads/089ca057b8956d666fb8286fbefa2b9d/CMakeLists.txt)
<details><summary>CMakeLists.txt</summary>
```cmake
cmake_minimum_required(VERSION 3.13)
project(test CXX)
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO RelWithDebInfo Release MinSizeRel Debug "")
set(CMAKE_MAP_IMPORTED_CONFIG_RELEASE Release RelWithDebInfo MinSizeRel Debug "")
set(CMAKE_MAP_IMPORTED_CONFIG_MINSIZEREL MinSizeRel RelWithDebInfo Release Debug "")
set(CMAKE_MAP_IMPORTED_CONFIG_DEBUG Debug RelWithDebInfo MinSizeRel Release "")
#### some imported target
add_library(utils SHARED IMPORTED)
set_target_properties(utils PROPERTIES
INTERFACE_LINK_LIBRARIES "\$<\$<NOT:\$<CONFIG:DEBUG>>:other.lib>;\$<\$<CONFIG:DEBUG>:otherd.lib>"
)
set_property(TARGET utils APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(utils PROPERTIES
IMPORTED_IMPLIB_RELEASE "utils.lib"
IMPORTED_LOCATION_RELEASE "utils.dll"
)
set_property(TARGET utils APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
set_target_properties(utils PROPERTIES
IMPORTED_IMPLIB_DEBUG "utilsd.lib"
IMPORTED_LOCATION_DEBUG "utilsd.dll"
)
####
set(PROJECT_SOURCES dummy.cpp)
# incorrectly links 'otherd.lib' and 'utils.lib' in Release config if CMAKE_MAP_IMPORTED_CONFIG* is used
add_library(${PROJECT_NAME} SHARED ${PROJECT_SOURCES})
target_link_libraries(${PROJECT_NAME} PUBLIC utils)
```
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/23393INTERFACE_SYSTEM_INCLUDE_DIRECTORIES the `${_IMPORT_PREFIX}/...` is missing!2022-04-05T16:17:20-04:00Claus KleinINTERFACE_SYSTEM_INCLUDE_DIRECTORIES the `${_IMPORT_PREFIX}/...` is missing!I am using **cmake version 3.23.0** on **OSX**
This `CMakeLists.txt` snipped:
```cmake
# to get CMAKE_INSTALL_INCLUDEDIR
include(GNUInstallDirs)
# target_include_directories with the SYSTEM modifier will request the compiler
# to omit ...I am using **cmake version 3.23.0** on **OSX**
This `CMakeLists.txt` snipped:
```cmake
# to get CMAKE_INSTALL_INCLUDEDIR
include(GNUInstallDirs)
# target_include_directories with the SYSTEM modifier will request the compiler
# to omit warnings from the provided paths, if the compiler supports that
target_include_directories(
${PROJECT_NAME} SYSTEM PUBLIC $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
)
```
Generates this exported config code:
```cmake
# Create imported target greeter::greeter
add_library(greeter::greeter STATIC IMPORTED)
set_target_properties(greeter::greeter PROPERTIES
INTERFACE_COMPILE_FEATURES "cxx_std_20"
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "fmt::fmt;greeter::project_warnings;greeter::project_options"
INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "include"
)
```
- At the line with `INTERFACE_SYSTEM_INCLUDE_DIRECTORIES` the `${_IMPORT_PREFIX}/...` is missing!https://gitlab.kitware.com/cmake/cmake/-/issues/22934file(GET_RUNTIME_DEPENDENCIES...) does not handle linker scripts from TBB2021-11-19T16:39:27-05:00Aron Helserfile(GET_RUNTIME_DEPENDENCIES...) does not handle linker scripts from TBBEncountered in the context of a VTK app using the common superbuild on linux.
TBB binary distributions on linux are distributed with several libraries where `libtbb.so.2` is the real library, and `libtbb.so` is a text file with the cont...Encountered in the context of a VTK app using the common superbuild on linux.
TBB binary distributions on linux are distributed with several libraries where `libtbb.so.2` is the real library, and `libtbb.so` is a text file with the contents
```
INPUT (libtbb.so.2)
```
If I pass this file to `file(GET_RUNTIME_DEPENDENCIES` like so:
```
# Construct a list of libraries already in the application bundle
file(GLOB_RECURSE missing_libs "${CMAKE_INSTALL_PREFIX}/${lib_dest_dir}/*${suffix}")
# Construct a list of the application's runtime dependencies
file(GET_RUNTIME_DEPENDENCIES
....
LIBRARIES ${qt_plugins} ${missing_libs}
)
```
I get a cryptic error:
```
CMake Error at cmake_install.cmake:132 (file):
file Failed to run objdump on:
/home/aron.helser/projects/xxx/sb/build/install/lib/libtbb.so
```
`libtbb.so.2` exists in that directory, so it could be handled. Or a more informative error message, perhaps.https://gitlab.kitware.com/cmake/cmake/-/issues/22918COMPILE_DEFINITIONS: Definition values with percent signs on Windows2021-11-16T12:00:42-05:00Jörg BornemannCOMPILE_DEFINITIONS: Definition values with percent signs on WindowsConsider a target with compile definitions like this
```
target_compile_definitions(myapp PRIVATE
TESTCASE_BUILDDIR="${CMAKE_BINARY_DIR}/foo%2bar"))
```
This works fine on Linux, but on Windows there will be errors. For example, MSVC’...Consider a target with compile definitions like this
```
target_compile_definitions(myapp PRIVATE
TESTCASE_BUILDDIR="${CMAKE_BINARY_DIR}/foo%2bar"))
```
This works fine on Linux, but on Windows there will be errors. For example, MSVC’s cl.exe yields “cl : Command line error D8038 : invalid argument”.
According to MS docs at https://docs.microsoft.com/en-us/cpp/build/reference/d-preprocessor-definitions?view=msvc-160#remarks percent sign should be written as doubled percent sign when passing it to the compiler with -D.
Given that `target_compile_definitions` already does some escaping, it should probably also take care of doubling the percent sign on Windows.
Discourse link: https://discourse.cmake.org/t/percent-signs-in-target-compile-definitions-on-windows/4489https://gitlab.kitware.com/cmake/cmake/-/issues/22624set(ENV{FOO} "") does not create new environment variable2021-09-14T08:12:50-04:00Jun-ichi Takimotoset(ENV{FOO} "") does not create new environment variableIf an environment variable FOO does not exist yet, `set(ENV{FOO} "")` does not export FOO.
I want to create an environmental variable FOO with empty value, and export it to control the behavior of a child process. But if FOO does not ex...If an environment variable FOO does not exist yet, `set(ENV{FOO} "")` does not export FOO.
I want to create an environmental variable FOO with empty value, and export it to control the behavior of a child process. But if FOO does not exist yet, set(ENV{FOO} "") does not export FOO to the environment for the child.
Suppose the following shell script `checkFOO` and cmake script `envtest.cmake` exist in the current directory:
```
#!/bin/sh
# filename: checkFOO
if env | grep -q FOO; then
echo "FOO exists"
else
echo "FOO not exists"
fi
```
```
# filename: envtest.cmake
set(ENV{FOO} "")
execute_process(COMMAND "./checkFOO")
```
Then running `cmake -P envtest.cmake` outputs "FOO not exists".
If `envtest.cmake` is replaced by
```
set(ENV{FOO} "fake value")
set(ENV{FOO} "")
execute_process(COMMAND "./checkFOO")
```
Then it outputs "FOO exists". Is this an intended behavior?https://gitlab.kitware.com/cmake/cmake/-/issues/22529Enable sccache for debug builds of CMake in gitlab CI2022-10-26T09:41:46-04:00alcroitoEnable sccache for debug builds of CMake in gitlab CII noticed that CMake's gitlab CI does not use sccache for RelWithDebInfo and Debug builds of CMake on Windows
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.1/.gitlab/os-windows.yml#L30
It's possible to enable sccache on those conf...I noticed that CMake's gitlab CI does not use sccache for RelWithDebInfo and Debug builds of CMake on Windows
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.1/.gitlab/os-windows.yml#L30
It's possible to enable sccache on those configs if you replace the `/Zi` flag with `/Z7`.
It has the downside of keeping the debug info in the object files, but for CI purposes it should be ok.
Thought i'd mention if you think it's worthwhile to enable it.
We do that in Qt's CI with our own custom function that replaces the `/Zi` flag in `CMAKE_C/CXX_COMPILER` in the top-
level directory scope.
https://github.com/qt/qtbase/blob/81411cb3a82b97fa80e4ba66b94797abe8d6ef7e/cmake/QtFlagHandlingHelpers.cmake#L951
@ben.boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/22473Document commands that are valid in TEST_INCLUDE_FILES2022-02-10T10:32:44-05:00Eric PedersonDocument commands that are valid in TEST_INCLUDE_FILESApparently not all CMake commands are valid in the context of a `TEST_INCLUDE_FILES` script, for example `get_test_property`. Sometimes you will get an error like "Unknown CMake command", sometimes a command will fail in other ways, for...Apparently not all CMake commands are valid in the context of a `TEST_INCLUDE_FILES` script, for example `get_test_property`. Sometimes you will get an error like "Unknown CMake command", sometimes a command will fail in other ways, for example, `set_property(TEST test APPEND PROPERTY LABELS labels)` fails with "set_property given TEST names that do not exist".
The documentation should indicate which commands are valid or invalid in a `TEST_INCLUDE_FILES` script.https://gitlab.kitware.com/cmake/cmake/-/issues/21605add_custom_target: DEPENDS takes union of all configurations2021-03-26T11:57:37-04:00matkaraadd_custom_target: DEPENDS takes union of all configurationsWhen using a conditional generator expression in the DEPENDS field of a custom target, both conditional branches are always taken.
Example:
```cmake
add_custom_command(OUTPUT ${OUTPUT_DEBUG} COMMAND ${COMMAND_DEBUG})
add_custom_command(...When using a conditional generator expression in the DEPENDS field of a custom target, both conditional branches are always taken.
Example:
```cmake
add_custom_command(OUTPUT ${OUTPUT_DEBUG} COMMAND ${COMMAND_DEBUG})
add_custom_command(OUTPUT ${OUTPUT_RELEASE} COMMAND ${COMMAND_RELEASE})
add_custom_target(target ALL
DEPENDS
$<IF:$<CONFIG:Debug>,${OUTPUT_DEBUG},${OUTPUT_RELEASE}>
)
```
Whenever `target` is built in debug, both `OUTPUT_RELEASE` and `OUTPUT_DEBUG` commands are triggered.
This also happens with the following reproducer:
```cmake
cmake_minimum_required(VERSION 3.19)
project(test)
add_custom_command(OUTPUT debug COMMAND cmake -E touch debug)
add_custom_command(OUTPUT release COMMAND cmake -E touch release)
add_custom_target(target ALL
DEPENDS
$<$<CONFIG:Release>:release>
$<$<CONFIG:Debug>:debug>
)
```
Output:
```
$ cmake --build . --config Release
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Checking Build System
Generating debug
Generating release
Building Custom Rule CMakeLists.txt
Building Custom Rule CMakeLists.txt
```https://gitlab.kitware.com/cmake/cmake/-/issues/21363file(COPY truncates timestamp on Linux, leading to erroneous behaviour2022-02-16T14:45:42-05:00dokempffile(COPY truncates timestamp on Linux, leading to erroneous behaviourProblem description:
On Linux, `file(COPY` sets the timestamp of the generated file to a truncation of the original file's timestamp with the precision being seconds. This means, that the copy is considered older than the original. In a...Problem description:
On Linux, `file(COPY` sets the timestamp of the generated file to a truncation of the original file's timestamp with the precision being seconds. This means, that the copy is considered older than the original. In a use case, where you copy the same file twice within one second, the policy of not copying if the timestamp has not changed leads to the second copy operation being no-op despite the source file having changed.
Minimum working example:
* Clone https://gitlab.dune-project.org/dominic/cmake-filecopy-bug
* run `./reproduce.sh`
* Observe how the time stamps differ and how the content of the two files differs after a second copy.
Most probable solution:
It seems that the handling of timestamps is still based on second-precision `utime` instead of milli- or nano-second precision `utimensat`.
Related issues:
* #19204 would be a remedy for the issue that disables the copy prevention in case of matching timestamps.
* #19335 is also requesting millisecond-precision timestamps, though for `string(TIMESTAMP`.
* #19852 has more timestamp-related issues that might be solved by a similar fixhttps://gitlab.kitware.com/cmake/cmake/-/issues/21253It is not possible to create a minimal .NET Core project with CMake2022-02-01T17:59:10-05:00Sam PIt is not possible to create a minimal .NET Core project with CMakeMy goal is to create a simple Hello World C# .NET Core project and generate the project with CMake. This does not appear to work.
My CMake is as follows
> project (mvp LANGUAGES CSharp)
>
> set ( CMAKE_DOTNET_TARGET_FRAMEWORK "netcore...My goal is to create a simple Hello World C# .NET Core project and generate the project with CMake. This does not appear to work.
My CMake is as follows
> project (mvp LANGUAGES CSharp)
>
> set ( CMAKE_DOTNET_TARGET_FRAMEWORK "netcore2.1")
>
> add_executable(mvp Program.cs)
This results in a .csproj and .sln file which VS 2017 and 2019 will open (and the .csproj does appear to have
` <TargetFramework>netcore2.1</TargetFramework> `
correctly set, but reports the following error and refuses to build.
> An error occurred trying to load the project properties window. Close the window and try again.
Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))https://gitlab.kitware.com/cmake/cmake/-/issues/21178COMMON_LANGUAGE_RUNTIME and related settings are ignored with non-VS generators2022-02-25T18:10:33-05:00AnyOldName3COMMON_LANGUAGE_RUNTIME and related settings are ignored with non-VS generatorsIf using this target property to set up CLR/CLI instead of manually specifying `/clr`, only the Visual Studio generators actually set the necessary compiler flags. As it's just a compiler flag for `cl.exe` which this property controls, r...If using this target property to set up CLR/CLI instead of manually specifying `/clr`, only the Visual Studio generators actually set the necessary compiler flags. As it's just a compiler flag for `cl.exe` which this property controls, rather than an MSBuild/Visual Studio-specific feature, it seems reasonable to set it with other generators when the compiler is MSVC, and spit out a warning/error with other compilers.
This *could* potentially be extended to more esoteric C++/CLI/.NET features, like `VS_PACKAGE_REFERENCES`, as 'all' that needs to do is get command-line Nuget to fetch the relevant packages to an equivalent location and pass the necessary flags to the compiler and linker to use them, which is approximately one extra command and a couple of extra arguments in a makefile/Ninja build file. Obviously that's going to be a lot more work than just setting compiler flags, though.
If other tools start supporting C++/CLI in the future (e.g. if Microsoft fork Clang or GCC in their quest to increase .NET usage on Unix) it'll make it easier to get that working if there's already groundwork for relevant options not to be VS-specific, too.https://gitlab.kitware.com/cmake/cmake/-/issues/20828CMake doesn't re-run custom command if set of DEPENDS changes2020-12-27T08:25:48-05:00Nehal J WaniCMake doesn't re-run custom command if set of DEPENDS changesConsider the following situation:
```bash
# Two input files
$ echo 1 > /tmp/input1
$ echo 2 > /tmp/input2
# A sample project for this query
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(query)
set(ext...Consider the following situation:
```bash
# Two input files
$ echo 1 > /tmp/input1
$ echo 2 > /tmp/input2
# A sample project for this query
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(query)
set(external_file /tmp/input1)
add_custom_command(
OUTPUT out
COMMAND echo hello > out
COMMENT "Running echo hello"
DEPENDS ${external_file}
VERBATIM)
add_custom_target(run DEPENDS out)
# Configure
$ cmake -S . -Bbuild -GNinja
...
-- Configuring done
-- Generating done
-- Build files have been written to: /spare/scratch/1592007425/build
# Build the target 'run'
$ cmake --build build/ -- run
[1/1] Running echo hello
# So far so good
$ cmake --build build/ -- run
ninja: no work to do.
# Now, let's modify the input for the `DEPENDS` in the argument from `/tmp/input1` to `/tmp/input2`:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(query)
set(external_file /tmp/input2)
add_custom_command(
OUTPUT out
COMMAND echo hello > out
COMMENT "Running echo hello"
DEPENDS ${external_file}
VERBATIM)
add_custom_target(run DEPENDS out)
# Now, try running the 'run' target. It doesn't say 'echo hello' :'(
$ cmake --build build/ -- run
[0/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: /spare/scratch/1592007425/build
ninja: no work to do.
```
I also tried: `set_source_files_properties(${external_file} PROPERTIES GENERATED TRUE)`, but it didn't make any difference.
Of course, in the above scenario, if I update the timestamp (mtime) of the input to be greater than the out file, run re-triggers the 'echo hello'.
My actual use case is as follows: I am using `add_custom_command()` for running a binary to generate some files (source-gen). I have multiple versions of this same binary already built (read only, can't modify them). I want to be able to switch to any of these to check how it impacts by project. Think of this as trying to run `protoc`, but wanting to regenerate the `.pb.h` and `.pb.cc` files whenever I want to use a different build of `protoc`.