Help: Fix typos found by the rst-backticks
hook
The corresponding `pre-commit` configuration is coming in the separate MR. Signed-off-by: Alex Turbov <i.zaufi@gmail.com>
This commit is contained in:
parent
c833629508
commit
bc4c71627a
@ -102,7 +102,7 @@ The options are:
|
||||
``COMMAND``
|
||||
Specify the command-line(s) to execute at build time.
|
||||
At least one ``COMMAND`` would normally be given, but certain patterns
|
||||
may omit it, such as adding commands in separate calls using `APPEND`.
|
||||
may omit it, such as adding commands in separate calls using ``APPEND``.
|
||||
|
||||
If more than one ``COMMAND`` is specified, they will be executed in order,
|
||||
but *not* necessarily composed into a stateful shell or batch script.
|
||||
|
@ -149,7 +149,7 @@ Existence Checks
|
||||
does not matter. Note the following caveats:
|
||||
|
||||
* Macro arguments are not variables.
|
||||
* It is not possible to test directly whether a `<name>` is a non-cache
|
||||
* It is not possible to test directly whether a ``<name>`` is a non-cache
|
||||
variable. The expression ``if(DEFINED someName)`` will evaluate to true
|
||||
if either a cache or non-cache variable ``someName`` exists. In
|
||||
comparison, the expression ``if(DEFINED CACHE{someName})`` will only
|
||||
|
@ -134,8 +134,8 @@ For more information on regular expressions look under
|
||||
list(INSERT <list> <element_index> <element> [<element> ...])
|
||||
|
||||
Inserts elements to the list to the specified index. It is an
|
||||
error to specify an out-of-range index. Valid indexes are 0 to `N`
|
||||
where `N` is the length of the list, inclusive. An empty list
|
||||
error to specify an out-of-range index. Valid indexes are *0* to *N*
|
||||
where *N* is the length of the list, inclusive. An empty list
|
||||
has length 0. If no variable named ``<list>`` exists in the
|
||||
current scope its value is treated as empty and the elements are
|
||||
inserted in that empty list.
|
||||
@ -146,8 +146,8 @@ For more information on regular expressions look under
|
||||
.. versionadded:: 3.15
|
||||
|
||||
If no variable name is given, removes exactly one element. Otherwise,
|
||||
with `N` variable names provided, assign the last `N` elements' values
|
||||
to the given variables and then remove the last `N` values from
|
||||
with *N* variable names provided, assign the last *N* elements' values
|
||||
to the given variables and then remove the last *N* values from
|
||||
``<list>``.
|
||||
|
||||
.. signature::
|
||||
@ -156,8 +156,8 @@ For more information on regular expressions look under
|
||||
.. versionadded:: 3.15
|
||||
|
||||
If no variable name is given, removes exactly one element. Otherwise,
|
||||
with `N` variable names provided, assign the first `N` elements' values
|
||||
to the given variables and then remove the first `N` values from
|
||||
with *N* variable names provided, assign the first *N* elements' values
|
||||
to the given variables and then remove the first *N* values from
|
||||
``<list>``.
|
||||
|
||||
.. signature::
|
||||
@ -307,10 +307,10 @@ Ordering
|
||||
Sorts a list of strings using natural order
|
||||
(see ``strverscmp(3)`` manual), i.e. such that contiguous digits
|
||||
are compared as whole numbers.
|
||||
For example: the following list `10.0 1.1 2.1 8.0 2.0 3.1`
|
||||
will be sorted as `1.1 2.0 2.1 3.1 8.0 10.0` if the ``NATURAL``
|
||||
For example: the following list *10.0 1.1 2.1 8.0 2.0 3.1*
|
||||
will be sorted as *1.1 2.0 2.1 3.1 8.0 10.0* if the ``NATURAL``
|
||||
comparison is selected where it will be sorted as
|
||||
`1.1 10.0 2.0 2.1 3.1 8.0` with the ``STRING`` comparison.
|
||||
*1.1 10.0 2.0 2.1 3.1 8.0* with the ``STRING`` comparison.
|
||||
|
||||
Use the ``CASE`` keyword to select a case sensitive or case insensitive
|
||||
sort mode. The ``<case>`` option should be one of:
|
||||
|
@ -164,7 +164,7 @@ The options for the above signatures are:
|
||||
The above example shows how values for variables
|
||||
``COMPILE_DEFINITIONS``, ``INCLUDE_DIRECTORIES``, ``LINK_DIRECTORIES``,
|
||||
``LINK_LIBRARIES``, and ``LINK_OPTIONS`` are used. Compiler options
|
||||
can be passed in like `CMAKE_FLAGS -DCOMPILE_DEFINITIONS=-Werror`.
|
||||
can be passed in like ``CMAKE_FLAGS -DCOMPILE_DEFINITIONS=-Werror``.
|
||||
|
||||
``COMPILE_DEFINITIONS <defs>...``
|
||||
Specify ``-Ddefinition`` arguments to pass to :command:`add_definitions`
|
||||
|
@ -398,7 +398,7 @@ List of CPack DEB generator specific variables:
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_PREDEPENDS
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS
|
||||
|
||||
Sets the `Pre-Depends` field of the Debian package.
|
||||
Sets the ``Pre-Depends`` field of the Debian package.
|
||||
Like :variable:`Depends <CPACK_DEBIAN_PACKAGE_DEPENDS>`, except that it
|
||||
also forces ``dpkg`` to complete installation of the packages named
|
||||
before even starting the installation of the package which declares the
|
||||
@ -462,8 +462,8 @@ List of CPack DEB generator specific variables:
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_CONFLICTS
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS
|
||||
|
||||
Sets the `Conflicts` field of the Debian package.
|
||||
When one binary package declares a conflict with another using a `Conflicts`
|
||||
Sets the ``Conflicts`` field of the Debian package.
|
||||
When one binary package declares a conflict with another using a ``Conflicts``
|
||||
field, ``dpkg`` will not allow them to be unpacked on the system at
|
||||
the same time.
|
||||
|
||||
@ -490,8 +490,8 @@ List of CPack DEB generator specific variables:
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_PROVIDES
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES
|
||||
|
||||
Sets the `Provides` field of the Debian package.
|
||||
A virtual package is one which appears in the `Provides` control field of
|
||||
Sets the ``Provides`` field of the Debian package.
|
||||
A virtual package is one which appears in the ``Provides`` control field of
|
||||
another package.
|
||||
|
||||
:Mandatory: No
|
||||
@ -509,7 +509,7 @@ List of CPack DEB generator specific variables:
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_REPLACES
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES
|
||||
|
||||
Sets the `Replaces` field of the Debian package.
|
||||
Sets the ``Replaces`` field of the Debian package.
|
||||
Packages can declare in their control file that they should overwrite
|
||||
files in certain other packages, or completely replace other packages.
|
||||
|
||||
@ -547,7 +547,7 @@ List of CPack DEB generator specific variables:
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_SUGGESTS
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS
|
||||
|
||||
Sets the `Suggests` field of the Debian package.
|
||||
Sets the ``Suggests`` field of the Debian package.
|
||||
Allows packages to declare a suggested package install grouping.
|
||||
|
||||
:Mandatory: No
|
||||
@ -668,7 +668,7 @@ List of CPack DEB generator specific variables:
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_MULTIARCH
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_MULTIARCH
|
||||
|
||||
Sets the `Multi-Arch` field of the Debian package.
|
||||
Sets the ``Multi-Arch`` field of the Debian package.
|
||||
Packages can declare in their control file how they should handle
|
||||
situations, where packages for different architectures are being installed
|
||||
on the same machine.
|
||||
|
@ -469,7 +469,7 @@ a remote server.
|
||||
The ``DOWNLOADED`` option in the :command:`cpack_add_component` command
|
||||
specifies that a component is to be downloaded. Alternatively, the ``ALL``
|
||||
option in the :command:`cpack_configure_downloads` command specifies that
|
||||
`all` components are to be be downloaded.
|
||||
``all`` components are to be be downloaded.
|
||||
|
||||
The :command:`cpack_ifw_add_repository` command and the
|
||||
:variable:`CPACK_IFW_DOWNLOAD_ALL` variable allow for more specific
|
||||
|
@ -61,7 +61,7 @@ on Windows Nullsoft Scriptable Install System.
|
||||
|
||||
.. variable:: CPACK_NSIS_COMPRESSOR
|
||||
|
||||
The arguments that will be passed to the NSIS `SetCompressor` command.
|
||||
The arguments that will be passed to the NSIS ``SetCompressor`` command.
|
||||
|
||||
.. variable:: CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL
|
||||
|
||||
@ -78,8 +78,8 @@ on Windows Nullsoft Scriptable Install System.
|
||||
|
||||
.. variable:: CPACK_NSIS_DISPLAY_NAME
|
||||
|
||||
The display name string that appears in the Windows `Apps & features`
|
||||
in `Control Panel`
|
||||
The display name string that appears in the Windows *Apps & features*
|
||||
in *Control Panel*
|
||||
|
||||
.. variable:: CPACK_NSIS_PACKAGE_NAME
|
||||
|
||||
@ -111,15 +111,15 @@ on Windows Nullsoft Scriptable Install System.
|
||||
|
||||
.. variable:: CPACK_NSIS_CREATE_ICONS_EXTRA
|
||||
|
||||
Additional NSIS commands for creating `Start Menu` shortcuts.
|
||||
Additional NSIS commands for creating *Start Menu* shortcuts.
|
||||
|
||||
.. variable:: CPACK_NSIS_DELETE_ICONS_EXTRA
|
||||
|
||||
Additional NSIS commands to uninstall `Start Menu` shortcuts.
|
||||
Additional NSIS commands to uninstall *Start Menu* shortcuts.
|
||||
|
||||
.. variable:: CPACK_NSIS_EXECUTABLES_DIRECTORY
|
||||
|
||||
Creating NSIS `Start Menu` links assumes that they are in ``bin`` unless this
|
||||
Creating NSIS *Start Menu* links assumes that they are in ``bin`` unless this
|
||||
variable is set. For example, you would set this to ``exec`` if your
|
||||
executables are in an exec directory.
|
||||
|
||||
|
@ -22,7 +22,7 @@ https://rpm.org/documentation.
|
||||
|
||||
.. versionchanged:: 3.6
|
||||
|
||||
`<COMPONENT>` part of variables is preferred to be in upper case (e.g. if
|
||||
``<COMPONENT>`` part of variables is preferred to be in upper case (e.g. if
|
||||
component is named ``foo`` then use :variable:`!CPACK_RPM_FOO_XXXX` variable
|
||||
name format) as is with other :variable:`!CPACK_<COMPONENT>_XXXX` variables.
|
||||
For the purposes of back compatibility (CMake/CPack version 3.5 and lower)
|
||||
|
@ -400,7 +400,7 @@ include files.
|
||||
|
||||
**Note:** Throughout this tutorial, we will refer to the project build and
|
||||
the project binary directory interchangeably. These are the same and are not
|
||||
meant to refer to a `bin/` directory.
|
||||
meant to refer to a ``bin/`` directory.
|
||||
|
||||
We used :command:`target_include_directories` to specify
|
||||
where the executable target should look for include files.
|
||||
|
@ -10,7 +10,7 @@ possible, however, to setup CPack to bundle multiple build directories and
|
||||
construct a package that contains multiple configurations of the same project.
|
||||
|
||||
First, we want to ensure that the debug and release builds use different names
|
||||
for the libraries that will be installed. Let's use `d` as the
|
||||
for the libraries that will be installed. Let's use ``d`` as the
|
||||
postfix for the debug libraries.
|
||||
|
||||
Set :variable:`CMAKE_DEBUG_POSTFIX` near the beginning of the top-level
|
||||
|
@ -1415,7 +1415,7 @@ Compile Context
|
||||
linking requirements (e.g., all-``inline`` or C++ template libraries).
|
||||
|
||||
Note that for proper evaluation of this expression requires policy :policy:`CMP0099`
|
||||
to be set to `NEW`.
|
||||
to be set to ``NEW``.
|
||||
|
||||
Linker Language And ID
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
@ -104,7 +104,7 @@ optional.
|
||||
|
||||
``version``
|
||||
The Data version of snippet file to generate, an integer. Currently the only
|
||||
supported version is `1`.
|
||||
supported version is ``1``.
|
||||
|
||||
``callbacks``
|
||||
A list of command-line strings for callbacks to handle collected timing
|
||||
@ -205,7 +205,7 @@ and contain the following data:
|
||||
|
||||
``version``
|
||||
The Data version of the snippet file, an integer. Currently the version is
|
||||
always `1`.
|
||||
always ``1``.
|
||||
|
||||
``command``
|
||||
The full command executed.
|
||||
@ -312,7 +312,7 @@ for navigating the instrumentation data.
|
||||
|
||||
``version``
|
||||
The Data version of the index file, an integer. Currently the version is
|
||||
always `1`.
|
||||
always ``1``.
|
||||
|
||||
``buildDir``
|
||||
The build directory of the CMake project.
|
||||
|
@ -167,12 +167,12 @@ the current working directory (cwd) is used for the other. For example:
|
||||
============================== ============ ===========
|
||||
Command Line Source Dir Build Dir
|
||||
============================== ============ ===========
|
||||
``cmake -B build`` `cwd` ``build``
|
||||
``cmake -B build`` *cwd* ``build``
|
||||
``cmake -B build src`` ``src`` ``build``
|
||||
``cmake -B build -S src`` ``src`` ``build``
|
||||
``cmake src`` ``src`` `cwd`
|
||||
``cmake build`` (existing) `loaded` ``build``
|
||||
``cmake -S src`` ``src`` `cwd`
|
||||
``cmake src`` ``src`` *cwd*
|
||||
``cmake build`` (existing) *loaded* ``build``
|
||||
``cmake -S src`` ``src`` *cwd*
|
||||
``cmake -S src build`` ``src`` ``build``
|
||||
``cmake -S src -B build`` ``src`` ``build``
|
||||
============================== ============ ===========
|
||||
|
@ -551,7 +551,7 @@ that are mapped to subprojects.
|
||||
|
||||
When the :prop_test:`PROCESSORS` test property is set, CTest will display a
|
||||
weighted test timing result in label and subproject summaries. The time is
|
||||
reported with `sec*proc` instead of just `sec`.
|
||||
reported with ``sec * proc`` instead of just ``sec``.
|
||||
|
||||
The weighted time summary reported for each label or subproject ``j``
|
||||
is computed as::
|
||||
@ -810,10 +810,10 @@ The available ``<dashboard-options>`` are the following:
|
||||
|
||||
.. option:: --http1.0
|
||||
|
||||
Submit using `HTTP 1.0`.
|
||||
Submit using ``HTTP 1.0``.
|
||||
|
||||
This option will force CTest to use `HTTP 1.0` to submit files to the
|
||||
dashboard, instead of `HTTP 1.1`.
|
||||
This option will force CTest to use ``HTTP 1.0`` to submit files to the
|
||||
dashboard, instead of ``HTTP 1.1``.
|
||||
|
||||
.. option:: --no-compress-output
|
||||
|
||||
|
@ -16,7 +16,7 @@ as ``OFF`` by default unless projects enable the feature. For example:
|
||||
|
||||
CMake 3.26 and later prefer to enable the feature by default.
|
||||
|
||||
Note that it is the policy setting at the `end` of the top level
|
||||
Note that it is the policy setting at the **end** of the top level
|
||||
``CMakeLists.txt`` file that matters. The policy setting applies globally
|
||||
to the whole project.
|
||||
|
||||
|
@ -3,7 +3,7 @@ CPACK_DESKTOP_SHORTCUTS
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Species a list of shortcut names that should be created on the `Desktop`
|
||||
Species a list of shortcut names that should be created on the ``Desktop``
|
||||
for this file.
|
||||
|
||||
The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.
|
||||
|
@ -3,7 +3,7 @@ CPACK_STARTUP_SHORTCUTS
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Species a list of shortcut names that should be created in the `Startup` folder
|
||||
Species a list of shortcut names that should be created in the ``Startup`` folder
|
||||
for this file.
|
||||
|
||||
The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.
|
||||
|
@ -4,7 +4,7 @@ VS_SHADER_OBJECT_FILE_NAME
|
||||
.. versionadded:: 3.12
|
||||
|
||||
.. noqa: spellcheck off
|
||||
.. Ignore `-Fo` here
|
||||
.. Ignore ``-Fo`` here
|
||||
|
||||
Specifies a file name for the compiled shader object file for an ``.hlsl``
|
||||
source file. This adds the ``-Fo`` flag to the command line for the FxCompiler
|
||||
|
@ -19,8 +19,8 @@ When consumed, these targets will be reapplied as necessary.
|
||||
|
||||
.. note::
|
||||
|
||||
Similar to the introduction of :prop:`CXX_SCAN_FOR_MODULES`, this property
|
||||
defaults to _not_ adding ``import std`` support to targets using
|
||||
Similar to the introduction of :prop_tgt:`CXX_SCAN_FOR_MODULES`, this
|
||||
property defaults to **not** adding ``import std`` support to targets using
|
||||
``cxx_std_23`` without an explicit request in order to preserve existing
|
||||
behavior for projects using C++23 without ``import std``. A future policy
|
||||
to change the default behavior is expected once the feature sees wider
|
||||
|
@ -4,9 +4,9 @@ GHS_INTEGRITY_APP
|
||||
.. versionadded:: 3.14
|
||||
|
||||
``ON`` / ``OFF`` boolean to determine if an executable target should
|
||||
be treated as an `Integrity Application`.
|
||||
be treated as an ``Integrity Application``.
|
||||
|
||||
If no value is set and if a ``.int`` file is added as a source file to the
|
||||
executable target it will be treated as an `Integrity Application`.
|
||||
executable target it will be treated as an ``Integrity Application``.
|
||||
|
||||
Supported on :generator:`Green Hills MULTI`.
|
||||
|
@ -4,8 +4,8 @@ XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE
|
||||
.. versionadded:: 3.23
|
||||
|
||||
Property value for ``GPU Frame Capture`` in the Options section of
|
||||
the generated Xcode scheme. Example values are `Metal` and
|
||||
`Disabled`.
|
||||
the generated Xcode scheme. Example values are ``Metal`` and
|
||||
``Disabled``.
|
||||
|
||||
This property is initialized by the value of the variable
|
||||
:variable:`CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE`
|
||||
|
@ -368,7 +368,7 @@ Other Changes
|
||||
|
||||
* The :command:`ctest_memcheck` command no longer automatically adds
|
||||
``leak_check=1`` to the options used by ``AddressSanitizer``. The default
|
||||
behavior of ``AddressSanitizer`` is to run `LeakSanitizer` to check leaks
|
||||
behavior of ``AddressSanitizer`` is to run ``LeakSanitizer`` to check leaks
|
||||
unless ``leak_check=0``.
|
||||
|
||||
* The :command:`ctest_memcheck` command was fixed to correctly append extra
|
||||
|
@ -13,7 +13,7 @@ For native build systems supporting multiple configurations in the
|
||||
build tree (such as :ref:`Visual Studio Generators` and :generator:`Xcode`),
|
||||
the value is a reference to a build-time variable specifying the name
|
||||
of the per-configuration output subdirectory. On :ref:`Makefile Generators`
|
||||
this evaluates to `.` because there is only one configuration in a build tree.
|
||||
this evaluates to ``.`` because there is only one configuration in a build tree.
|
||||
Example values:
|
||||
|
||||
::
|
||||
@ -28,7 +28,7 @@ Since these values are evaluated by the native build system, this
|
||||
variable is suitable only for use in command lines that will be
|
||||
evaluated at build time. Example of intended usage:
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
add_executable(mytool mytool.c)
|
||||
add_custom_command(
|
||||
|
@ -4,4 +4,4 @@ CMAKE_DEBUG_POSTFIX
|
||||
See variable :variable:`CMAKE_<CONFIG>_POSTFIX`.
|
||||
|
||||
This variable is a special case of the more-general
|
||||
:variable:`CMAKE_<CONFIG>_POSTFIX` variable for the `DEBUG` configuration.
|
||||
:variable:`CMAKE_<CONFIG>_POSTFIX` variable for the ``DEBUG`` configuration.
|
||||
|
@ -17,11 +17,11 @@ path. Example of such locations are directories created due to the setting of
|
||||
|
||||
Expected content of the ``CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS``
|
||||
variable is a list of permissions that can be used by :command:`install` command
|
||||
`PERMISSIONS` section.
|
||||
``PERMISSIONS`` section.
|
||||
|
||||
Example usage:
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
set(CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
|
||||
OWNER_READ
|
||||
|
@ -4,8 +4,8 @@ CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE
|
||||
.. versionadded:: 3.23
|
||||
|
||||
Property value for ``GPU Frame Capture`` in the Options section of
|
||||
the generated Xcode scheme. Example values are `Metal` and
|
||||
`Disabled`.
|
||||
the generated Xcode scheme. Example values are ``Metal`` and
|
||||
``Disabled``.
|
||||
|
||||
This variable initializes the
|
||||
:prop_tgt:`XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE`
|
||||
|
@ -9,5 +9,5 @@ This variable serves the same purpose during packaging as the
|
||||
:variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS` variable
|
||||
serves during installation (e.g. ``make install``).
|
||||
|
||||
If `include(CPack)` is used then by default this variable is set to the content
|
||||
If ``include(CPack)`` is used then by default this variable is set to the content
|
||||
of :variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS`.
|
||||
|
@ -2,7 +2,7 @@ The fuzzers in this directory are run continuously through OSS-fuzz.
|
||||
All fuzzers are implemented by way of the `libFuzzer engine`_.
|
||||
|
||||
The link to the OSS-fuzz integration can be found here: (pending)
|
||||
All email addresses in the `project.yaml` file on OSS-fuzz will have access
|
||||
All email addresses in the ``project.yaml`` file on OSS-fuzz will have access
|
||||
to detailed bug reports and will be notified via email if/when bugs are found.
|
||||
|
||||
.. _`libFuzzer Engine`: https://llvm.org/docs/LibFuzzer.html
|
||||
|
Loading…
Reference in New Issue
Block a user