CMake/Source/cmNinjaTypes.h

/* Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
   file Copyright.txt or https://cmake.org/licensing for details.  */
#ifndef cmNinjaTypes_h
#define cmNinjaTypes_h

#include "cmConfigure.h" // IWYU pragma: keep

#include <map>
#include <set>
#include <string>
#include <vector>

enum cmNinjaTargetDepends
{
  DependOnTargetArtifact,
  DependOnTargetOrdering
};

typedef std::vector<std::string> cmNinjaDeps;
typedef std::set<std::string> cmNinjaOuts;
typedef std::map<std::string, std::string> cmNinjaVars;

#endif // ! cmNinjaTypes_h
Simplify CMake per-source license notices Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle. 2016-09-27 19:01:08 +00:00			`/* Distributed under the OSI-approved BSD 3-Clause License. See accompanying`
			`file Copyright.txt or https://cmake.org/licensing for details. */`
Ninja: Add the Ninja generator 2011-11-11 05:00:49 +00:00			`#ifndef cmNinjaTypes_h`
Source: Stabilize include order Each source file has a logical first include file. Include it in an isolated block so that tools that sort includes do not move them. 2016-04-29 13:40:20 +00:00			`#define cmNinjaTypes_h`

Use quotes for non-system includes Automate with: git grep -l '#include <cm_' -- Source \ \| xargs sed -i 's/#include <\(cm_.\)>/#include "\1"/g' git grep -l '#include <cmsys/' -- Source \ \| xargs sed -i 's/#include <\(cmsys\/.\)>/#include "\1"/g' git grep -l '#include <cm[A-Z]' -- Source \ \| xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g' 2017-04-11 20:00:21 +00:00			`#include "cmConfigure.h" // IWYU pragma: keep`
make sure to include cmConfigure.h before cmStandardIncludes.h 2016-09-01 18:05:48 +00:00
Fix several include-what-you-use findings 2016-11-05 20:40:14 +00:00			`#include <map>`
Ninja: Improve performance with deeply-dependent custom targets 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> 2017-08-31 21:48:02 +00:00			`#include <set>`
Fix several include-what-you-use findings 2016-11-05 20:40:14 +00:00			`#include <string>`
			`#include <vector>`
Ninja: Add the Ninja generator 2011-11-11 05:00:49 +00:00
ninja: break unnecessary target dependencies 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 2017-04-17 20:24:44 +00:00			`enum cmNinjaTargetDepends`
			`{`
			`DependOnTargetArtifact,`
			`DependOnTargetOrdering`
			`};`

Ninja: Add the Ninja generator 2011-11-11 05:00:49 +00:00			`typedef std::vector<std::string> cmNinjaDeps;`
Ninja: Improve performance with deeply-dependent custom targets 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> 2017-08-31 21:48:02 +00:00			`typedef std::set<std::string> cmNinjaOuts;`
Ninja: Add the Ninja generator 2011-11-11 05:00:49 +00:00			`typedef std::map<std::string, std::string> cmNinjaVars;`

			`#endif // ! cmNinjaTypes_h`