use inline code formatting in docs for variables, functions, and modu…

…les (#591)

Reading through the docs today, I found a few places where it looked like italics were being used when inline code formatting would be clearer.

I expected that in many of these cases, inline code formatting was actually *intended*, but just mistakenly not applied. When you're mostly writing markdown, it's easy to get in the habit of using a single backtick for inline code formatting...  reStructuredText uses 2 backticks.

For example, at https://docs.rapids.ai/api/rapids-cmake/stable/packages/rapids_cpm_versions/.

<img width="1323" alt="Screenshot 2024-04-22 at 1 08 50 PM" src="https://github.com/rapidsai/rapids-cmake/assets/7608904/f24e3148-41f6-4545-bbb2-e7fc7f317ea6">

This proposes changing them to inline code formatting, to make the names of things like environment variables more obvious visually.

## Notes for Reviewers

After noticing a few in the rendered docs, I looked for other possible cases like this.

```shell
git grep -E ' \`[^\`]+' *.rst
```

Used my best judgment to decide which seemed like they should be inline code formatting.

Authors:
  - James Lamb (https://github.com/jameslamb)

Approvers:
  - Robert Maynard (https://github.com/robertmaynard)

URL: #591

docs/api.rst

@@ -68,7 +68,7 @@ package uses :ref:`can be found here. <cpm_versions>`
 Cython
 ******
 
-The `rapids-cython-core` module allows projects to easily build cython modules using
+The ``rapids-cython-core`` module allows projects to easily build cython modules using
 `scikit-build-core <https://scikit-build-core.readthedocs.io/en/latest/>`_.
 
 .. note::
@@ -88,7 +88,7 @@ Cython (legacy)
 ***************
 
 .. note::
-  `rapids-cython` is deprecated. Please switch to `rapids-cython-core`.
+  ``rapids-cython`` is deprecated. Please switch to ``rapids-cython-core``.
 
 The `rapids_cython` functions allow projects to easily build cython modules using
 `scikit-build <https://scikit-build.readthedocs.io/en/latest/>`_.
@@ -142,12 +142,11 @@ require.
 Export Set Generation
 *********************
 
-These `rapids_export` functions allow projects to generate correct build and install tree `Project-Config.cmake` modules including required dependencies.
+These `rapids_export` functions allow projects to generate correct build and install tree ``Project-Config.cmake`` modules including required dependencies.
 
 For the vast majority of projects :cmake:command:`rapids_export` should be sufficient. But when
 not projects may use commands such as :cmake:command:`rapids_export_write_dependencies` and
-:cmake:command:`rapids_export_write_language` to create a custom `Project-Config.cmake`.
-
+:cmake:command:`rapids_export_write_language` to create a custom ``Project-Config.cmake``.
 
 .. toctree::
    :maxdepth: 1

docs/basics.rst

@@ -30,7 +30,7 @@ Usage
 *****
 
 ``rapids-cmake`` is designed for projects to use only the subset of features that they need. To enable
-this `rapids-cmake` comprises the following primary components:
+this ``rapids-cmake`` comprises the following primary components:
 
 - :ref:`cmake <common>`
 - :ref:`cpm <cpm>`

docs/dependency_tracking.rst

@@ -3,12 +3,12 @@ Dependency Tracking
 ###################
 
 One of the biggest features of rapids-cmake is that it can track dependencies ( `find_package`, `cpm` ),
-allowing projects to easily generate `<project>-config.cmake` files with correct dependency requirements.
-In a normal CMake project, public dependencies need to be recorded in two locations: the original ``CMakeLists.txt`` file and the generated `<project>-config.cmake`. This dual source of truth increases
+allowing projects to easily generate ``<project>-config.cmake`` files with correct dependency requirements.
+In a normal CMake project, public dependencies need to be recorded in two locations: the original ``CMakeLists.txt`` file and the generated ``<project>-config.cmake``. This dual source of truth increases
 developer burden, and adds a common source of error.
 
 ``rapids-cmake`` is designed to remove this dual source of truth by expanding the concept of Modern CMake `Usage Requirements <https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements>`_ to include external packages.
-This is done via the ``BUILD_EXPORT_SET`` ( maps to `<BUILD_INTERFACE>` ) and ``INSTALL_EXPORT_SET`` ( maps to `<INSTALL_INTERFACE>` ) keywords on commands such as :cmake:command:`rapids_find_package` and :cmake:command:`rapids_cpm_find`.
+This is done via the ``BUILD_EXPORT_SET`` ( maps to ``<BUILD_INTERFACE>`` ) and ``INSTALL_EXPORT_SET`` ( maps to ``<INSTALL_INTERFACE>`` ) keywords on commands such as :cmake:command:`rapids_find_package` and :cmake:command:`rapids_cpm_find`.
 Let's go over an example of how these come together to make dependency tracking for projects easy.
 
 .. code-block:: cmake
@@ -55,23 +55,23 @@ Tracking find_package
     )
 
 The :cmake:command:`rapids_find_package(<PackageName>)` combines the :cmake:command:`find_package <cmake:command:find_package>` command and dependency tracking.
-This example records that the `Threads` package is required by both the export set `example-targets` for both the install and build configuration.
+This example records that the ``Threads`` package is required by both the export set ``example-targets`` for both the install and build configuration.
 
-This means that when :cmake:command:`rapids_export` is called the generated `example-config.cmake` file will include the call
+This means that when :cmake:command:`rapids_export` is called the generated ``example-config.cmake`` file will include the call
 `find_dependency(Threads)`, removing the need for developers to maintain that dual source of truth.
 
-The :cmake:command:`rapids_find_package(<PackageName>)` command also supports non-required finds correctly. In those cases `rapids-cmake` only records
+The :cmake:command:`rapids_find_package(<PackageName>)` command also supports non-required finds correctly. In those cases ``rapids-cmake`` only records
 the dependency when the underlying :cmake:command:`find_package <cmake:command:find_package>` command is successful.
 
-It is common for projects to have dependencies for which CMake doesn't have a `Find<Package>`. In those cases projects will have a custom
-`Find<Package>` that they need to use, and install for consumers. Rapids-cmake tries to help projects simplify this process with the commands
+It is common for projects to have dependencies for which CMake doesn't have a ``Find<Package>``. In those cases projects will have a custom
+``Find<Package>`` that they need to use, and install for consumers. Rapids-cmake tries to help projects simplify this process with the commands
 :cmake:command:`rapids_find_generate_module` and :cmake:command:`rapids_export_package`.
 
-The :cmake:command:`rapids_find_generate_module` allows projects to automatically generate a `Find<Package>` and encode via the `BUILD_EXPORT_SET`
-and `INSTALL_EXPORT_SET` parameters when the generated module should also be installed and added to `CMAKE_MODULE_PATH` so that consumers can use it.
+The :cmake:command:`rapids_find_generate_module` allows projects to automatically generate a ``Find<Package>`` and encode via the ``BUILD_EXPORT_SET``
+and ```INSTALL_EXPORT_SET``` parameters when the generated module should also be installed and added to ``CMAKE_MODULE_PATH`` so that consumers can use it.
 
-If you already have an existing `Find<Package>` written, :cmake:command:`rapids_export_package` simplifies the process of installing the module and
-making sure it is part of `CMAKE_MODULE_PATH` for consumers.
+If you already have an existing ``Find<Package>`` written, :cmake:command:`rapids_export_package` simplifies the process of installing the module and
+making sure it is part of ``CMAKE_MODULE_PATH`` for consumers.
 
 Tracking CPM
 ************
@@ -83,17 +83,17 @@ Tracking CPM
     )
 
 The :cmake:command:`rapids_cpm_find` combines the :cmake:command:`CPMFindPackage` command and dependency tracking, in a very similar way
-to :cmake:command:`rapids_find_package`. In this example what we are saying is that nlohmann_json is only needed by the build directory `example-config`
-and not needed by the installed `example-config`. While this pattern is rare, it occurs when projects have some dependencies that aren't needed by consumers but are
+to :cmake:command:`rapids_find_package`. In this example what we are saying is that nlohmann_json is only needed by the build directory ``example-config``
+and not needed by the installed ``example-config``. While this pattern is rare, it occurs when projects have some dependencies that aren't needed by consumers but are
 propagated through the usage requirements inside a project via $<BUILD_INTERFACE>. Why use a build directory `config` file at all? The most common
 reason is that developers need to work on multiple dependent projects in a fast feedback loop. In that case this workflow avoids having to re-install a project each time
 a change needs to be tested in a dependent project.
 
-When used with `BUILD_EXPORT_SET`, :cmake:command:`rapids_cpm_find` will generate a :cmake:command:`CPMFindPackage(<PackageName> ...)` call, and when used
-with `INSTALL_EXPORT_SET` it will generate a :cmake:command:`find_dependency(<PackageName> ...) <cmake:command:find_dependency>` call. The theory behind this is that most packages currently don't have
-great build `config.cmake` support so it is best to have a fallback to cpm, while it is expected that all CMake packages have install rules.
+When used with ``BUILD_EXPORT_SET``, :cmake:command:`rapids_cpm_find` will generate a :cmake:command:`CPMFindPackage(<PackageName> ...)` call, and when used
+with ``INSTALL_EXPORT_SET`` it will generate a :cmake:command:`find_dependency(<PackageName> ...) <cmake:command:find_dependency>` call. The theory behind this is that most packages currently don't have
+great build ``config.cmake`` support so it is best to have a fallback to cpm, while it is expected that all CMake packages have install rules.
 If this isn't the case for a CPM package you can instead use :cmake:command:`rapids_export_cpm`, and :cmake:command:`rapids_export_package` to specify the correct generated commands
-and forgo using `[BUILD|INSTALL]_EXPORT_SET`.
+and forgo using ``[BUILD|INSTALL]_EXPORT_SET``.
 
 
 Generating example-config.cmake
@@ -113,12 +113,12 @@ Generating example-config.cmake
     DOCUMENTATION doc_string
     )
 
