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
When multiple source files in a single target have the same name, we
already set `ObjectFileName` explicitly to avoid a `.obj` collision. For
C++ module sources, set `Module{Output,Dependencies}File` to avoid
`.ifc` and `.module.json` collisions.
Fixes: #25038
The existing `export-interfaces-{build,install}` tests were actually
doing this, but make those test exporting the interfaces and copy the
existing tests to tests which explicitly test the "no properties"
condition.
The `CXX_SCAN_FOR_MODULES` property may be used to control scanning for
targets and for source files rather than assuming "C++20 always needs to
be scanned".
Not in the same executable (as that is IFNDR), but in the same project.
This tests to make sure that there's not some project-wide cache that
gets confused.
The build should fail. However, the error message is completely
generator-dependent as it is the build tool which (should) eventually
detect this case.
This includes a number of examples that should work for various levels
of support in a compiler.
There are a number of tests which are gated on various features in the
compilers. To enable the tests, set `CMake_TEST_MODULE_COMPILATION` to a
comma-separated (to avoid `;`-escaping problems) to the list of features
which are supported:
- `named`: Named modules are supported.
- `shared`: Shared libraries with module usage at the API boundary are
supported.
- `partitions`: Named module partitions are supported.
- `internal_partitions`: Named module internal partitions are
supported.
Additionally, a `CMake_TEST_MODULE_COMPILATION_RULES` file must be
passed which contains the rules for how to build modules using the
provided compiler. It will be included in the tests to provide these
rules. To verify that the file provided works as intended, it must set
`CMake_TEST_CXXModules_UUID` to a specific version to indicate that it
is an expected file.
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).
Ben Boeckel