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.
Our practice of closing MRs temporarily while discussion
takes place in a separate issue isn't always well understood
by MR authors. Expiring a MR seems to be better understood,
but making it clear that it is also a temporary state is helpful.
The logic is that the describe output is readily available using `git
tag --contains` locally. In addition, for a hypothetical commit which
landed in both v3.9.4 and v3.10.1, there is no "better" tag to refer to.
since v3.10.0's relation to such a commit is unclear either way.
Also mention that a `Fixes` trailer is preferred if the mention is just
to indicate a commit which introduced an error rather than writing a
complete sentence about it.
Remove this content from the `cmake-developer(7)` manual because it
is relevant only to developers working on CMake itself. Move it to
a guide in the developer documentation.
The Maintain Current Release instructions previously assumed that
the topic branch had been merged to master. Add text to make this
explicit in the instructions as an initial verification step.
The previous instructions also made no mention of the commit
message for the merge to the release branch. This needs to include
a footer that mentions the merge request number for tracking
purposes.