-Before `rapids-cmake`, if a project wanted to generate a config module they would follow the example in
+Before ``rapids-cmake``, if a project wanted to generate a config module they would follow the example in
 the :ref:`cmake-packages docs <cmake:Creating Packages>` and use :cmake:command:`install(EXPORT) <cmake:command:install>`, :cmake:command:`export(EXPORT) <cmake:command:export>`, :cmake:command:`write_basic_package_version_file <cmake:command:write_basic_package_version_file>`, and a custom `config.cmake.in` file.
 
 The goal of :cmake:command:`rapids_export` is to replace all the boilerplate with an easy to use function that also embeds the necessary
-dependency calls collected by `BUILD_EXPORT_SET` and `INSTALL_EXPORT_SET`.
+dependency calls collected by ``BUILD_EXPORT_SET`` and ``INSTALL_EXPORT_SET``.
 
 :cmake:command:`rapids_export` uses CMake best practises to generate all the necessary components of a project config file. It handles generating
 a correct version file, finding dependencies and all the other boilerplate necessary to make well-behaved CMake config files. Moreover,
-the files generated by :cmake:command:`rapids_export` are completely standalone with no dependency on `rapids-cmake`.
+the files generated by :cmake:command:`rapids_export` are completely standalone with no dependency on ``rapids-cmake``.

