Add a role that can be used to create local links (a la '`LINK`_'), but
that also applies literal style. This is particularly useful for
referring to subcommands within the command's documentation in a style
that is consistent with ':command:`BAR <foo(BAR)>`' but is much less
verbose.
Although this is intended for subcommands, it works with any local
reference.
Co-authored-by: Brad King <brad.king@kitware.com>
Split the genex directive into its own class, allowing a slight
simplification of CMakeObject. Add ability to specify an explicit target
name for the same.
Use this to provide a target for the `$<TARGET_PROPERTY:prop>` generator
expression which is otherwise missing one (due to overlap with
`$<TARGET_PROPERTY:tgt,prop>`). With this one can write:
:genex:`$<TARGET_PROPERTY:prop> <TARGET_PROPERTY:prop>`
to link the second variant.
Fixes: #24573
Implement logic to support several styles of parsing in the new
signature directive that control where line breaks are allowed in a
signature.
The default is 'smart', which forbids breaks inside of square- or
angle-brackets. The 'verbatim' option forbids all breaks. In all cases,
breaks are always allowed where a newline appears in the source.
This seems to Just Work for most writers, but HTML needs some special
handling that is accomplished by a new CSS rule and assigning the 'nbsp'
class to spaces that are not allowed to break. (ROFF's line wrapping is
rather unfortunate here, as it prefers splitting and hyphenating words
rather than breaking at a space.)
Add signatures to the collection of observed objects (which can be
referenced elsewhere). Don't automatically strip parameters from a
:command: reference, as these may now link signatures. (Do, however,
munge them into 'text <ref>' form if they aren't already, as not doing
so adds an extra '()' for some reason.) Correspondingly, change xref
resolution to try to match 'command' when a ref like 'command(args)' is
not matched, so that existing links to commands that have not been
converted to use the new signature directive don't immediately break.
Add a `signature` directive to offer a CMake version of Sphinx's
`function` directive, similar to that found in other domains (py, cpp,
etc.). Like others, this takes one or more signatures as arguments and
creates dt/dd nodes from the signatures and the directive contents.
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
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.
