When running the module dependencies scan tool for for a language that
does not compile the preprocessed output, we do not actually put the
preprocessed output in the build graph. However, the value of
`CMAKE_EXPERIMENTAL_<LANG>_SCANDEP_SOURCE` may reference the placeholder
for the preprocessed source. Populate the placeholder to keep the file
out of the way. In particular, do not clobber the `.ddi` file.
Since commit 33a8e0bb09 (cmNinjaTargetGenerator: Simplify scan rule
depfile selection, 2020-11-06, v3.20.0-rc1~516^2~1), the `$out` of the
scan rule always matches our `.rsp` file selection, so use `$out.rsp`.
The Ninja generator traditionally referenced source files and include
directories using paths relative to the build directory if they could be
expressed without a `../` sequence that leaves the build and source
directories. For example, when using a `build/` directory inside the
source tree, sources would be compiled as `-c ../src.c` and include
directories would be referenced as `-I ../include`. This approach
matches the traditional Ninja convention of using relative paths
whenever possible, but has undesirable side effects such as:
* Compiler diagnostic messages may not use absolute paths, making it
harder for IDEs/editors to find the referenced sources or headers.
* Debug symbols may not use absolute paths, making it harder for
debuggers to find the referenced sources or headers.
* Different results depending on the path to the build tree relative
to the source tree.
* Inconsistent with the Makefile generators, which use absolute paths.
Switch to always using absolute paths to reference source files and
include directories on compiler command lines. While alternative
solutions for diagnostic messages and debug symbols may exist with
specific tooling, this is the simplest and most consistent approach.
Note that a previous attempt to do this in commit 955c2a630a (Ninja: Use
full path for all source files, 2016-08-05, v3.7.0-rc1~275^2) was
reverted by commit 666ad1df2d (Revert "Ninja: Use full path for all
source files", 2017-02-24, v3.8.0-rc2~9^2) due to problems hooking up
depfile dependencies on generated files. This time, the changes in
commit 2725ecff38 (Ninja: Handle depfiles with absolute paths to
generated files, 2021-05-19) should avoid those problems.
Fixes: #13894, #17450
The `GetSourceFilePath` method is meant only for compiled sources, and
automatically handles converting it to a path for the Ninja build
manifest. Rename the method to clarify both.
These fields are specified by our `P1689r3` paper, but are not actually
needed. The dependencies of the scanning results themselves can be
captured via normal depfile logic. Avoid saving this possibly-large
information in the scanning results. It is not needed by later steps.
Make the `config` argument non-optional so all callers must be explicit.
Convert the path style argument to an enumeration to make its role clear
at call sites.
The path style argument is implemented by `ConvertToIncludeReference`,
which was introduced with the Ninja generator by commit 5b114c9bee
(Introduce a cmLocalGenerator::ConvertToIncludeReference function,
2011-09-07, v2.8.7~187^2~4). Its only purpose is to allow the Ninja
generator to use relative paths in `-I` flags. Add a comment explaining
this role.
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 new target property `EXPORT_COMPILE_COMMANDS` associated with the
existing global variable can be used to optionally configure targets for
their compile commands to be exported.
Fixes: #19462
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>
The target property `ISPC_HEADER_SUFFIX` and associated global
variable now can control the suffix used when generating the
C/C++ interoperability ISPC headers.
In addition the default suffix is now "_ispc.h" which matches the
common convention that the ISPC compiler team uses and recommends.
48aac247e9 Compile with explicit language flag when source LANGUAGE property is set
2e67a75acd Embarcadero: Simplify addition of -P flag for C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5522
This change was originally made by commit 74b1c9fc8e (Explicitly specify
language flag when source LANGUAGE property is set, 2020-06-01,
v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert
"specify language flag when source LANGUAGE property is set",
2020-11-19) to restore compatibility with pre-3.19 behavior.
Implement the change again, but add policy CMP0119 to make this change
while preserving compatibility with existing projects.
Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to
specify `-TP` for their MSVC-like variants because we already use the
flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX`
and `Platform/Windows-Embarcadero`.
Note also that this does not seem possible to implement for XL C.
Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix:
`1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`.
It returns non-zero even with `-qsuppress=1501-218`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Fixes: #14516, #20716
These changes are in preparation of compiler generated dependencies support
for Makefiles generators
* compiler output and dependency target can be different for Makefiles generators
* resolve inconsistency naming for dependency file place-holder
Revert commit 74b1c9fc8e (Explicitly specify language flag when source
LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup
tables from its two immediate ancestors. The purpose of that change was
to convert an explicit `LANGUAGE` source file property into an explicit
language specification compiler flag like `-x c`. This seems reasonable
since the property is documented as meaning "indicate what programming
language the source file is". It is also needed to help compilers deal
with non-standard source file extensions they don't recognize.
However, some projects have been setting `LANGUAGE C` on `.S` assembler
source files to mean "use the C compiler". Passing `-x c` for them
breaks the build because the `.S` sources are not written in C. These
projects should be updated to use `enable_language(ASM)`, for which
CMake often chooses the C compiler as the assembler when using
toolchains that support it (which would have to be the case for projects
using the approach).
Revert the change for now to preserve the old behavior for such projects.
We can re-introduce it with a policy in a future version of CMake.
Fixes: #21469
Issue: #14516, #20716
All the scan-related code paths are actually about dyndep rather than
explicit preprocessing. It just happens that the implementation for
Fortran requires explicit preprocessing.
For NVCC the compiler takes care of device linking when passed the "-dlink"
flag.
Clang doesn't support such magic and requires the buildsystem to do the work
that NVCC does behind the scenes.
The implementation is based on Bazel's device linking documentation:
7cabcdf073/third_party/nccl/build_defs.bzl.tpl (L259)Closes: #20726
5ece12b7e4 gitlab-ci: add ISPC to the Fedora CI image
8976817d6d ISPC: Update help documentation to include ISPC
2368f46ba4 ISPC: Support building with the MSVC toolchain
e783bf8aa6 ISPC: Support ISPC header generation byproducts and parallel builds
34cc6acc81 Add ISPC compiler support to CMake
419d70d490 Refactor some swift only logic to be re-used by other languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5065