docs/hardware_resources_and_testing.rst

@@ -111,7 +111,7 @@ For the CMake side you can use :cmake:command:`rapids_test_gpu_requirements` to
   add_test(NAME test_small_alloc COMMAND cuda_test 50)
   rapids_test_gpu_requirements(test_small_alloc GPUS 1 PERCENT 10)
 
-Now in the C++ you need to parse the relevant `CTEST_RESOURCE_GROUP` environment variables.
+Now in the C++ you need to parse the relevant ``CTEST_RESOURCE_GROUP`` environment variables.
 To simplify the process, here is some helper C++ code that will do the heavy lifting for you:
 
 .. literalinclude:: cpp_code_snippets/rapids_cmake_ctest_allocation.hpp

docs/packages/rapids_cpm_versions.rst

@@ -62,27 +62,27 @@ as needed.
     An optional boolean value that represents if we should do a shallow git clone
     or not.
 
-    If no such field exists the default is `true`.
+    If no such field exists the default is ``true``.
 
 ``exclude_from_all``
 
-    An optional boolean value that represents the CMake `EXCLUDE_FROM_ALL` property.
-    If this is set to `true`, and the project is built from source all targets of that
-    project will be excluded from the `ALL` build rule. This means that any target
+    An optional boolean value that represents the CMake ```EXCLUDE_FROM_ALL``` property.
+    If this is set to ``true``, and the project is built from source all targets of that
+    project will be excluded from the ``ALL`` build rule. This means that any target
     that isn't used by the consuming project will not be compiled. This is useful
     when a project generates multiple targets that aren't required and the cost
     of building them isn't desired.
 
