71b65abc C++ feature checks: Filter out warnings caused by user flags
eb3abf8b C++ feature checks: Prepare for multiple check output filters
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1286
Fix remaining occurrences of the issue addressed in commit 5962db4389
(Use C++11 nullptr, 2017-08-22) that are only showing up on macOS.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
The opened XML elements were not closed, so an assert was triggered when the
file was finally closed. If CMake is built with assertions disabled then an
invalid XML file will be produced.
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>
Filter out `-Winvalid-command-line-argument` warnings from Clang (that
can be caused by user-specified flags) so that they do not break our
checks for C++ feature availability.
When we report that a compiler was unable to build a simple test
program, indent the output of the attempt so that our message formatting
will show it as a pre-formatted block.
e2cca9f8 FindGTest: Avoid macro name collision
4636c64b FindGTest: Improve test to catch link error
35061791 FindGTest: Fix shared linking on Windows
9fd9e448 FindGTest: Avoid using find_dependency in a find module
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1267
Instead of `list(FIND...)` and then checking result for `-1`
(found/not-found), nowadays `if` command has the `IN_LIST` test for
that.
This change was originally made by commit v3.9.0-rc1~41^2 (FindBoost:
Simplify search in lists, 2017-04-23) but then had to be reverted by
commit v3.9.2~3^2 (FindBoost: Revert "Simplify search in lists.",
2017-09-05) due to problems related to using `find_dependency`. Those
problems were addressed by commit 3080a0a611 (FindBoost: Improve
behavior when thread dependency is missing, 2017-09-15), so now we can
restore the original change.
Issue: #17252
Add special parsing of the flags given in `/MANIFESTUAC:"..."` in order
to map them correctly to `.vcxproj` elements.
Keep the old incorrect flag table entries for `uiAccess` and `level`
flags for compatibility even though they do not really exist.
Fixes: #16563
67529aab Doc: document that CoverageExtraFlags will come first
69fac3c3 pass arguments as vector to cmCTest::RunCommand()
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1261
bf1e606f FindMPI: Add support for FreeBSD and SLES
2f673da6 FindMPI: Support components for various languages
9a58e69c FindMPI: Modernization from ground up
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !893
714ce728 bootstrap: Make libuv available during bootstrap
6a2d967d bootstrap: Require compiler mode aware of C99 on Solaris
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1131
7200ab49 Tests: Fix CMake syntax warning in VSGNUFortran test
9da13bc3 Tests: Fix some references to 'cmake' executable
f1f109e9 Tests: Drop tests that have not run for over 10 years
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1270
Use two _'s for private function/macro names rather than one. This
avoids a potential collision if a function/macro with no leading _ that
otherwise matches the name of a private function/macro also overrides a
built-in function or is defined twice.
Add a reference to one of Google Test's command-line flags to the
FindGTest test. This will ensure that we are using the correct compile
definitions on Windows, as the test will otherwise fail to link. (IOW,
this tests the changes made by the previous commit.)
Add logic to FindGTest.cmake to attempt to determine if the libraries
are shared or static. If the libraries are shared, add an interface
compile definition that is needed in some cases for successful linking
on Windows.
See also https://github.com/google/googletest/issues/877.
Backport the changes from commit fa114e7d70 (FindBoost: Add Boost 1.65
dependencies, 2017-08-22) and commit dbba53a5aa (FindBoost: Add version
1.65.1, 2017-09-06) to CMake 3.9.
Fixes: #17289
An update from vim-cmake-syntax by commit v3.9.0-rc1~167^2^2
(vim-cmake-syntax 2017-05-02, 2017-05-02) brought in a change to set
`expandtab` in CMake language files. This should be a per-project or
per-user choice instead, so drop the setting.
On UNIX, build only the parts of libuv we need for the filesystem,
process, and poll abstractions using the POSIX poll() backend. This
avoids many platform-specific conditions. On Windows, build all of
libuv; there are no conditional alternatives anyway.
