| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Update experimental UUID for instrumentation after commit 4683db44a1
(instrumentation: Write index files to data/index/ subdirectory, 2025-09-19)
updated the location of index files.
|
| |
|
|
|
|
| |
Update experimental UUID for instrumentation after commit fbb5b47fbf
(instrumentation: Rename postTest and postInstall hooks, 2025-09-04)
broke old hook names.
|
| |
|
|
|
|
| |
Update experimental UUID for instrumentation after commit bf52fbfbc4
(instrumentation: Add Google trace output, 2025-08-28) introduced a
significant feature.
|
| |
|
|
|
|
| |
Update experimental UUID for instrumentation after commit afa94bae1e
(instrumentation: Rename queries field to options, 2025-07-08) broke compatibility
for old queries.
|
| |
|
|
| |
Now that `clang -stdlib=libstdc++` is supported.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
097d4fd1b5 instrumentation: Collect and record project build system metrics
8a3c195188 Tests/RunCMake: Add RunCMake_CHECK_ONLY Option
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !9791
|
| | |
| |
| |
| |
| |
| | |
Add a feature for collecting build instrumentation for CMake projects.
Issue: #26099
|
| |/
|
|
| |
Now that GCC is supported, update the feature UUID.
|
| |
|
|
|
|
|
| |
Update find_package documentation to describe (the current state of)
support for Common Package Specification packages. Make some general
improvements to the same while we're at it. Add documentation blurb for
the experimental flag that enables CPS support.
|
| |
|
|
|
| |
Given that the feature currently only supports C++ sources and is not
formally accepted by ISO yet, gate it behind a flag.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add initial support for exporting (install only, for now) Common Package
Specification (https://cps-org.github.io/cps/) format package
descriptions. This has some limitations, such as not supporting
generator expressions (as these cannot be portably exported), and only
partially supporting transitive dependencies, but should be usable for
at least some simple cases. (Actually, $<LINK_ONLY> is theoretically
supportable, but is not yet implemented.)
This still needs tests; these will be added in the next commit. Other
potential improvements include support for language-specific compile
definitions and inferring some package properties from project
properties. Additionally, there is no module support yet; this is partly
pending on having a tool agnostic format for providing the necessary
information.
|
| |
|
|
| |
Fixes: #25980
|
| | |
|
| |
|
|
|
|
|
| |
Some design concerns have been raised after trying the 3.29 release
candidates. Avoid committing to a stable public interface for now.
Issue: #25767
|
| |
|
|
|
|
|
| |
All the major compilers now have scheduled releases with support for
scanning, so remove the experimental gate.
Fixes: #18355
|
| |
|
|
| |
Supporting modules on IMPORTED targets is worth an update.
|
| |
|
|
|
| |
This will be required when dealing with imported targets which contain
modules.
|
| |
|
|
|
| |
This was missed in be53c75852 (cmExperimental: recycle the C++ modules
API UUID, 2023-07-21) from !8639.
|
| |
|
|
|
| |
The transitive support for Clang is a change in support for the
ecosystem.
|
| |
|
|
| |
It is now subsumed by the UUID setting completely.
|
| |
|
|
|
| |
Syntactic support for C++ header units has been removed, so a new UUID
is warranted.
|
| |
|
|
| |
LLVM/Clang 16.0 now contains official support for what CMake needs.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |/ |
|
| |
|
|
|
|
|
| |
Instead, just set the variables for how scanning works since that is
part of the compiler mechanisms.
Fixes: #24198
|
| | |
|
| |
|
|
| |
Visual Studio 17.4 now contains official support for what CMake needs.
|
| |
|
|
| |
This adds the `is-interface` key on provides fields.
|
| |
|
|
| |
The set of features available has been expanded, so update the UUID.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These fields are specified by our `P1689r3` paper, but are not actually
needed. The dependencies of the scanning results themselves can be
captured via normal depfile logic. Avoid saving this possibly-large
information in the scanning results. It is not needed by later steps.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optionally enable this infrastructure through an undocumented
`CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` variable. Currently this is
experimental and intended for use by compiler writers to implement their
scanning tools. Warn as such when the feature is activated. Later when
compilers provide the needed scanning tools we can enable this variable
from our corresponding compiler information modules. It is never meant
to be set by project code.
When enabled, generate a build graph similar to what we use for Fortran
module dependencies. There are some differences needed because we can
scan dependencies without explicit preprocessing, and can directly
compile the original source afterward.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
|
|
|
Initialize it with placeholder content. This document will serve to
contain documentation for experimental features that are under
development and not yet included in official documentation.
|