-    If no such field exists the default is `false`.
+    If no such field exists the default is ``false``.
 
 ``always_download``
 
     An optional boolean value that represents if CPM should just download the
-    package ( `CPM_DOWNLOAD_ALL` ) instead of first searching for it on the machine.
+    package ( ``CPM_DOWNLOAD_ALL`` ) instead of first searching for it on the machine.
 
-    The default value for this field is `false` unless all of the following criteria is met.
+    The default value for this field is ``false`` unless all of the following criteria is met.
         - The projects exists in both the default and override files
-        - The `git_url`, `git_tag`, `patches` keys exist in the override
+        - The ``git_url``, ``git_tag``, ``patches`` keys exist in the override
 
 ``patches``
     An optional list of dictionary sets of git patches to apply to the project
@@ -96,7 +96,7 @@ as needed.
         ``file``
             A required string representing the git diff ( .diff ) or patch ( .patch ) to apply.
             Absolute and relative paths are supported. Relative paths are
-            evaluated in relation to the `rapids-cmake/cpm/patches` directory.
+            evaluated in relation to the ``rapids-cmake/cpm/patches`` directory.
 
             Supports the following placeholders:
                 - ``${current_json_dir}`` will be evaluated to the absolute path to the directory holding the current json file
@@ -116,10 +116,10 @@ as needed.
     An optional dictionary of cpu architecture and operating system keys to url values that represents a download for a pre-built proprietary version of the library. This creates a new entry in the search
     logic for a project:
 
-        - Search for a local version matching the `version` key
-            - disabled by `always_download`
+        - Search for a local version matching the ``version`` key
+            - disabled by ``always_download``
         - Download proprietary version if a valid OS + CPU Arch exists
-            - disabled by `USE_PROPRIETARY_BLOB` being off
+            - disabled by ``USE_PROPRIETARY_BLOB`` being off
         - Fallback to using git url and tag
 
     To determine the correct key, CMake will query for a key that matches the lower case value of `<arch>-<os>` where `arch` maps to
@@ -135,7 +135,7 @@ as needed.
 
     Due to requirements of proprietary binaries, explicit opt-in by the user on usage is required.
     Therefore for this binary to be used the caller must call the associated `rapids_cpm` command
-    with the `USE_PROPRIETARY_BLOB` set to `ON`.
+    with the ``USE_PROPRIETARY_BLOB`` set to ``ON``.
 
     Supports the following placeholders:
         - ``${rapids-cmake-version}`` will be evaluated to 'major.minor' of the current rapids-cmake cal-ver value.