In commit cfd8a5ac1f (Makefiles: Add support of DEPFILE for
add_custom_command, 2020-12-04, v3.20.0-rc1~237^2~1) we added a
`ConvertToOutputPath` call on a path given to the `depends` field of
`WriteMakeRule`. The latter already handles escaping for Makefile
syntax.
Fixes: #25554
Makefiles do not have a per-object sense of where they come from, so
forwarding any module information here would end up with incorrect
module file path construction by consuming targets. Leave a TODO item in
its place.
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
Now that scanning support is no longer experimental, the logic for
whether or not to scan C++ 20 sources is now important because all
projects are now exposted to the logic. Make the scanning rules explicit
in the documentation and rework the queries to localize all of the
associated logic.
A policy to handle the ultimate fallback logic will be implemented in a
following commit.
571b5e1f2c cxxmodules: improve error messages for C++ module setup
8b4d32c18b cmStandardLevelResolver: add query for the effective standard level
17ddc4ac76 cmStandardLevelResolver: compare with static string literals
6f1dae2b01 cmStandardLevelResolver: use `cmStrCat` where possible
0d45d40e13 cmStandardLevelResolver: use character literals where possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8755
This handles the case where `COLOR` is set to some ANSI-like color
sequence in the ambient environment. These sequences tend to include `;`
which terminates the command and tries to use the next component
(typically an integer, possibly with a trailing `m`) with errors like:
/bin/sh: line 1: 2: command not found
/bin/sh: line 1: 255: command not found
/bin/sh: line 1: 221: command not found
/bin/sh: line 1: 255m: command not found
Also add a test that sets `COLOR` in the environment which affects the
generated Makefiles behavior.
See: https://discourse.cmake.org/t/cmake-failing-gcc-compiler-checks/8277
The `SKIP_LINTING` source property was added to disable code check for
desired source files. The `SKIP_LINTING`includes `cpplint`, `clang-tidy`, \
`cppcheck` and `include-what-you-use`. If `SKIP_LINTING` is set on a
source file, the tools mentioned above will not be run on that source file.
De-duplicate code check rule generation in Ninja and Makefile generators
by moving their implementation to `cmCommonTargetGenerator`.
Previously Ninja was generating code check rules per language.
It was changed to generate code check rules for each source file.
These directories are used to direct collators for Fortran and C++
modules to consume dependent module information to properly collate.
However, the consumption of these files merely checks for existence of
the file, not whether they are actually needed anymore.
The problem arises when a target has Fortran or C++ modules at point A,
a build occurs populating this file, and then the target is updated to
no longer have potential modules. The `DependInfo.make` (for
`Makefiles`) or `<LANG>DependInfo.json` (for `Ninja`) files still exist
as they are never guaranteed to be cleaned up. This can introduce stale
information to the build which may cause a false-positive compilation if
a module file happens to still exist and gets found this way.
Instead, query the `linked-target-dirs` using the language in question
and only add the directory if it contains potential sources for modules
coming from the language in question.
Response files contained double-quote for any response file, but response files for wlink must contains single-quote. This is fix for libraries list response file. Problem for object file list was fixed by MR
!8115
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`).
07bc3b07ec gitlab-ci: test C++ modules using GCC
1b2270aa4e ci: add a Docker image to test out C++ modules with GCC
8c5a53096a Tests/RunCMake/CXXModules: add module-using examples
4151547e2f cmGlobalNinjaGenerator: use `cmModuleMapper` implementation
b43bdaff3c cmCxxModuleMapper: implement support for GCC's module map format
02d0f0e752 cmCxxModuleMapper: add source to handle module mapper contents
a046a45aad cmGlobalNinjaGenerator: add a TODO for header units
386465bf83 cmTarget: add support for C++ module fileset types
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7369
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
Since commit f3f57cc4ed (NMake: Use UTF-8 with BOM if supported by
nmake, 2021-04-22, v3.21.0-rc1~217^2), we add a BOM to response files
to tell MSVC tooling that they are encoded as UTF-8. However, the
"NMake Makefiles" generator may also be used with non-MSVC toolchains
that do not understand the BOM. Update the response file encoding
selection heuristic to add the BOM only with MSVC tooling.
Fixes: #23143
Since commit f3f57cc4ed (NMake: Use UTF-8 with BOM if supported by
nmake, 2021-04-22, v3.21.0-rc1~217^2) the encoding of response files is
selected based on the makefile encoding. In principle these may be
orthogonal, but in practice it is a useful heuristic. Call out this
heuristic in a comment, and leave a FIXME to do something better.
Brad King