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.
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
When a target is created it now inherits the EXCLUDE_FROM_ALL property
from its directory. This change makes it possible to include a target
in "all", even if its directory has been marked as EXCLUDE_FROM_ALL.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
While we already support `cmake --build . -- -j`, the options after `--`
are specific to the native build tool. Add new options `--parallel
[<N>]` and `-j [<N>]` to abstract this and map to the proper option
for the native build tool.
Calls to this method may dominate generation time in some cases.
Measurements for configuring cmake itself show a cache hit rate of ~57%
(7753 total calls, 4453 cache hits). For a larger project (that also
makes use of custom targets as prerequisite for all compile targets),
the measured cache hit ratio is ~96% (2530827 total calls, 2433124 cache
hits). For this project the observable cmake runtime could be reduced
from 40s to 30s.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
The commit v3.7.0-rc1~339^2 (Ninja: Fix inter-target order-only
dependencies of custom command, 2016-07-20) might cause performance
degradations for larger projects. Especially when using custom
commands as an input for each compilation rule (e.g. generated headers).
For reference in the following I am referring to
Source/cmGlobalNinjaGenerator.cxx:
-> cmGlobalNinjaGenerator::AppendTargetDependsClosure
-> cmGlobalNinjaGenerator::ComputeTargetDependsClosure
It turned out that the mentioned commit is doing (indirectly) some
redundant work that might impact performance when generating large
projects.
Imagine the dependency tree of custom targets:
A
\
C - D - E
/
B
For each target the transitive closure is calculated recursively, but as
the TargetDependsClosures are only cached on the top most level, everything
downstream has to be recalculated. I.e.
A->C->D->E
B->C->D->E
This ultimately leads to a lot of redundant calls to AppendTargetOutputs.
The recursive nature of the algorithm itself is not significant to the
problem, but reducing the work to actually to be done work, eliminates the
performance problem.
This patch changes the way, intermediate results are cached. Rather than
caching the closure of targets, we cache the closure of outputs. Such that
in the example above at B->C the cache already would kick in.
Caching the outputs has one disadvantage that the patch takes care of.
In case of such a structure
A E
\ / \
C - D G
/ \ /
B F
the calling order for A would be
A->C->D->E->G (at which time G is seen to the recursion)
then the recursion returns until it reaches
A->C->D->F (at which the seen G would prevent to recurse down to G)
But this would poison the cache for F with a wrong value (without G).
Hence we use a local result set to ensure the cache is still consistently
populated.
For a large C++ project with around 25k targets this reduced the CMake
configure / generate time from ~40s to ~29s.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
We now require C++11 support including `override`. Drop use of
the old compatibility macro. Convert references as follows:
git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' |
xargs sed -i 's/CM_OVERRIDE/override/g'
Previously, given two libraries, X and Y where X depends on Y, all
object compilations of X would require the Y library to have been linked
before being compiled. This is not necessary and can instead be loosened
such that object compilations of X only depend on the order-only
dependencies of Y to be completed. This is to ensure that generated
sources, headers, custom commands, etc. are completed before X starts to
compile its objects.
This should help build performance in projects with many libraries which
cause a deep library dependency chain. Previously, a library at the
bottom would not start compilation until after all other libraries
completed, but now only its link step needs to wait and its compilation
jobs can be run in parallel with other tasks.
Fixes: #15555
Marc Chevrier