| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Add a test case for C++ `OBJECT` libraries providing modules to
consumers.
|
|
|
|
| |
Fixes: #24618
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
It is now subsumed by the UUID setting completely.
|
|
|
|
|
| |
Syntactic support for C++ header units has been removed, so a new UUID
is warranted.
|
|
|
|
|
| |
There's no backing implementation for header units anyways, so just
remove it for now.
|
|
|
|
|
|
|
|
| |
When generating the `IMPORTED_CXX_MODULES_[CONFIG]` target property,
there was a missing path separator after a non-empty relative directory
part of the path to a module source file.
Co-authored-by: Brad King <brad.king@kitware.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling `install(EXPORT)` with the `CXX_MODULES_DIRECTORY` parameter
leads to installation rules being generated which `include()` CMake
scripts that set the `IMPORTED_CXX_MODULES_[CONFIG]` target property for
relevant targets. However, these scripts don't get generated for
targets in an export set which don't have any C++20 modules. When the
installation rules attempt to `include()` the missing scripts, the
install fails.
Co-authored-by: Brad King <brad.king@kitware.com>
|
| |
|
|
|
|
| |
Adapted from the example in issue #24652 by Ivan Garramona.
|
|
|
|
| |
It is not part of any module, so it needs to be declared as such.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
See: https://gitlab.kitware.com/cmake/cmake/-/issues/18355#note_1296721
See: https://github.com/ninja-build/ninja/pull/1937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 15.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Fixes: #24315
|
|
|
|
|
|
|
|
|
|
| |
These patches now support the `-MF` output, so remove the `none` support
added just for the old patchset which did not use it.
Also update the flag name to `-fmodule-output=`.
Due to the new Clang module mapper flag, use a new experimental support
UUID as well.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2c558cfd1b gitlab-ci: add CI jobs for Clang with C++20 modules
abd42e9cfc ci: add a Docker container for clang support of C++20 modules
51093f3002 Clang-FindBinUtils: also find `clang-scan-deps`
0b333de923 ci: add C++ module rules file for Clang
21b9fb1e8c cmCxxModuleMapper: support the `clang` module map format
9c66224668 cmNinjaTargetGenerator: skip setting `depfile` for `none` scantypes
9123a0991f cmNinjaTargetGenerator: use `.clear()` to empty out some strings
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Cristian Adam <cristian.adam@gmail.com>
Merge-request: !7978
|
| | |
|
| |
| |
| |
| | |
Visual Studio support warrants a new ID.
|
| | |
|
| |
| |
| |
| |
| | |
Visual Studio does not currently have a place to insert the logic
required to implement this test, so skip it if possible.
|
| |
| |
| |
| | |
This keeps the condition to a readable limit.
|
| | |
|
| | |
|
|/
|
|
|
| |
In Visual Studio, there is no mechanism to tell scanning apart from
non-scanning, so skip the sanity checks.
|
|
|
|
|
|
| |
Now that `Ninja` generators will know to generate rules for `IMPORTED`
targets, mark these as `INTERFACE` to avoid requirements of actual
artifacts.
|
|
|
|
|
|
| |
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".
|
|\
| |
| |
| |
| |
| |
| |
| | |
0e9782b336 msvc: bless MSVC 19.34 support for C++ modules as experimental
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7745
|
| |
| |
| |
| | |
Visual Studio 17.4 now contains official support for what CMake needs.
|
| |
| |
| |
| |
| |
| | |
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 tests that transitive usages are propogated properly across long
import chains between targets.
|
| |
|
|
|
|
| |
Apparently GCC accepts the ill-formed prior syntax.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The collator will use this to know where the target's export information
needs to go so that module properties may be provided.
|
|
|
|
|
| |
The collator will use this to generate property settings for the
imported targets in the build and install export sets.
|
| |
|
|
|
|
| |
The set of features available has been expanded, so update the UUID.
|
|
|
|
|
| |
C++ module properties will be generated at build time, so generate code
that includes the files actually responsible for the information.
|
| |
|
|
|
|
|
| |
`PUBLIC` filesets become `INTERFACE` upon installation. Allow
`INTERFACE` scopes for C++ modules when the target is imported.
|
|
|
|
|
|
|
|
|
|
| |
Compile features ensure a compiler is aware of a standard version, but the one
actually used may be newer. The test relies on the standard chosen being
pre-C++20, so force C++17 explicitly.
This was exposed by a nightly bot that has a compiler defaulting to C++23. The
test would've broken anyway in a few years once GCC or Clang upped their
default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|