Previously CMake may generate incomplete transitive requirements in
CMakeFiles/<target>.dir/CXXModules.json and therefore in module mapper
for compiler, when source files were listed in CMakeList.txt in a
certain order.
This commit fixes the problem by correctly tracking unfinished
transitive requirements computation of module units.
There have been a simple circular test case whose circular dependency
was reported by build system. Now with this correct implementation it's
reported by CMake generating module mappers.
Add two test cases for transitive requirements computation, one with
adding source files in hardcoded order, and the other in randomized
order.
Fixes: #25465
This test previously did not *require* that the internal partition be
specified as a transitive usage because nothing from it was exposed.
Plumb through usages such that the internal partitions are required.
Tell users what generators *do* support C++ modules. Report the current
generator to make clear it is not one of those supporting modules.
Also clarify the purpose of the existing documentation references.
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.
When `clang-scan-deps` fails to scan (e.g., bad source syntax, junk
flags, etc.), the redirection unconditionally updates the file. If this
fails, the `.ddi` file timestamp is updated. If the state is then
reverted (e.g., the command line returns to the state of the last
successful build), the updated file is not useful, but `ninja` does not
rerun because:
- the command hash matches the last successful run
- the output file is newer than its inputs
However, since the `.ddi` file has been updated with bogus contents from
a failed scan, collation fails as the `rules` array is empty (or
incomplete from a batch scan).
If `clang-scan-deps` were properly aware of its output file, it could
use this to not write the file if any inner scan fails. Requested in
https://github.com/llvm/llvm-project/issues/72875.
See: https://github.com/llvm/llvm-project/issues/72875Fixes: #25429
This allows for a more graceful transition for projects using C++20
without scanner support (e.g., Clang 15 or GCC 13). While newer
compilers will (needlessly) scan, it allows C++20-using projects to use
older compilers without having to set `CMAKE_CXX_SCAN_FOR_MODULES` to
support newer CMake minimum versions.
Fixes: #25357
C++ module sources should not be included by any other TUs, so their
presence cannot matter for order-only dependencies of the entire target.
Exclude them.
Update CMP0154 to take this into consideration and add tests to the
`CXXModules` suite (which already deals with module support detection).
Under CMP0155's NEW behavior, projects that explicitly enable C++20
support with `set(CMAKE_CXX_STANDARD 20)` may also explicitly
disable scanning with `set(CMAKE_CXX_SCAN_FOR_MODULES OFF)`.
We already propagate `CMAKE_CXX_STANDARD` into `try_compile` test
projects, so propagate `CMAKE_CXX_SCAN_FOR_MODULES` too.
Fixes: #25313
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.
42654cc818 Tests/CXXModules: add tests for modules with include requirements
7217cb78cf Tests/CXXModules: relax line number matching in stderr
b3d1bbbbcc cmExportFileGenerator: relocate include directories for C++ modules
349ff8b080 cmGeneratorTarget: remove not-INTERFACE assertion
681a763425 cmGeneratorTarget: use a character literal
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8838
Previously an internal error was raised which ended up causing an
internal exception to be thrown. This is a typo situation that should
fall into an explicit error.
Fixes: #25207
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
When consuming exported targets which contain C++ modules, the consuming
project must be able to recompile BMI files using the original target's
flags. This is because a module source may use some private target usage
requirement but not want to propagate it to consumers. To facilitate
this, export the private information as necessary for consumers to be
able to perform the BMI compilations.
Brad King