Command line argument passed to the internal tool "cmake_ninja_dyndep"
could hit MAX_ARG_STRLEN on Linux for projects with a large code base.
To prevent such problems, a response file was opted for argument transfer
in all cases, not only on Windows.
Add a `CUDA_COMPILER_LAUNCHER` target property like those added for C
and CXX by commit v3.4.0-rc1~450^2 (Add options to launch the compiler
through tools like ccache or distcc, 2015-06-04).
Fixes: #16953
The internal tool "cmake_ninja_depends" now supports reading the list of ddi
files from a reponse file to circumvent Windows command line length limits.
Use this response file for dyndep rule on Windows.
d96e5d9a Tests: use BYPRODUCTS in the CustomCommandWorkingDirectory test
664591ce RunCMake.Ninja: add a test for assumed sources
adf60b28 ninja: break unnecessary target dependencies
01c5bb95 RunCMake.Ninja: support passing arguments when running ninja
7f947b60 ninja: remove duplicate order-only dependencies
e9827eba ninja: describe the intermediate order depends target better
b57b7d8e Ninja: Order Fortran dyndep file generation explicitly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !430
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
Each target's dyndep file generation depends on loading information
generated by the same step in its dependencies. Add an explicit
ordering dependency to ensure the needed information is available.
Without the explicit ordering dependency we were abusing the more
general target ordering rules through the preprocessor rules generating
the `.ddi` files used as input to dyndep file generation.
Work around upstream ninja issue 1251 by converting include directories
used by our Fortran dependency scanner to the same path format that we
use in preprocessor `-I` flags and in the `build.ninja` manifest.
Fixes: #16722
The `WINDOWS_EXPORT_ALL_SYMBOLS` target property exports all symbols
found in object files explicitly given to the linker. However, the
linker may also find additional symbols in dependencies and copy them
into the linked binary (e.g. from `msvcrt.lib`). Provide a way to
export an explicit list of such symbols by adding a `.def` file as a
source file.
Fixes: #16473
Use `cmGeneratorTarget::ModuleDefinitionInfo` to combine the
implementation of `WINDOWS_EXPORT_ALL_SYMBOLS` with that of using a
`.def` file as a source. Only one of these could be used within a
single target before anyway.
Create a `ModuleDefinitionInfo` structure for each configuration of a
target to hold corresponding information about the selected module
definition file (`.def` source).
This reverts commit v3.7.0-rc1~275^2 (Ninja: Use full path for all
source files, 2016-08-05). Unfortunately using absolute paths can
cause incorrect rebuilds due to ninja limitations. The ninja
manual [1] explains:
> ... using absolute paths, your depfile may result in a mixture of
> relative and absolute paths. Paths used by other build rules need
> to match exactly.
Passing an absolute path to a source file to the compiler while using a
relative path in the ninja build manifest can cause such mixture and
lead to incorrect rebuilds. Simply revert the change for now.
Note that there was a follow-up to the original change in commit
v3.7.0-rc2~10^2 (Ninja: Fix RC language depfile generation with
cmcldeps, 2016-10-13). We don't need to revert that because that
change made the relevant code cleverly adapt to whatever variable
we use to reference the source file.
[1] https://ninja-build.org/manual.html#_depsFixes: #16675
Issue: #13894
Create a `<LANG>_CPPLINT` target property (initialized by a
`CMAKE_<LANG>_CPPLINT` variable) to specify a `cpplint` style checker
command line to be run along with the compiler.
Call sites of `ExpandRuleVariables` are now responsible for inserting
the `RULE_LAUNCH_{COMPILE,LINK,CUSTOM}` values in rule command lines.
Audit all call sites and add a comment to each one that does not insert
a launcher to explain why.
Change the default compile PDB file name for static libraries to match
the Visual Studio default of using the logical target name. This may be
incompatible with existing behavior but `COMPILE_PDB_NAME` documents
that the default is unspecified. Projects depending on a particular
name should set the property.
Closes: #16438
This allows users to specify different genex-based compile flags for
each file in a target, e.g. compiling just a single file with `Od/Ox` in
release builds on Visual Studio.
Add a factory function to cmLocalGenerator so that variableMappings can
be provided from it, and so that Ninja can always have a hard-coded
TargetImpLib.
The rule replacement API should not really be in cmLocalGenerator, but
it was historically, and this coupled many other things together here
too, such as output conversion. Make the output converter a parameter
so that rule replacement can be removed from cmLocalGenerator.
This one is not like the others as it doesn't participate in
substitutions. Keep ExpandRuleVariables doing only one thing and make
callers responsible for inserting a launcher prefix, simplifying the
code all-around.
Remove now-obsolete InsertRuleLauncher method.
In commit v3.7.0-rc1~275^2 (Ninja: Use full path for all source files,
2016-08-05), the source path was changed to use an absolute path.
Inside of `cmcldeps` for `.rc` file compilation, it uses a separate
argument for the path to the source file. This ended up causing
`cmcldeps` to transform the following call:
cmcldeps.exe RC source.rc ... C:/full/path/to/source.rc
into:
... C:/full/path/to//Tc source.rc
which is invalid. Update the source filename to use the full path to
the source file so that the path is replaced properly.
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.
Fortran INCLUDE statements are not handled by the preprocessor.
Since the location of the preprocessed file is distinct from the
original source file explicitly add the source file's directory
as an include path in the actual compile step (not the preprocessing step)
so INCLUDE can find it.
Closes: #16332
All Fortran sources need to be preprocessed before any source may be
compiled so that module dependencies can be (later) extracted. Factor
out an explicit preprocessing step preceding compilation. Use Ninja
depfile dependencies on the preprocessing step and then compile the
already-preprocessed source with a separate build statement that depends
explicitly only on the preprocessor output. Later we will insert
dynamic discovery of module dependencies between these steps.
