GitLab

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 lin...

Detect from the version of Ninja whether it supports the dynamically
discovered dependencies (dyndep) feature needed to support Fortran.

Create an internal `cmake -E cmake_ninja_dyndep` tool to read the "ddi"
files generated by `cmake -E cmake_ninja_depends` from all sources in a
target and generate a ninja dyndep file that tells Ninja about Fortran
module dependencies within the target and on target dependencies.

Create an internal `cmake -E cmake_ninja_depends` tool to scan an
already-preprocessed Fortran translation unit for modules that it
provides or requires.  Save the information in a "ddi" file with a
CMake-private format for intermediate dynamic dependency information.
This file may the be loaded by another tool to be added later.

Kitware maintains a branch of Ninja with support for dynamically
discovered dependencies (dyndep) that has not yet been accepted
upstream.  Add an internal API to check whether the Ninja version in use
for the build supports this feature.

Check for features as soon as we know the ninja version.  Save the
results so we do not have to re-compare versions every time.

Delay rejection of Fortran until after we've determined the version of
the `ninja` tool to be used.  This will later allow us to enable Fortran
support based on the version of ninja.

While at it, make the rejection an immediate fatal error.  Also provide
a stack trace so readers know what code tried to enable Fortran.

Ninja 1.7 introduced support for implicit outputs on build statements.
Add an internal API to check whether the Ninja version in use for the
build supports this feature.

Ninja 1.7 introduced support for implicit outputs on build statements.
Teach WriteBuild to generate the corresponding syntax.  Leave it up to
callers to decide whether implicit outputs are supported by the Ninja
version in use.  For now simply update all call sites to pass an empty
list of implicit outputs.

Christoph Kulla authored Aug 05, 2016 and Brad King committed Aug 30, 2016

Provide a way for custom commands to inform the ninja build tool about
their implicit dependencies.  For now simply make use of the option an
error on other generators.

Closes: #15479

With the Makefile generator one can use `cd $subdir; make install` to build and
install targets associated with a given subdirectory.  This is not possible to
do with the Ninja generator since there is only one `build.ninja` file at the
top of the build tree.  However, we can approximate it by allowing one to run
`ninja $subdir/install` at the top of the tree to build the targets in the
corresponding subdirectory and install them.

This also makes sense for `test`, `package`, and other GLOBAL_TARGET targets.
It was already done for `all` by commit v3.6.0-rc1~240^2~2 (Ninja: Add
`$subdir/all` targets, 2016-03-11).

In cmGlobalNinjaGenerator::AppendTargetOutputs we previously
handled GLOBAL_TARGET outputs specially in order to avoid adding
directory components to the output.  However, this is not necessary
because cmNinjaTargetGenerator::New already filters out copies of
these targets that are not at the top level.  Instead we can simply
follow the same output computation code path as UTILITY targets.

The `CMAKE_<LANG>_SIMULATE_ID` variables are not set to "GNU" for a
GNU-like Clang compiler on Windows.  They are only set to "MSVC" for a
MSVC-like Clang.  Revise our response file format selection accordingly.
Reported-by: Chaoren Lin <chaorenl@google.com>

Custom command dependencies are followed for each target's source files
and add their transitive closure to the corresponding target.  This
means that when a custom command in one target has a dependency on a
custom command in another target, both will appear in the dependent
target's sources.  For the Makefile, VS IDE, and Xcode generators this
is not a problem because each target gets its own independent build
system that is evaluated in target dependency order.  By the time the
dependent target is built the custom command that belongs to one of its
dependencies will already have been brought up to date.

For the Ninja generator we need to generate a monolithic build system
covering all targets so we can have only one copy of a custom command.
This means that we need to reconcile the target-level ordering
dependencies from its appearance in multiple targets to include only the
least-dependent common set.  This is done by computing the set
intersection of the dependencies of all the targets containing a custom
command.  However, we previously included only the direct dependencies
so any target-level dependency not directly added to all targets into
which a custom command propagates was discarded.

Fix this by computing the transitive closure of dependencies for each
target and then intersecting those sets.  That will get the common set
of dependencies.  Also add a test to cover a case in which the
incorrectly dropped target ordering dependencies would fail.

Just because it is shorter.

Apply fixits of clang-tidy's readability-braces-around-statements
checker.

Daniel Pfeifer authored Jun 01, 2016 and Brad King committed Jun 02, 2016

Use clang-tidy's readability-simplify-boolean-expr checker.
After applying the fix-its, revise all changes *very* carefully.
Be aware of false positives and invalid changes.

Use clang-tidy's performance-unnecessary-copy-initialization checker.
After applying the fix-its (which turns the copies into const&), revise
the changes and see whether the copies can be removed entirely by using
the original instead.

Daniel Pfeifer authored May 19, 2016 and Brad King committed May 25, 2016

Mostly automated:

values=("RelativeRoot" "NONE" "FULL" "HOME" "START" "HOME_OUTPUT" "START_OUTPUT"
        "OutputFormat" "UNCHANGED" "MAKERULE" "SHELL" "WATCOMQUOTE" "RESPONSE"
        "FortranFormat" "FortranFormatNone" "FortranFormatFixed" "FortranFormatFree")
for i in "${values[@]}"; do git grep -l cmLocalGenerator::$i | xargs sed -i "s|cmLocalGenerator::$i|cmOutputConverter::$i|g"; done

