Rewrite AppendTargetDependsClosure method to only cache local target
outputs, not including outputs from dependencies.
Caching all recursive target outputs causes much time to be spent
merging sets that have many elements in common (from targets that are
included through multiple dependency paths).
It is faster to always iterate over all dependencies instead.
Before, a documentation entry was in/out parameter.
Now it's a normal return value.
This also makes possible to eliminate defaulted default ctor
for `cmDocumentationEntry` for C++ 11.
Also, simplify `cmake::AppendGlobalGeneratorsDocumentation()`.
Also write for all configurations from multi-config generators.
This field was added in the Clang 5 documentation and not present in the
Clang 4 documentation (sometime between Dec 2016 and Mar 2017 according
to `web.archive.org`).
a12050666c Tests: Add case for ninja with non-ascii chars
02a04dd9c7 Ninja: Restore support for non-ascii paths on Windows with ninja<=1.10
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7833
Ninja treats every (normalized) path as its own node. It does not
recognize `/abs/path/to/file` in a depfile as matching `path/to/file`
even when `build.ninja` and the working directory are in `/abs/`.
See Ninja Issue 1251. In cases where we pass absolute paths to the
compiler, it will write a depfile containing absolute paths. If those
files are generated in the build tree by custom commands, `build.ninja`
references them by relative path in build statement outputs, so Ninja
does not hook up the dependency and rebuild the project correctly.
Add infrastructure to work around this problem by adding implicit
outputs to custom command build statements that reference the main
outputs by absolute path. Use a `${cmake_ninja_workdir}` placeholder
to avoid repeating the base path. For example:
build out.txt | ${cmake_ninja_workdir}out.txt: CUSTOM_COMMAND ...
Ninja will create two nodes for the output file, one with a relative
path and one with an absolute path. A depfile may then mention either
form of the path and Ninja will hook up the dependency. Unfortunately
Ninja will also stat the file twice.
Issue: #13894Fixes: #21865
Ninja 1.11 and later uses UTF-8 on Windows when possible, and
includes a tool that reports the code page in use. Use this tool
to determine what encoding to write the Ninja files in.
Fixes: #21866
39cbbb59a5 ninja: add experimental infrastructure to generate gcc-format modmap files
791b4d26d6 ninja: add experimental infrastructure to generate modmap files with dyndep
4b23359117 ninja: Add experimental infrastructure for C++20 module dependency scanning
f814d3b3c6 cmNinjaTargetGenerator: use $OBJ_FILE for the object
b0fc2993e1 Treat the '.mpp' file extension as C++ code
988f997100 cmScanDepFormat: Fix name of our internal tool in parse errors
dacd93a2db ninja: De-duplicate version numbers required for ninja features
533386ca29 cmStandardLevelResolver: Factor out helper to capture stoi exceptions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Acked-by: Shannon Booth <shannon.ml.booth@gmail.com>
Merge-request: !5562
The scan step may need to output additional information for the
compiler, not just the build tool. The modmap is assumed to be beside
the object output. Additional refactoring may open up a channel to
inform per-source paths to the dyndep rule in the future, but is not
done here.
Optionally enable this infrastructure through an undocumented
`CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` variable. Currently this is
experimental and intended for use by compiler writers to implement their
scanning tools. Warn as such when the feature is activated. Later when
compilers provide the needed scanning tools we can enable this variable
from our corresponding compiler information modules. It is never meant
to be set by project code.
When enabled, generate a build graph similar to what we use for Fortran
module dependencies. There are some differences needed because we can
scan dependencies without explicit preprocessing, and can directly
compile the original source afterward.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Remove the `cleandead` tool invocation added by commit fb18215904
(Ninja: clean ninja metadata once generated, 2019-05-13,
v3.17.0-rc1~207^2). The tool deletes files that were not previously
deleted by regenerating the build system. Also, there are use cases
where no-longer-generated files should not be removed, such as Qt's TS
files.
Fixes: #21549
73d1c78bf4 ci: update to use ninja 1.10.2
11f4259362 Ninja: Clean metadata after regen during build on Windows with 1.10.2+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5555
Ninja 1.10.2 fixes support for `generator = 1` rules that run metadata
update commands during regeneration while a build is running. Update
the condition added by commit ccaa0bccc4 (Ninja: Do not clean metadata
when re-generating inside a running build, 2020-01-27,
v3.17.0-rc1~73^2) to remove our workaround when Ninja is new enough.
Fixes: #20274
The Ninja `cleandead` tool does not account for implicit outputs
discovered by `dyndep` bindings and can remove Fortran `.mod` files that
are still needed. Disable the `cleandead` step when using `dyndep`
bindings.
Fixes: #21406
Early versions of the Ninja Multi-Config generator required
CMAKE_CONFIGURATION_TYPES and friends to be cache variables in order
to support selecting the default config in cmake(1) --build. The
behavior of cmake(1) --build has since been updated to no longer
require this, and requiring these variables to be cache variables is
inconsistent with the other generators.
Read the variables as normal CMake variables like the other generators.
This does not require a policy, since the only scenario where this would
cause a breakage is one where the cache variable and the CMake variable
are explicitly set to different values, which doesn't make sense to do
anyway.
#pragma once is a widely supported compiler pragma, even though it is
not part of the C++ standard. Many of the issues keeping #pragma once
from being standardized (distributed filesystems, build farms, hard
links, etc.) do not apply to CMake - it is easy to build CMake on a
single machine. CMake also does not install any header files which can
be consumed by other projects (though cmCPluginAPI.h has been
deliberately omitted from this conversion in case anyone is still using
it.) Finally, #pragma once has been required to build CMake since at
least August 2017 (7f29bbe6 enabled server mode unconditionally, which
had been using #pragma once since September 2016 (b13d3e0d)). The fact
that we now require C++11 filters out old compilers, and it is unlikely
that there is a compiler which supports C++11 but does not support
#pragma once.
We may want to enable these variables later on with specific
semantics. To avoid breaking backwards compatibility, make it an
error to use them for now.
Prior to this fix, CMAKE_NMC_DEFAULT_CONFIGS would inherit "all" from
the union of CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG and
CMAKE_NMC_CROSS_CONFIGS. This is inconsistent with the behavior of the
"all" target signifying CMAKE_NMC_CROSS_CONFIGS. Update "all" in
CMAKE_NMC_DEFAULT_CONFIGS to inherit only from CMAKE_NMC_CROSS_CONFIGS.
Ben Boeckel