We may want to enable these variables later on with specific
semantics. To avoid breaking backwards compatibility, make it an
error to use them for now.
Prior to this fix, CMAKE_NMC_DEFAULT_CONFIGS would inherit "all" from
the union of CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG and
CMAKE_NMC_CROSS_CONFIGS. This is inconsistent with the behavior of the
"all" target signifying CMAKE_NMC_CROSS_CONFIGS. Update "all" in
CMAKE_NMC_DEFAULT_CONFIGS to inherit only from CMAKE_NMC_CROSS_CONFIGS.
Many users will want to use the Ninja Multi-Config generator like a
traditional Visual Studio-style multi-config generator, which doesn't
mix configurations - custom commands are built using target executables
of the same configuration the command is for. We do not want to force
these people to generate an N*N build matrix when they only need N*1,
especially if they have lots of targets. Add a new variable,
CMAKE_NINJA_CROSS_CONFIG_ENABLE, to opt-in to the cross-config build
matrix.
Resolve conflicts with changes since the 3.15 series:
* Convert `cmSystemTools::IsOn` => `cmIsOn`.
* Move one "EXCLUDE_FROM_ALL" target property logic fix to
its new location in `cmMakefile::AddNewUtilityTarget`.
The "all" target in each directory is supposed to have targets from that
directory even if the directory itself is marked `EXCLUDE_FROM_ALL` in
its parent. This was broken by commit dc6888573d (Pass EXCLUDE_FROM_ALL
from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) which made the
participation of a target in "all" independent of context. Revert much
of the logic change from that commit to restore the old behavior. Then
re-implement the behavior intended by the commit to keep its test
working. Extend the test to cover the old behavior too.
Fixes: #19753
Our dyndep support version 1 has been merged to upstream Ninja.
We never developed a second dyndep version, so simply drop our
checks for different versions.
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
Instead of passing multiple strings to the `WriteRule` and `AddRule` methods
of `cmGlobalNinjaGenerator`, pass only a `cmNinjaRule` instance reference,
that is set up beforehand.
Adapt calls to `WriteRule` and `AddRule` in multiple places.
Additional clean files for the Ninja generator can be registered
via the new method `cmGlobalNinjaGenerator::AddAdditionalCleanFile`.
If there are additional clean files, a new rule `CLEAN_ADDITIONAL` and
a new build target `CMakeFiles/clean.additional` get generated.
The `clean` target will depend on `CMakeFiles/clean.additional`, if the target
exists.
Provide a way for custom commands and targets to set the pool variable
of the ninja build statement. Setting `JOB_POOL` is not compatible with
`USES_TERMINAL`, which implies the `console` pool.
The option is silently ignored with other generators.
Closes: #18483
A convenience `clean` target for the Ninja generator exists since commit
3bd41f2eb5. It's safe to call `ninja clean` instead of `ninja -t clean`.
This removes the exception mapping of the `clean` target in
`cmake --build ... --target clean` calls to the Ninja `-t clean` tool.
Ninja 1.9 supports the multi-line depfile format generated by the
Intel Compiler for Windows. Teach the global generator to detect
when the version is new enough to support this.
This refactors a std::vector<std::string> into a class so that
we can extend the features to represent things such as multiple
chained commands in the future.