Find uses of `cmSystemTools::ReplaceString` where both `replace` and
`with` are string literals with a size of one.

Automate with:

git grep -l ReplaceString | xargs sed -i "s|cmSystemTools::ReplaceString(\([^,]*\), \"\(.\)\", \"\(.\)\");|std::replace(\1.begin(), \1.end(), '\2', '\3');|g"
git grep -l ReplaceString | xargs sed -i "s|cmSystemTools::ReplaceString(\([^,]*\), \"\(.\)\", \"\\\\\\\\\");|std::replace(\1.begin(), \1.end(), '\2', '\\\\\\\\');|g"
git grep -l ReplaceString | xargs sed -i "s|cmSystemTools::ReplaceString(\([^,]*\), \"\\\\\\\\\", \"\(.\)\");|std::replace(\1.begin(), \1.end(), '\\\\\\\\', '\2');|g"

Nicolas Despres authored May 14, 2016 and Brad King committed May 17, 2016

Add a `CMAKE_NINJA_OUTPUT_PATH_PREFIX` variable.  When it is set, CMake
generates a `build.ninja` file suitable for embedding into another ninja
project potentially generated by an alien generator.

Nicolas Despres authored May 14, 2016 and Brad King committed May 17, 2016

This gives us a central location to revise paths.

In `AppendTargetOutputs` we generate a logical build target name for
each UTILITY command.  Simplify the logic to avoid testing the result
of `ConvertToNinjaPath`.

Kitware Robot authored May 16, 2016 and Brad King committed May 16, 2016

Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.

* 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.

Modern editors provide plenty of ways to visually separate functions.
Drop the explicit comments that previously served this purpose.
Use the following command to automate the change:

    $ git ls-files -z -- \
        "*.c" "*.cc" "*.cpp" "*.cxx" "*.h" "*.hh" "*.hpp" "*.hxx" |
      egrep -z -v "^Source/cmCommandArgumentLexer\." |
      egrep -z -v "^Source/cmCommandArgumentParser(\.y|\.cxx|Tokens\.h)" |
      egrep -z -v "^Source/cmDependsJavaLexer\." |
      egrep -z -v "^Source/cmDependsJavaParser(\.y|\.cxx|Tokens\.h)" |
      egrep -z -v "^Source/cmExprLexer\." |
      egrep -z -v "^Source/cmExprParser(\.y|\.cxx|Tokens\.h)" |
      egrep -z -v "^Source/cmFortranLexer\." |
      egrep -z -v "^Source/cmFortranParser(\.y|\.cxx|Tokens\.h)" |
      egrep -z -v "^Source/cmListFileLexer\." |
      egrep -z -v "^Source/cm_sha2" |
      egrep -z -v "^Source/(kwsys|CursesDialog/form)/" |
      egrep -z -v "^Utilities/(KW|cm).*/" |
      xargs -0 sed -i '/^\(\/\/---*\|\/\*---*\*\/\)$/ {d;}'

This avoids modifying third-party sources and generated sources.

The clang-format tool can do a good job formatting most code, but
well-organized streaming blocks are best left manually formatted.

Find blocks of the form

    os <<
      "...\n"
      "...\n"
      ;

using the command

    $ git ls-files -z -- Source |
      egrep -v -z '^Source/kwsys/' |
      xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \
        '<<[^\n]*\n(^ *("[^\n]*("|<<|;)$|;)\n){2,}'

Find blocks of the form

    os << "...\n"
       << "...\n"
       << "...\n";

using the command

    $ git ls-files -z -- Source |
      egrep -v -z '^Source/kwsys/' |
      xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \
        '<<[^\n]*\n(^ *<<[^\n]*(\\n"|<<|;)$\n){2,}'

Surround such blocks with the pair

    /* clang-format off */
    ...
    /* clang-format on */

in order to protect them from update by clang-format.  Use the C-style
`/*...*/` comments instead of C++-style `//...` comments in order to
prevent them from ever being swallowed by re-formatting of surrounding
comments.

Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first).  First
run `clang-format` with the config file:

    ---
    SortIncludes: false
    ...

Commit the result temporarily.  Then run `clang-format` again with:

    ---
    SortIncludes: true
    IncludeCategories:
      - Regex:    'sys/types.h'
        Priority: -1
    ...

Commit the result temporarily.  Start a new branch and cherry-pick the
second commit.  Manually resolve conflicts to preserve indentation of
re-ordered includes.  This cleans up the include ordering without
changing any other style.

Use the following command to run `clang-format`:

    $ git ls-files -z -- \
        '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
      egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
      egrep -z -v '^Source/cm_sha2' |
      egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
      egrep -z -v '...

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.

Dmitry Ivanov authored Apr 06, 2016 and Brad King committed Apr 07, 2016

Update the WriteBuild method to use a negative command line length limit
to specify that we should force use of response files.

Charles Huet authored Mar 11, 2016 and Brad King committed Mar 18, 2016

With the Makefile generator one can use `cd $subdir; make all` to build
all targets associated with a given subdirectory.  This is not possible
to do with the Ninja generator since there is only one `build.ninja`
file at the top of the build tree.  However, we can approximate it by
allowing one to run `ninja $subdir/all` at the top of the tree to build
the targets in the corresponding subdirectory.

Port logic from cmGlobalUnixMakefileGenerator3::WriteDirectoryRule2 to
cmGlobalNinjaGenerator in order to produce equivalent directory-level
targets.