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).
c5b56b35c2 cmInstallExportGenerator: expose the temporary directory
c107760417 cmNinjaTargetGenerator: support msvc-style deps discovery for scanning
64c15ec018 cmNinjaTargetGenerator: add flags for scanning based on the fileset type
aaa18f15cf cmTarget: add support for querying all file set names
cc4e19710d cmGlobalNinjaGenerator: use an extention based on the modmapfmt
97a68198c9 cmGlobalNinjaGenerator: escape `:` in module names
499009b79c cmTarget: avoid creating export entries if they don't exist
0513a1fe10 cmInstallGenerator: use CMake-private variables in generated code
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7214
Redefine the `CMAKE_CI_PACKAGE` pipeline schedule variable to
indicate whether it is for a development version (`dev`) or a
release version (`v[0-9]...`). Use this to automatically turn
package upload jobs on or off without having to edit the jobs
in `.gitlab-ci.yml` for release branches.
The previous wording could be misread as ensuring the arguments to the
call match the release version. Clarify that one needs to remove the
call and replace it with the literal release version string.
This helps to maximize the amount of information visible in the GitLab
web interface.
Also document their meaning in the developer documentation and in the CI
configuration file directly.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/8496
This makes `versionadded` and `versionchanged` directives show up in
`cmake --help-*` output instead of disappearing (and potentially making
empty sections).
Fixes: #22808
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.
This enables cross-reference syntax for CMake generator expressions:
:genex:`SOME_GENEX`
:genex:`$<SOME_GENEX>`
:genex:`$<SOME_GENEX:...>`
and definition of CMake generator expressions via a directive:
.. genex:: SOME_GENEX
.. genex:: $<SOME_GENEX>
.. genex:: $<SOME_GENEX:...>
It also adds generator expressions defined by the directive and by
`Help/genex/SOME_GENEX.rst` documents to the index.
This was accidentally left out of commit 8acf46caf1 (Utilities/Sphinx:
Add role and directive for 'envvar' in CMake domain, 2018-04-19,
v3.12.0-rc1~200^2~1).
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.
GitLab now uses a `/-/` component between the `group/project` part of
the URL and the `{issues,merge_requests,tree}` part so that it can
support `group/subgroup/project` with arbitrary depth.
Revert the change from commit 7b354baad5 (CMakeVersion: Set
CMake_VERSION_RC to 0 even in non-rc versions, 2019-07-25) and instead
define a `0` value in `CMake_VERSION_RC` to mean `-rc0`. This
distinguishes release branch versions prior to the first release
candidate from the first release candidate itself. It also makes room
for a dedicated "CMake $major.$minor.0-rc1" release commit for `-rc1` as
we have for later release candidates and final releases.
The logic that uses this value already ignores any "false" value, so `0`
is just as good as not being set at all. Using `0` for this role makes
the version components look more symmetric and reduces the number of
edits needed when creating releases.
