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.
Add link flags during the "device compile" step.
Enabled the relevant tests. The disable reasons regarding separable compilation
were outdated and the actual failure case was device link flags support.
The target properties `CUDA_SEPARABLE_COMPILATION` and `CUDA_PTX_COMPILATION`
now aren't mutually exclusive and can now be used together on the same
target.
Move the logic for appending cubin afterwards, so the check can simply be
empty().
With the Makefile generator the option is now at the front instead of being
intermixed with the actual bins.
Seems the relative paths were wrong basically all around such that only
compiling files in the top-level directory would work. I've modified
CudaOnly.SeparateCompilation to cover this.
Fixes#22482.
Extend the fix from commit 67e2130c96 (Makefiles: Fix
CMAKE_EXPORT_COMPILE_COMMANDS crash with custom compile rule,
2020-11-20, v3.19.1~8^2) to work for the `<FLAGS>` placeholder too.
Also fix the test case to actually enable `EXPORT_COMPILE_COMMANDS`
on the test target.
Fixes: #22261
Most calls to `MaybeConvertToRelativePath` use one of our common work
directories (e.g. top of the build tree) as the local path. Add helpers
for each of the common cases to simplify and clarify call sites.
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.
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
