When a target uses objects from another target which provides modules as
sources, the modules provided by the referenced target must also be
treated as if they were provided by the referencing target. Add the
concept of "forwarding" modules so that consumers can use modules
created by these sources as well.
Note that this is only sensible for Fortran where module usages are
implicit as far as CMake's visibility model is concerned. C++ modules
have their own concept of visibility which does not require or support
such `$<TARGET_OBJECTS>` reuse in this way.
This requires knowing when a generated header is public, which we can
model using file sets. Add policy CMP0154 to treat generated sources
as private by default in targets with file sets. Generated public
headers can be specified in public file sets.
Fixes: #24959
Issue: #15555
If the COMSPEC is set to an absolute path, use it instead of just
`cmd.exe`. This avoids searching for the tool in the current working
directory and the `PATH`. If COMSPEC is not set to an absolute path,
fall back to the existing behavior.
Issue: #18350
Since commit f3ca199c9b (cmGlobalNinjaGenerator: Factor out GNU-like
command-line detection on Windows, 2023-03-18, v3.26.1~2^2~6), we
accidentally "unrecognize" MinGW tools on Windows if a language other
than C or CXX is enabled. This causes the wrong slash style to be
generated in paths in `build.ninja`.
Fixes: #24642
1b7c26da49 Ninja: Wrap rules using '>' shell redirection with 'cmd /C' on Windows
ffd8537acf Clang: Record Clang 16.0 C++ modules flags only for GNU-like front-end
6013227230 cmGlobalNinjaGenerator: Use forward slashes in clang modmap format on Windows
d9d74b5e8a cmDyndepCollation: Drop outdated mentions of CXX_MODULE_INTERNAL_PARTITIONS
edab56d29a cmLocalNinjaGenerator: De-duplicate condition for using 'cmd /C' on Windows
8ebe3f92b3 cmGlobalNinjaGenerator: Detect GNU-like command-line for dyndep collator
f3ca199c9b cmGlobalNinjaGenerator: Factor out GNU-like command-line detection on Windows
f79817fcf0 cmCxxModuleMapper: Use value semantics in path conversion callback
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8346
Revert commit 1f16af01f4 (cmGlobalNinjaGenerator: Optimize target
depends closure, 2023-01-17, v3.26.0-rc1~74^2). It regressed generation
time for some projects. Revert it pending further investigation.
The `DisableCleandead` member was added by commit c5011399c5 (Ninja:
Avoid cleandead with dyndep bindings for Fortran module dependencies,
2020-11-10, v3.19.0~15^2) but has not been used since commit 1144d25094
(Merge branch 'backport-ninja-no-cleandead' into ninja-no-cleandead,
2020-12-14, v3.19.2~4^2). Remove it.
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>