Merge topic 'help-code-block'

9890cfc4ec Help: More syntax highlighting for literal blocks

Acked-by: Kitware Robot <[email protected]>
Merge-request: !10258

Help/command/cmake_host_system_information.rst

@@ -283,7 +283,7 @@ Query Windows registry
 
 .. versionadded:: 3.24
 
-::
+.. code-block:: cmake
 
   cmake_host_system_information(RESULT <variable>
                                 QUERY WINDOWS_REGISTRY <key> [VALUE_NAMES|SUBKEYS|VALUE <name>]

Help/command/cmake_pkg_config.rst

@@ -12,7 +12,7 @@ Process pkg-config format package files.
 Synopsis
 ^^^^^^^^
 
-.. parsed-literal::
+.. code-block:: cmake
 
   cmake_pkg_config(EXTRACT <package> [<version>] [...])
 

Help/command/find_package.rst

@@ -26,7 +26,7 @@ Typical Usage
 
 Most calls to ``find_package()`` typically have the following form:
 
-.. parsed-literal::
+.. code-block:: cmake
 
   find_package(<PackageName> [<version>] [REQUIRED] [COMPONENTS <components>...])
 
@@ -133,7 +133,7 @@ forced to use only Module mode with a ``MODULE`` keyword.  If the
 Basic Signature
 ^^^^^^^^^^^^^^^
 
-.. parsed-literal::
+.. code-block:: cmake
 
   find_package(<PackageName> [version] [EXACT] [QUIET] [MODULE]
                [REQUIRED] [[COMPONENTS] [components...]]
@@ -249,7 +249,7 @@ of the ``NO_POLICY_SCOPE`` option.
 Full Signature
 ^^^^^^^^^^^^^^
 
-.. parsed-literal::
+.. code-block:: cmake
 
   find_package(<PackageName> [version] [EXACT] [QUIET]
                [REQUIRED] [[COMPONENTS] [components...]]

Help/cpack_gen/nsis.rst

@@ -132,9 +132,11 @@ on Windows Nullsoft Scriptable Install System.
 
  Specify links in ``[application]`` menu.  This should contain a list of pair
  ``link`` ``link name``. The link may be a URL or a path relative to
- installation prefix.  Like::
+ installation prefix.  Like:
 
-  set(CPACK_NSIS_MENU_LINKS
+ .. code-block:: cmake
+
+    set(CPACK_NSIS_MENU_LINKS
       "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html"
       "CMake Help" "https://cmake.org" "CMake Web Site")
 

Help/dev/documentation.rst

@@ -629,7 +629,7 @@ reStructuredText markup from comment blocks that start in ``.rst:``.
 At the top of ``Modules/<module-name>.cmake``, begin with the following
 license notice:
 
-::
+.. code-block:: cmake
 
  # Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
  # file Copyright.txt or https://cmake.org/licensing for details.
@@ -637,7 +637,7 @@ license notice:
 After this notice, add a *BLANK* line.  Then, add documentation using
 a `Bracket Comment`_ of the form:
 
-::
+.. code-block:: cmake
 
   #[=======================================================================[.rst:
   <module-name>
@@ -655,7 +655,7 @@ All such comments must start with ``#`` in the first column.
 
 For example, a ``FindXxx.cmake`` module may contain:
 
-::
+.. code-block:: cmake
 
   # Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
   # file Copyright.txt or https://cmake.org/licensing for details.

Help/manual/cmake-configure-log.7.rst

@@ -20,7 +20,9 @@ detailed information about specific events, such as toolchain inspection
 by :command:`try_compile`, meant for use in debugging the configuration
 of a build tree.
 
-For human use, this version of CMake writes the configure log to the file::
+For human use, this version of CMake writes the configure log to the file:
+
+.. code-block:: cmake
 
   ${CMAKE_BINARY_DIR}/CMakeFiles/CMakeConfigureLog.yaml
 

Help/manual/cmake-developer.7.rst

@@ -126,7 +126,9 @@ In either case (or even when providing both variables and imported
 targets), find modules should provide backwards compatibility with old
 versions that had the same name.
 
-A FindFoo.cmake module will typically be loaded by the command::
+A FindFoo.cmake module will typically be loaded by the command:
+
+.. code-block:: cmake
 
   find_package(Foo [major[.minor[.patch[.tweak]]]]
                [EXACT] [QUIET] [REQUIRED]

Help/manual/cmake-generator-expressions.7.rst

@@ -691,7 +691,7 @@ All paths are expected to be in cmake-style format.
   present, ``0`` otherwise. See :ref:`Path Structure And Terminology` for the
   meaning of each path component.
 
-  ::
+  .. code-block:: cmake
 
     $<PATH:HAS_ROOT_NAME,path>
     $<PATH:HAS_ROOT_DIRECTORY,path>
@@ -753,7 +753,7 @@ command.  All paths are expected to be in cmake-style format.
     All operations now accept a list of paths as argument. When a list of paths
     is specified, the operation will be applied to each path.
 
-  ::
+  .. code-block:: cmake
 
     $<PATH:GET_ROOT_NAME,path...>
     $<PATH:GET_ROOT_DIRECTORY,path...>

Help/manual/cmake-packages.7.rst

@@ -682,7 +682,9 @@ If a project arranges for package registry entries to exist, such as::
   45e7d55f13b87179bb12f907c8de6fc4 REG_SZ c:/Users/Me/Work/lib/cmake/MyPackage
   7b4a9844f681c80ce93190d4e3185db9 REG_SZ c:/Users/Me/Work/MyPackage-build
 
-or::
+or
+
+.. code-block:: console
 
  $ cat ~/.cmake/packages/MyPackage/7d1fb77e07ce59a81bed093bbee945bd
  /home/me/work/lib/cmake/MyPackage

Help/policy/CMP0000.rst

@@ -13,7 +13,7 @@ CMake.  Specifying a version also helps the project build with CMake
 versions newer than that specified.  Use the :command:`cmake_minimum_required`
 command at the top of your main ``CMakeLists.txt`` file:
 
-::
+.. code-block:: cmake
 
   cmake_minimum_required(VERSION <major>.<minor>)
 

Help/policy/CMP0003.rst

@@ -10,7 +10,7 @@ This policy affects how libraries whose full paths are NOT known are
 found at link time, but was created due to a change in how CMake deals
 with libraries whose full paths are known.  Consider the code
 
-::
+.. code-block:: cmake
 
   target_link_libraries(myexe /path/to/libA.so)
 
@@ -36,7 +36,7 @@ example code now produces something like
 
 Unfortunately this change can break code like
 
-::
+.. code-block:: cmake
 
   target_link_libraries(myexe /path/to/libA.so B)
 
@@ -70,7 +70,7 @@ The setting for this policy used when generating the link line is that
 in effect when the target is created by an add_executable or
 add_library command.  For the example described above, the code
 
-::
+.. code-block:: cmake
 
   cmake_policy(SET CMP0003 OLD) # or cmake_policy(VERSION 2.4)
   add_executable(myexe myexe.c)
@@ -79,7 +79,7 @@ add_library command.  For the example described above, the code
 will work and suppress the warning for this policy.  It may also be
 updated to work with the corrected linking approach:
 
-::
+.. code-block:: cmake
 
   cmake_policy(SET CMP0003 NEW) # or cmake_policy(VERSION 2.6)
   link_directories(/path/to) # needed to find library B
@@ -88,7 +88,7 @@ updated to work with the corrected linking approach:
 
 Even better, library B may be specified with a full path:
 
-::
+.. code-block:: cmake
 
   add_executable(myexe myexe.c)
   target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)

Help/policy/CMP0004.rst

@@ -9,7 +9,7 @@ Libraries linked may not have leading or trailing whitespace.
 CMake versions 2.4 and below silently removed leading and trailing
 whitespace from libraries linked with code like
 
-::
+.. code-block:: cmake
 
   target_link_libraries(myexe " A ")
 

Help/policy/CMP0008.rst

@@ -8,7 +8,7 @@ Libraries linked by full-path must have a valid library file name.
 
 In CMake 2.4 and below it is possible to write code like
 
-::
+.. code-block:: cmake
 
   target_link_libraries(myexe /full/path/to/somelib)
 

Help/policy/CMP0023.rst

@@ -14,7 +14,7 @@ target explicitly, even if empty.  This produces confusing behavior
 when used in combination with the historical behavior of the plain
 :command:`target_link_libraries` signature.  For example, consider the code:
 
-::
+.. code-block:: cmake
 
  target_link_libraries(mylib A)
  target_link_libraries(mylib PRIVATE B)

Help/policy/CMP0054.rst

@@ -19,7 +19,7 @@ that have been quoted or bracketed.
 
 Given the following partial example:
 
-::
+.. code-block:: cmake
 
   set(A E)
   set(E "")
@@ -32,20 +32,20 @@ Given the following partial example:
 
 After explicit expansion of variables this gives:
 
-::
+.. code-block:: cmake
 
   if("E" STREQUAL "")
 
 With the policy set to ``OLD`` implicit expansion reduces this semantically to:
 
-::
+.. code-block:: cmake
 
   if("" STREQUAL "")
 
 With the policy set to ``NEW`` the quoted arguments will not be
 further dereferenced:
 
-::
+.. code-block:: cmake
 
   if("E" STREQUAL "")
 

Help/policy/CMP0071.rst

@@ -28,7 +28,9 @@ source files.
   source file properties :prop_sf:`SKIP_AUTOMOC`, :prop_sf:`SKIP_AUTOUIC` or
   :prop_sf:`SKIP_AUTOGEN`.
 
-Source skip example::
+Source skip example:
+
+.. code-block:: cmake
 
   # ...
   set_property(SOURCE /path/to/file1.h PROPERTY SKIP_AUTOMOC ON)

Help/prop_dir/IMPLICIT_DEPENDS_INCLUDE_TRANSFORM.rst

@@ -17,13 +17,13 @@ replaced by the value given with the macro argument substituted for
 
 will convert lines of the form
 
-::
+.. code-block:: c
 
   #include MYDIR(myheader.h)
 
 to
 
-::
+.. code-block:: c
 
   #include <mydir/myheader.h>
 

Help/prop_sf/XCODE_FILE_ATTRIBUTES.rst

@@ -5,7 +5,9 @@ XCODE_FILE_ATTRIBUTES
 
 Add values to the :generator:`Xcode` ``ATTRIBUTES`` setting on its reference to a
 source file.  Among other things, this can be used to set the role on
-a ``.mig`` file::
+a ``.mig`` file:
+
+.. code-block:: cmake
 
   set_source_files_properties(defs.mig
       PROPERTIES

Help/prop_tgt/AUTOMOC_DEPEND_FILTERS.rst

@@ -41,7 +41,9 @@ Example 1
 A header file ``my_class.hpp`` uses a custom macro ``JSON_FILE_MACRO`` which
 is defined in an other header ``macros.hpp``.
 We want the ``moc`` file of ``my_class.hpp`` to depend on the file name
-argument of ``JSON_FILE_MACRO``::
+argument of ``JSON_FILE_MACRO``:
+
+.. code-block:: c++
 
   // my_class.hpp
   class My_Class : public QObject
@@ -52,7 +54,9 @@ argument of ``JSON_FILE_MACRO``::
   };
 
 In ``CMakeLists.txt`` we add a filter to
-:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS` like this::
+:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS` like this:
+
+.. code-block:: c++
 
   list( APPEND CMAKE_AUTOMOC_DEPEND_FILTERS
     "JSON_FILE_MACRO"
@@ -68,7 +72,9 @@ Example 2
 
 In the target ``my_target`` a header file ``complex_class.hpp`` uses a
 custom macro ``JSON_BASED_CLASS`` which is defined in an other header
-``macros.hpp``::
+``macros.hpp``:
+
+.. code-block:: c++
 
   // macros.hpp
   ...
@@ -81,7 +87,7 @@ custom macro ``JSON_BASED_CLASS`` which is defined in an other header
   };
   ...
 
-::
+.. code-block:: c++
 
   // complex_class.hpp
   #pragma once
@@ -90,13 +96,17 @@ custom macro ``JSON_BASED_CLASS`` which is defined in an other header
 
 Since ``complex_class.hpp`` doesn't contain a ``Q_OBJECT`` macro it would be
 ignored by :prop_tgt:`AUTOMOC`.  We change this by adding ``JSON_BASED_CLASS``
-to :variable:`CMAKE_AUTOMOC_MACRO_NAMES`::
+to :variable:`CMAKE_AUTOMOC_MACRO_NAMES`:
+
+.. code-block:: cmake
 
   list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "JSON_BASED_CLASS")
 
 We want the ``moc`` file of ``complex_class.hpp`` to depend on
 ``meta.json``.  So we add a filter to
-:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS`::
+:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS`:
+
+.. code-block:: cmake
 
   list(APPEND CMAKE_AUTOMOC_DEPEND_FILTERS
     "JSON_BASED_CLASS"
@@ -104,6 +114,8 @@ We want the ``moc`` file of ``complex_class.hpp`` to depend on
   )
 
 Additionally we assume ``meta.json`` is :prop_sf:`GENERATED` which is
-why we have to add it to :prop_tgt:`AUTOGEN_TARGET_DEPENDS`::
+why we have to add it to :prop_tgt:`AUTOGEN_TARGET_DEPENDS`:
+
+.. code-block:: cmake
 
   set_property(TARGET my_target APPEND PROPERTY AUTOGEN_TARGET_DEPENDS "meta.json")

Help/prop_tgt/IMPLICIT_DEPENDS_INCLUDE_TRANSFORM.rst

@@ -17,13 +17,13 @@ replaced by the value given with the macro argument substituted for
 
 will convert lines of the form
 
-::
+.. code-block:: c
 
   #include MYDIR(myheader.h)
 
 to
 
-::
+.. code-block:: c
 
   #include <mydir/myheader.h>
 

Help/prop_tgt/INTERFACE_LINK_LIBRARIES_DIRECT.rst

@@ -95,12 +95,16 @@ One may limit the effects of ``INTERFACE_LINK_LIBRARIES_DIRECT`` and
 ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` to a subset of dependent
 targets by using the :genex:`TARGET_PROPERTY` generator expression.
 For example, to limit the effects to executable targets, use an
-entry of the form::
+entry of the form:
+
+.. code-block:: cmake
 
   "$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>:...>"
 
 Similarly, to limit the effects to specific targets, use an entry
-of the form::
+of the form:
+
+.. code-block:: cmake
 
   "$<$<BOOL:$<TARGET_PROPERTY:USE_IT>>:...>"
 

Help/release/3.0.rst

@@ -50,7 +50,9 @@ Syntax
 
 * The CMake language has been extended with
   :ref:`Bracket Argument` and  :ref:`Bracket Comment`
-  syntax inspired by Lua long brackets::
+  syntax inspired by Lua long brackets:
+
+  .. code-block:: cmake
 
     set(x [===[bracket argument]===] #[[bracket comment]])
 

Help/release/3.1.rst

@@ -336,17 +336,23 @@ Deprecated and Removed Features
 * In CMake 3.0 the :command:`target_link_libraries` command
   accidentally began allowing unquoted arguments to use
   :manual:`generator expressions <cmake-generator-expressions(7)>`
-  containing a (``;`` separated) list within them.  For example::
+  containing a (``;`` separated) list within them.  For example:
+
+  .. code-block:: cmake
 
     set(libs B C)
     target_link_libraries(A PUBLIC $<BUILD_INTERFACE:${libs}>)
 
-  This is equivalent to writing::
+  This is equivalent to writing:
+
+  .. code-block:: cmake
 
     target_link_libraries(A PUBLIC $<BUILD_INTERFACE:B C>)
 
   and was never intended to work.  It did not work in CMake 2.8.12.
-  Such generator expressions should be in quoted arguments::
+  Such generator expressions should be in quoted arguments:
+
+  .. code-block:: cmake
 
     set(libs B C)
     target_link_libraries(A PUBLIC "$<BUILD_INTERFACE:${libs}>")
@@ -356,14 +362,18 @@ Deprecated and Removed Features
 * Prior to CMake 3.1 the Makefile generators did not escape ``#``
   correctly inside make variable assignments used in generated
   makefiles, causing them to be treated as comments.  This made
-  code like::
+  code like:
+
+  .. code-block:: cmake
 
     add_compile_options(-Wno-#pragma-messages)
 
   not work in Makefile generators, but work in other generators.
   Now it is escaped correctly, making the behavior consistent
   across generators.  However, some projects may have tried to
-  workaround the original bug with code like::
+  workaround the original bug with code like:
+
+  .. code-block:: cmake
 
     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-\\#pragma-messages")
 

Help/variable/CMAKE_AUTOMOC_MACRO_NAMES.rst

@@ -16,7 +16,9 @@ The default value is ``Q_OBJECT;Q_GADGET;Q_NAMESPACE;Q_NAMESPACE_EXPORT``.
 Example
 ^^^^^^^
 Let CMake know that source files that contain ``CUSTOM_MACRO`` must be ``moc``
-processed as well::
+processed as well:
+
+.. code-block:: cmake
 
   set(CMAKE_AUTOMOC ON)
   list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "CUSTOM_MACRO")

Help/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_PREFIX.rst

@@ -9,6 +9,8 @@ path prefixing the toolchain GNU compiler and its binutils.
 See also :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX`
 and :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE`.
 
-For example, the path to the linker is::
+For example, the path to the linker is:
+
+.. code-block:: cmake
 
   ${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}ld${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}

Help/variable/CPACK_PACKAGING_INSTALL_PREFIX.rst

@@ -7,7 +7,7 @@ Each CPack generator has a default value (like ``/usr``).  This default
 value may be overwritten from the ``CMakeLists.txt`` or the :manual:`cpack(1)`
 command line by setting an alternative value.  Example:
 
-::
+.. code-block:: cmake
 
   set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")
 

Help/variable/CPACK_SET_DESTDIR.rst

@@ -9,7 +9,7 @@ basic relocation mechanism that should not be used on Windows (see
 :variable:`CMAKE_INSTALL_PREFIX` documentation).  It is usually invoked like
 this:
 
-::
+.. code-block:: sh
 
  make DESTDIR=/home/john install
 

Modules/CMakeAddFortranSubdirectory.cmake

@@ -18,7 +18,7 @@ built into a dll, so :variable:`BUILD_SHARED_LIBS` is turned on in
 the project.  In addition the :variable:`CMAKE_GNUtoMS` option is set
 to on, so that Microsoft ``.lib`` files are created.  Usage is as follows:
 
-::
+.. code-block:: cmake
 
   cmake_add_fortran_subdirectory(
    <subdir>                # name of subdirectory

Modules/CMakeDetermineVSServicePack.cmake

@@ -15,7 +15,9 @@ the compiler version number.
 
 Determine the Visual Studio service pack of the 'cl' in use.
 
-Usage::
+Usage:
+
+.. code-block:: cmake
 
   if(MSVC)
     include(CMakeDetermineVSServicePack)

Modules/CMakeExpandImportedTargets.cmake

@@ -20,7 +20,7 @@ behavior or use of the :prop_tgt:`INTERFACE_LINK_LIBRARIES` property
 because :manual:`generator expressions <cmake-generator-expressions(7)>`
 cannot be evaluated during configuration.
 
-::
+.. code-block:: cmake
 
  CMAKE_EXPAND_IMPORTED_TARGETS(<var> LIBRARIES lib1 lib2...libN
                                [CONFIGURATION <config>])
@@ -33,7 +33,7 @@ respective configuration of the imported targets if it exists.  If no
 CONFIGURATION is given, it uses the first configuration from
 ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}.
 
-::
+.. code-block:: cmake
 
     cmake_expand_imported_targets(expandedLibs
       LIBRARIES ${CMAKE_REQUIRED_LIBRARIES}

Modules/CMakeFindDependencyMacro.cmake

@@ -8,7 +8,9 @@ CMakeFindDependencyMacro
 .. command:: find_dependency
 
   The ``find_dependency()`` macro wraps a :command:`find_package` call for
-  a package dependency::
+  a package dependency:
+
+  .. code-block:: cmake
 
     find_dependency(<dep> [...])
 

Modules/CMakeForceCompiler.cmake

@@ -27,7 +27,7 @@ toolchain file instead.
 
 Macro ``CMAKE_FORCE_C_COMPILER`` has the following signature:
 
-::
+.. code-block:: cmake
 
    CMAKE_FORCE_C_COMPILER(<compiler> <compiler-id>)
 
@@ -39,7 +39,7 @@ compiler information tests.
 
 Macro ``CMAKE_FORCE_CXX_COMPILER`` has the following signature:
 
-::
+.. code-block:: cmake
 
    CMAKE_FORCE_CXX_COMPILER(<compiler> <compiler-id>)
 
@@ -51,7 +51,7 @@ compiler information tests.
 
 Macro ``CMAKE_FORCE_Fortran_COMPILER`` has the following signature:
 
-::
+.. code-block:: cmake
 
    CMAKE_FORCE_Fortran_COMPILER(<compiler> <compiler-id>)
 
@@ -63,7 +63,7 @@ compiler information tests.
 
 So a simple toolchain file could look like this:
 
-::
+.. code-block:: cmake
 
    include (CMakeForceCompiler)
    set(CMAKE_SYSTEM_NAME Generic)

Modules/CMakePackageConfigHelpers.cmake

@@ -13,7 +13,9 @@ Generating a Package Configuration File
 
 .. command:: configure_package_config_file
 
- Create a config file for a project::
+ Create a config file for a project:
+
+ .. code-block:: cmake
 
    configure_package_config_file(<input> <output>
      INSTALL_DESTINATION <path>
@@ -132,7 +134,9 @@ Generating a Package Version File
 
 .. command:: write_basic_package_version_file
 
- Create a version file for a project::
+ Create a version file for a project:
+
+ .. code-block:: cmake
 
    write_basic_package_version_file(<filename>
      [VERSION <major.minor.patch>]
@@ -394,6 +398,7 @@ Example using both the :command:`configure_package_config_file` and
    set_and_check(FOO_SYSCONFIG_DIR "@PACKAGE_SYSCONFIG_INSTALL_DIR@")
 
    check_required_components(Foo)
+
 #]=======================================================================]
 
 include(WriteBasicConfigVersionFile)

Modules/CPack.cmake

@@ -176,7 +176,9 @@ installers.  The most commonly-used variables are:
 
   The name of the package file to generate, not including the
   extension.  For example, ``cmake-2.6.1-Linux-i686``.  The default value
-  is::
+  is:
+
+  .. code-block:: cmake
 
     ${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}
 
@@ -197,7 +199,9 @@ installers.  The most commonly-used variables are:
   .. versionadded:: 3.7
 
   An algorithm that will be used to generate an additional file with the
-  checksum of the package.  The output file name will be::
+  checksum of the package.  The output file name will be:
+
+  .. code-block:: cmake
 
     ${CPACK_PACKAGE_FILE_NAME}.${CPACK_PACKAGE_CHECKSUM}
 

Modules/CPackComponent.cmake

@@ -47,7 +47,9 @@ The following variables influence the component-specific packaging:
  list. The :command:`get_cmake_property` command can be used to obtain the
  ``COMPONENTS`` property, then the :command:`list(REMOVE_ITEM)` command can be
  used to remove the unwanted ones. For example, to use all defined components
- except ``foo`` and ``bar``::
+ except ``foo`` and ``bar``:
+
+ .. code-block:: cmake
 
    get_cmake_property(CPACK_COMPONENTS_ALL COMPONENTS)
    list(REMOVE_ITEM CPACK_COMPONENTS_ALL "foo" "bar")
@@ -113,7 +115,7 @@ Add component
 
 Describe an installation component.
 
-::
+.. code-block:: cmake
 
   cpack_add_component(compname
                       [DISPLAY_NAME name]
@@ -190,7 +192,7 @@ Add component group
 
 Describes a group of related CPack installation components.
 
-::
+.. code-block:: cmake
 
   cpack_add_component_group(groupname
                            [DISPLAY_NAME name]
@@ -242,7 +244,7 @@ Add installation type
 Add a new installation type containing
 a set of predefined component selections to the graphical installer.
 
-::
+.. code-block:: cmake
 
   cpack_add_install_type(typename
                          [DISPLAY_NAME name])
@@ -269,7 +271,7 @@ Configure downloads
 Configure CPack to download
 selected components on-the-fly as part of the installation process.
 
-::
+.. code-block:: cmake
 
   cpack_configure_downloads(site
                             [UPLOAD_DIRECTORY dirname]

Modules/CPackIFW.cmake

@@ -23,7 +23,7 @@ The module defines the following commands:
 
   Sets the arguments specific to the CPack IFW generator.
 
-  ::
+  .. code-block:: cmake
 
     cpack_ifw_configure_component(<compname> [COMMON] [ESSENTIAL] [VIRTUAL]
                         [FORCED_INSTALLATION] [REQUIRES_ADMIN_RIGHTS]
@@ -176,7 +176,7 @@ The module defines the following commands:
 
   Sets the arguments specific to the CPack IFW generator.
 
-  ::
+  .. code-block:: cmake
 
     cpack_ifw_configure_component_group(<groupname> [VIRTUAL]
                         [FORCED_INSTALLATION] [REQUIRES_ADMIN_RIGHTS]
@@ -317,7 +317,7 @@ The module defines the following commands:
 
   Add QtIFW specific remote repository to binary installer.
 
-  ::
+  .. code-block:: cmake
 
     cpack_ifw_add_repository(<reponame> [DISABLED]
                         URL <url>
@@ -350,7 +350,7 @@ The module defines the following commands:
 
   Update QtIFW specific repository from remote repository.
 
-  ::
+  .. code-block:: cmake
 
     cpack_ifw_update_repository(<reponame>
                         [[ADD|REMOVE] URL <url>]|
@@ -387,7 +387,7 @@ The module defines the following commands:
 
   Add additional resources in the installer binary.
 
-  ::
+  .. code-block:: cmake
 
     cpack_ifw_add_package_resources(<file_path> <file_path> ...)
 

Modules/CPackIFWConfigureFile.cmake

@@ -20,7 +20,7 @@ The module defines the following commands:
 
   Copy a file to another location and modify its contents.
 
-  ::
+  .. code-block:: cmake
 
     cpack_ifw_configure_file(<input> <output>)
 

Modules/CSharpUtilities.cmake

@@ -32,7 +32,9 @@ Main functions provided by the module
 .. command:: csharp_set_windows_forms_properties
 
   Sets source file properties for use of Windows Forms. Use this, if your CSharp
-  target uses Windows Forms::
+  target uses Windows Forms:
+
+  .. code-block:: cmake
 
     csharp_set_windows_forms_properties([<file1> [<file2> [...]]])
 
@@ -64,7 +66,9 @@ Main functions provided by the module
   Sets source file properties of ``.Designer.cs`` files depending on
   sibling filenames. Use this, if your CSharp target does **not**
   use Windows Forms (for Windows Forms use
-  :command:`csharp_set_windows_forms_properties` instead)::
+  :command:`csharp_set_windows_forms_properties` instead):
+
+  .. code-block:: cmake
 
     csharp_set_designer_cs_properties([<file1> [<file2> [...]]])
 
@@ -101,7 +105,9 @@ Main functions provided by the module
 .. command:: csharp_set_xaml_cs_properties
 
   Sets source file properties for use of Windows Presentation Foundation (WPF) and
-  XAML. Use this, if your CSharp target uses WPF/XAML::
+  XAML. Use this, if your CSharp target uses WPF/XAML:
+
+  .. code-block:: cmake
 
     csharp_set_xaml_cs_properties([<file1> [<file2> [...]]])
 
@@ -125,7 +131,9 @@ Helper functions which are used by the above ones
 
   Helper function which computes a list of key values to identify
   source files independently of relative/absolute paths given in cmake
-  and eliminates case sensitivity::
+  and eliminates case sensitivity:
+
+  .. code-block:: cmake
 
     csharp_get_filename_keys(OUT [<file1> [<file2> [...]]])
 
@@ -158,7 +166,9 @@ Helper functions which are used by the above ones
 
   Returns the full filepath and name **without** extension of a key.
   KEY is expected to be a key from csharp_get_filename_keys. In BASE
-  the value of KEY without the file extension is returned::
+  the value of KEY without the file extension is returned:
+
+  .. code-block:: cmake
 
     csharp_get_filename_key_base(BASE KEY)
 
@@ -172,7 +182,9 @@ Helper functions which are used by the above ones
 .. command:: csharp_get_dependentupon_name
 
   Computes a string which can be used as value for the source file property
-  :prop_sf:`VS_CSHARP_<tagname>` with *target* being ``DependentUpon``::
+  :prop_sf:`VS_CSHARP_<tagname>` with *target* being ``DependentUpon``:
+
+  .. code-block:: cmake
 
     csharp_get_dependentupon_name(NAME FILE)
 

Modules/CTestCoverageCollectGCOV.cmake

@@ -24,7 +24,7 @@ After generating this tar file, it can be sent to CDash for display with the
 
 .. command:: ctest_coverage_collect_gcov
 
-  ::
+  .. code-block:: cmake
 
     ctest_coverage_collect_gcov(TARBALL <tarfile>
       [SOURCE <source_dir>][BUILD <build_dir>]

Modules/CheckPIESupported.cmake

@@ -14,7 +14,7 @@ property for executables will be honored at link time.
 
 .. command:: check_pie_supported
 
-  ::
+  .. code-block:: cmake
 
     check_pie_supported([OUTPUT_VARIABLE <output>]
                         [LANGUAGES <lang>...])

Modules/Dart.cmake

@@ -18,7 +18,7 @@ submissions as well as testing with CTest.  This module should be
 included in the CMakeLists.txt file at the top of a project.  Typical
 usage:
 
-::
+.. code-block:: cmake
 
   include(Dart)
   if(BUILD_TESTING)

Modules/DeployQt4.cmake

@@ -24,13 +24,13 @@ The following functions are provided by this module:
 Requires CMake 2.6 or greater because it uses function and
 PARENT_SCOPE.  Also depends on BundleUtilities.cmake.
 
-::
+.. code-block:: cmake
 
   write_qt4_conf(<qt_conf_dir> <qt_conf_contents>)
 
 Writes a qt.conf file with the <qt_conf_contents> into <qt_conf_dir>.
 
-::
+.. code-block:: cmake
 
   resolve_qt4_paths(<paths_var> [<executable_path>])
 
@@ -38,7 +38,7 @@ Loop through <paths_var> list and if any don't exist resolve them
 relative to the <executable_path> (if supplied) or the
 CMAKE_INSTALL_PREFIX.
 
-::
+.. code-block:: cmake
 
   fixup_qt4_executable(<executable>
     [<qtplugins> <libs> <dirs> <plugins_dir> <request_qt_conf>])
@@ -65,7 +65,7 @@ directories to be searched to find library dependencies.
 <request_qt_conf> will force a qt.conf file to be written even if not
 needed.
 
-::
+.. code-block:: cmake
 
   install_qt4_plugin_path(plugin executable copy installed_plugin_path_var
                           <plugins_dir> <component> <configurations>)
@@ -80,7 +80,7 @@ rather than install time.
 
 If <component> is set then anything installed will use this COMPONENT.
 
-::
+.. code-block:: cmake
 
   install_qt4_plugin(plugin executable copy installed_plugin_path_var
                      <plugins_dir> <component>)
@@ -90,7 +90,7 @@ directory (or <plugins_dir>) relative to <executable> and store the
 result in <installed_plugin_path_var>.  See documentation of
 INSTALL_QT4_PLUGIN_PATH.
 
-::
+.. code-block:: cmake
 
   install_qt4_executable(<executable>
     [<qtplugins> <libs> <dirs> <plugins_dir> <request_qt_conf> <component>])

Modules/ExternalData.cmake

@@ -47,7 +47,9 @@ Module Functions
 .. command:: ExternalData_Expand_Arguments
 
   The ``ExternalData_Expand_Arguments`` function evaluates ``DATA{}``
-  references in its arguments and constructs a new list of arguments::
+  references in its arguments and constructs a new list of arguments:
+
+  .. code-block:: cmake
 
     ExternalData_Expand_Arguments(
       <target>   # Name of data management target
@@ -62,7 +64,9 @@ Module Functions
 
   The ``ExternalData_Add_Test`` function wraps around the CMake
   :command:`add_test` command but supports ``DATA{}`` references in
-  its arguments::
+  its arguments:
+
+  .. code-block:: cmake
 
     ExternalData_Add_Test(
       <target>   # Name of data management target
@@ -81,7 +85,9 @@ Module Functions
 .. command:: ExternalData_Add_Target
 
   The ``ExternalData_Add_Target`` function creates a custom target to
-  manage local instances of data files stored externally::
+  manage local instances of data files stored externally:
+
+  .. code-block:: cmake
 
     ExternalData_Add_Target(
       <target>                  # Name of data management target

Modules/FindArmadillo.cmake

@@ -13,7 +13,7 @@ Armadillo is a library for linear algebra & scientific computing.
 
 Using Armadillo:
 
-::
+.. code-block:: cmake
 
   find_package(Armadillo REQUIRED)
   include_directories(${ARMADILLO_INCLUDE_DIRS})

Modules/FindBacktrace.cmake

@@ -28,7 +28,9 @@ The following cache variables are also available to set or use:
   The directory holding the ``backtrace(3)`` header.
 
 Typical usage is to generate of header file using :command:`configure_file`
-with the contents like the following::
+with the contents like the following:
+
+.. code-block:: c
 
  #cmakedefine01 Backtrace_FOUND
  #if Backtrace_FOUND

Modules/FindCUDA.cmake

@@ -308,9 +308,11 @@ Values for ``target_CUDA_architecture``:
 Returns list of flags to be added to ``CUDA_NVCC_FLAGS`` in ``<out_variable>``.
 Additionally, sets ``<out_variable>_readable`` to the resulting numeric list.
 
-Example::
+Example:
 
-  cuda_select_nvcc_arch_flags(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
+.. code-block:: cmake
+
+  cuda_select_nvcc_arch_flags(ARCH_FLAGS "3.0" "3.5+PTX" "5.2(5.0)" "Maxwell")
   list(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})
 
 More info on CUDA architectures: https://en.wikipedia.org/wiki/CUDA.

Modules/FindCVS.cmake

@@ -16,7 +16,7 @@ The module defines the following variables:
 
 Example usage:
 
-::
+.. code-block:: cmake
 
    find_package(CVS)
    if(CVS_FOUND)

Modules/FindCxxTest.cmake

@@ -68,7 +68,9 @@ Module Commands
 
 .. command:: cxxtest_add_test
 
-  Create a CxxTest runner and adds it to the CTest testing suite::
+  Create a CxxTest runner and adds it to the CTest testing suite:
+
+  .. code-block:: cmake
 
     CXXTEST_ADD_TEST(<test_name> <gen_source_file>
                      <input_files_to_testgen>...)

Modules/FindDoxygen.cmake

@@ -69,7 +69,7 @@ Functions
   ability to customize the Doxygen configuration used to build the
   documentation.
 
-  ::
+  .. code-block:: cmake
 
     doxygen_add_docs(targetName
         [filesOrDirs...]

Modules/FindGTest.cmake

@@ -77,7 +77,7 @@ The following cache variables may also be set:
 Example usage
 ^^^^^^^^^^^^^
 
-::
+.. code-block:: cmake
 
     enable_testing()
     find_package(GTest REQUIRED)

Modules/FindHg.cmake

@@ -18,7 +18,7 @@ The module defines the following variables:
 .. versionadded:: 3.1
   If the command line client executable is found the following macro is defined:
 
-::
+.. code-block:: cmake
 
   HG_WC_INFO(<dir> <var-prefix>)
 
@@ -32,7 +32,7 @@ at a given location.  This macro defines the following variables:
 
 Example usage:
 
-::
+.. code-block:: cmake
 
    find_package(Hg)
    if(HG_FOUND)

Modules/FindJava.cmake

@@ -73,7 +73,7 @@ For these components the following variables are set:
 
 Example Usages:
 
-::
+.. code-block:: cmake
 
   find_package(Java)
   find_package(Java 1.8 REQUIRED)

Modules/FindLATEX.cmake

@@ -50,7 +50,9 @@ Possible components are::
   LATEX2HTML
   HTLATEX
 
-Example Usages::
+Example Usages:
+
+.. code-block:: cmake
 
   find_package(LATEX)
   find_package(LATEX COMPONENTS PDFLATEX)

Modules/FindLua.cmake

@@ -29,13 +29,13 @@ This module defines:
 
 Note that the expected include convention is
 
-::
+.. code-block:: c
 
   #include "lua.h"
 
 and not
 
-::
+.. code-block:: c
 
   #include <lua/lua.h>
 

Modules/FindLua50.cmake

@@ -13,11 +13,15 @@ This module defines::
   LUA_LIBRARIES, both lua and lualib
   LUA_INCLUDE_DIR, where to find lua.h and lualib.h (and probably lauxlib.h)
 
-Note that the expected include convention is::
+Note that the expected include convention is:
+
+.. code-block:: c
 
   #include "lua.h"
 
-and not::
+and not:
+
+.. code-block:: c
 
   #include <lua/lua.h>
 

Modules/FindLua51.cmake

@@ -14,11 +14,15 @@ This module defines::
   LUA_VERSION_STRING, the version of Lua found (since CMake 2.8.8)
 
 
-Note that the expected include convention is::
+Note that the expected include convention is:
+
+.. code-block:: c
 
   #include "lua.h"
 
-and not::
+and not:
+
+.. code-block:: c
 
   #include <lua/lua.h>
 

Modules/FindMPI.cmake

@@ -207,7 +207,7 @@ Usage of mpiexec
 When using ``MPIEXEC_EXECUTABLE`` to execute MPI applications, you should typically
 use all of the ``MPIEXEC_EXECUTABLE`` flags as follows:
 
-::
+.. code-block:: cmake
 
    ${MPIEXEC_EXECUTABLE} ${MPIEXEC_NUMPROC_FLAG} ${MPIEXEC_MAX_NUMPROCS}
      ${MPIEXEC_PREFLAGS} EXECUTABLE ${MPIEXEC_POSTFLAGS} ARGS

Modules/FindMatlab.cmake

@@ -278,7 +278,9 @@ Reference
 
   If set, specifies additional versions of Matlab that may be looked for.
   The variable should be a list of strings, organized by pairs of release
-  name and versions, such as follows::
+  name and versions, such as follows:
+
+  .. code-block:: cmake
 
     set(MATLAB_ADDITIONAL_VERSIONS
         "release_name1=corresponding_version1"
@@ -286,7 +288,9 @@ Reference
         ...
         )
 
-  Example::
+  Example:
+
+  .. code-block:: cmake
 
     set(MATLAB_ADDITIONAL_VERSIONS
         "R2013b=8.2"

Modules/FindOpenSceneGraph.cmake

@@ -87,7 +87,7 @@ This module defines the following output variables:
 
 ================================== Example Usage:
 
-::
+.. code-block:: cmake
 
   find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgUtil)
       # libOpenThreads & libosg automatically searched
@@ -95,7 +95,7 @@ This module defines the following output variables:
 
 
 
-::
+.. code-block:: cmake
 
   add_executable(foo foo.cc)
   target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})

Modules/FindProtobuf.cmake

@@ -106,7 +106,9 @@ Example:
 
 .. command:: protobuf_generate_cpp
 
-  Add custom commands to process ``.proto`` files to C++::
+  Add custom commands to process ``.proto`` files to C++:
+
+  .. code-block:: cmake
 
     protobuf_generate_cpp (
       <srcs-var> <hdrs-var>
@@ -135,7 +137,9 @@ Example:
 
   .. versionadded:: 3.4
 
-  Add custom commands to process ``.proto`` files to Python::
+  Add custom commands to process ``.proto`` files to Python:
+
+  .. code-block:: cmake
 
     protobuf_generate_python (<py-srcs-var> [<proto-file>...])
 
@@ -149,7 +153,9 @@ Example:
 
   .. versionadded:: 3.13
 
-  Automatically generate source files from ``.proto`` schema files at build time::
+  Automatically generate source files from ``.proto`` schema files at build time:
+
+  .. code-block:: cmake
 
     protobuf_generate (
         TARGET <target>
@@ -230,7 +236,9 @@ Example:
     Command name, path, or CMake executable used to generate protobuf bindings.
     If omitted, ``protobuf::protoc`` is used.
 
-  Example::
+  Example:
+
+  .. code-block:: cmake
 
     find_package(gRPC CONFIG REQUIRED)
     find_package(Protobuf REQUIRED)

Modules/FindPython.cmake

@@ -50,7 +50,9 @@ If component ``Development`` is specified, it implies sub-components
 
 To ensure consistent versions between components ``Interpreter``, ``Compiler``,
 ``Development`` (or one of its sub-components) and ``NumPy``, specify all
-components at the same time::
+components at the same time:
+
+.. code-block:: cmake
 
   find_package (Python COMPONENTS Interpreter Development)
 
@@ -340,14 +342,18 @@ Hints
   ``pydebug`` and ``gil_disabled``, ``debug`` and ``free threaded`` versions
   will be searched **after** ``non-debug`` and ``non-gil-disabled`` ones.
 
-  For example, if we have::
+  For example, if we have:
+
+  .. code-block:: cmake
 
     set (Python_FIND_ABI "ON" "ANY" "ANY" "ON")
 
   The following flags combinations will be appended, in that order, to the
   artifact names: ``tdmu``, ``tdm``, ``tdu``, and ``td``.
 
-  And to search any possible ABIs::
+  And to search any possible ABIs:
+
+  .. code-block:: cmake
 
     set (Python_FIND_ABI "ANY" "ANY" "ANY" "ANY")
 
@@ -592,7 +598,9 @@ This module defines the command ``Python_add_library`` (when
 :command:`add_library` and adds a dependency to target ``Python::Python`` or,
 when library type is ``MODULE``, to target ``Python::Module`` or
 ``Python::SABIModule`` (when ``USE_SABI`` option is specified) and takes care
-of Python module naming rules::
+of Python module naming rules:
+
+.. code-block:: cmake
 
   Python_add_library (<name> [STATIC | SHARED | MODULE [USE_SABI <version>] [WITH_SOABI]]
                       <source1> [<source2> ...])

Modules/FindPython2.cmake

@@ -43,7 +43,9 @@ If component ``Development`` is specified, it implies sub-components
 
 To ensure consistent versions between components ``Interpreter``, ``Compiler``,
 ``Development`` (or one of its sub-components) and ``NumPy``, specify all
-components at the same time::
+components at the same time:
+
+.. code-block:: cmake
 
   find_package (Python2 COMPONENTS Interpreter Development)
 
@@ -472,7 +474,9 @@ This module defines the command ``Python2_add_library`` (when
 :prop_gbl:`CMAKE_ROLE` is ``PROJECT``), which has the same semantics as
 :command:`add_library` and adds a dependency to target ``Python2::Python`` or,
 when library type is ``MODULE``, to target ``Python2::Module`` and takes care
-of Python module naming rules::
+of Python module naming rules:
+
+.. code-block:: cmake
 
   Python2_add_library (<name> [STATIC | SHARED | MODULE]
                        <source1> [<source2> ...])

Modules/FindPython3.cmake

@@ -50,7 +50,9 @@ If component ``Development`` is specified, it implies sub-components
 
 To ensure consistent versions between components ``Interpreter``, ``Compiler``,
 ``Development`` (or one of its sub-components) and ``NumPy``, specify all
-components at the same time::
+components at the same time:
+
+.. code-block:: cmake
 
   find_package (Python3 COMPONENTS Interpreter Development)
 
@@ -338,14 +340,18 @@ Hints
   ``pydebug`` and ``gil_disabled``, ``debug`` and ``free threaded`` versions
   will be searched **after** ``non-debug`` and ``non-gil-disabled`` ones.
 
-  For example, if we have::
+  For example, if we have:
+
+  .. code-block:: cmake
 
     set (Python3_FIND_ABI "ON" "ANY" "ANY" "ON")
 
   The following flags combinations will be appended, in that order, to the
   artifact names: ``tdmu``, ``tdm``, ``tdu``, and ``td``.
 
-  And to search any possible ABIs::
+  And to search any possible ABIs:
+
+  .. code-block:: cmake
 
     set (Python3_FIND_ABI "ANY" "ANY" "ANY" "ANY")
 
@@ -590,7 +596,9 @@ This module defines the command ``Python3_add_library`` (when
 :command:`add_library` and adds a dependency to target ``Python3::Python`` or,
 when library type is ``MODULE``, to target ``Python3::Module`` or
 ``Python3::SABIModule`` (when ``USE_SABI`` option is specified) and takes care
-of Python module naming rules::
+of Python module naming rules:
+
+.. code-block:: cmake
 
   Python3_add_library (<name> [STATIC | SHARED | MODULE [USE_SABI <version>] [WITH_SOABI]]
                        <source1> [<source2> ...])

Modules/FindSquish.cmake

@@ -41,7 +41,7 @@ This module can be used to find Squish.
 It provides the function squish_add_test() for adding a squish test
 to cmake using Squish >= 4.x:
 
-::
+.. code-block:: cmake
 
    squish_add_test(cmakeTestName
      AUT targetName SUITE suiteName TEST squishTestName
@@ -74,7 +74,7 @@ The arguments have the following meaning:
 
 
 
-::
+.. code-block:: cmake
 
    enable_testing()
    find_package(Squish 6.5)
@@ -93,14 +93,14 @@ The arguments have the following meaning:
 For users of Squish version 3.x the macro squish_v3_add_test() is
 provided:
 
-::
+.. code-block:: cmake
 
    squish_v3_add_test(testName applicationUnderTest testCase envVars testWrapper)
    Use this macro to add a test using Squish 3.x.
 
 
 
-::
+.. code-block:: cmake
 
   enable_testing()
   find_package(Squish 3.0)

Modules/FindSubversion.cmake

@@ -23,7 +23,7 @@ standard syntax, e.g. ``find_package(Subversion 1.4)``.
 
 If the command line client executable is found two macros are defined:
 
-::
+.. code-block:: cmake
 
   Subversion_WC_INFO(<dir> <var-prefix> [IGNORE_SVN_FAILURE])
   Subversion_WC_LOG(<dir> <var-prefix>)
@@ -57,7 +57,7 @@ subversion working copy at a given location.  This macro defines the variable:
 
 Example usage:
 
-::
+.. code-block:: cmake
 
   find_package(Subversion)
   if(SUBVERSION_FOUND)

Modules/FindXCTest.cmake

@@ -22,7 +22,9 @@ Module Functions
 
   The ``xctest_add_bundle`` function creates a XCTest bundle named
   <target> which will test the target <testee>. Supported target types
-  for testee are Frameworks and App Bundles::
+  for testee are Frameworks and App Bundles:
+
+  .. code-block:: cmake
 
     xctest_add_bundle(
       <target>  # Name of the XCTest bundle
@@ -33,7 +35,9 @@ Module Functions
 
   The ``xctest_add_test`` function adds an XCTest bundle to the
   project to be run by :manual:`ctest(1)`. The test will be named
-  <name> and tests <bundle>::
+  <name> and tests <bundle>:
+
+  .. code-block:: cmake
 
     xctest_add_test(
       <name>    # Test name

Modules/FindXMLRPC.cmake

@@ -27,7 +27,7 @@ Modules may be listed by running "xmlrpc-c-config".  Modules include:
 
 Typical usage:
 
-::
+.. code-block:: cmake
 
   find_package(XMLRPC REQUIRED libwww-client)
 #]=======================================================================]

Modules/FindwxWidgets.cmake

@@ -58,7 +58,7 @@ options that need to be passed to the wx-config utility.  For example,
 to use the base toolkit found in the /usr/local path, set the variable
 (before calling the FIND_PACKAGE command) as such:
 
-::
+.. code-block:: cmake
 
   set(wxWidgets_CONFIG_OPTIONS --toolkit=base --prefix=/usr)
 
@@ -93,7 +93,7 @@ and unix style:
 
 Sample usage:
 
-::
+.. code-block:: cmake
 
    # Note that for MinGW users the order of libs is important!
    find_package(wxWidgets COMPONENTS gl core base OPTIONAL_COMPONENTS net)
@@ -107,7 +107,7 @@ Sample usage:
 
 If wxWidgets is required (i.e., not an optional part):
 
-::
+.. code-block:: cmake
 
    find_package(wxWidgets REQUIRED gl core base OPTIONAL_COMPONENTS net)
    include(${wxWidgets_USE_FILE})

Modules/FindwxWindows.cmake

@@ -34,7 +34,7 @@ the name of the library is.  This code sets the following variables:
 
 OPTIONS If you need OpenGL support please
 
-::
+.. code-block:: cmake
 
   set(WXWINDOWS_USE_GL 1)
 
@@ -52,7 +52,7 @@ include(${CMAKE_CURRENT_LIST_DIR}/Use_wxWindows.cmake).
 
 USAGE
 
-::
+.. code-block:: cmake
 
   set(WXWINDOWS_USE_GL 1)
   find_package(wxWindows)

Modules/FortranCInterface.cmake

@@ -79,14 +79,18 @@ Module Functions
 .. command:: FortranCInterface_HEADER
 
   The ``FortranCInterface_HEADER`` function is provided to generate a
-  C header file containing macros to mangle symbol names::
+  C header file containing macros to mangle symbol names:
+
+  .. code-block:: cmake
 
     FortranCInterface_HEADER(<file>
                              [MACRO_NAMESPACE <macro-ns>]
                              [SYMBOL_NAMESPACE <ns>]
                              [SYMBOLS [<module>:]<function> ...])
 
-  It generates in ``<file>`` definitions of the following macros::
+  It generates in ``<file>`` definitions of the following macros:
+
+  .. code-block:: c
 
      #define FortranCInterface_GLOBAL (name,NAME) ...
      #define FortranCInterface_GLOBAL_(name,NAME) ...
@@ -125,7 +129,9 @@ Module Functions
 .. command:: FortranCInterface_VERIFY
 
   The ``FortranCInterface_VERIFY`` function is provided to verify
-  that the Fortran and C/C++ compilers work together::
+  that the Fortran and C/C++ compilers work together:
+
+  .. code-block:: cmake
 
     FortranCInterface_VERIFY([CXX] [QUIET])
 

Modules/GNUInstallDirs.cmake

@@ -131,7 +131,7 @@ Macros
 
 .. command:: GNUInstallDirs_get_absolute_install_dir
 
-  ::
+  .. code-block:: cmake
 
     GNUInstallDirs_get_absolute_install_dir(absvar var dirname)
 

Modules/GetPrerequisites.cmake

@@ -46,7 +46,7 @@ The following functions are provided by this module:
      (projects can override with gp_resolved_file_type_override)
    gp_file_type
 
-::
+.. code-block:: cmake
 
   GET_PREREQUISITES(<target> <prerequisites_var> <exclude_system> <recurse>
                     <exepath> <dirs> [<rpaths>])
@@ -72,7 +72,7 @@ locations, /usr/lib...
   The variable GET_PREREQUISITES_VERBOSE can be set to true to enable verbose
   output.
 
-::
+.. code-block:: cmake
 
   LIST_PREREQUISITES(<target> [<recurse> [<exclude_system> [<verbose>]]])
 
@@ -86,7 +86,7 @@ indicating whether to include or exclude "system" prerequisites.  With
 <verbose> set to 0 only the full path names of the prerequisites are
 printed, set to 1 extra information will be displayed.
 
-::
+.. code-block:: cmake
 
   LIST_PREREQUISITES_BY_GLOB(<glob_arg> <glob_exp>)
 
@@ -99,21 +99,21 @@ matching file is executable, its prerequisites are listed.
 Any additional (optional) arguments provided are passed along as the
 optional arguments to the list_prerequisites calls.
 
-::
+.. code-block:: cmake
 
   GP_APPEND_UNIQUE(<list_var> <value>)
 
 Append <value> to the list variable <list_var> only if the value is
 not already in the list.
 
-::
+.. code-block:: cmake
 
   IS_FILE_EXECUTABLE(<file> <result_var>)
 
 Return 1 in <result_var> if <file> is a binary executable, 0
 otherwise.
 
-::
+.. code-block:: cmake
 
   GP_ITEM_DEFAULT_EMBEDDED_PATH(<item> <default_embedded_path_var>)
 
@@ -123,7 +123,7 @@ is embedded inside a bundle.
 Override on a per-project basis by providing a project-specific
 gp_item_default_embedded_path_override function.
 
-::
+.. code-block:: cmake
 
   GP_RESOLVE_ITEM(<context> <item> <exepath> <dirs> <resolved_item_var>
                   [<rpaths>])
@@ -133,7 +133,7 @@ Resolve an item into an existing full path file.
 Override on a per-project basis by providing a project-specific
 gp_resolve_item_override function.
 
-::
+.. code-block:: cmake
 
   GP_RESOLVED_FILE_TYPE(<original_file> <file> <exepath> <dirs> <type_var>
                         [<rpaths>])
@@ -157,7 +157,7 @@ Possible types are:
 Override on a per-project basis by providing a project-specific
 gp_resolved_file_type_override function.
 
-::
+.. code-block:: cmake
 
   GP_FILE_TYPE(<original_file> <file> <type_var>)
 

Modules/GoogleTest.cmake

@@ -38,7 +38,9 @@ same as the Google Test name (i.e. ``suite.testcase``); see also
 .. command:: gtest_add_tests
 
   Automatically add tests with CTest by scanning source code for Google Test
-  macros::
+  macros:
+
+  .. code-block:: cmake
 
     gtest_add_tests(TARGET target
                     [SOURCES src1...]
@@ -127,7 +129,9 @@ same as the Google Test name (i.e. ``suite.testcase``); see also
     set_tests_properties(${noArgsTests}   PROPERTIES TIMEOUT 10)
     set_tests_properties(${withArgsTests} PROPERTIES TIMEOUT 20)
 
-  For backward compatibility, the following form is also supported::
+  For backward compatibility, the following form is also supported:
+
+  .. code-block:: cmake
 
     gtest_add_tests(exe args files...)
 
@@ -152,7 +156,9 @@ same as the Google Test name (i.e. ``suite.testcase``); see also
 .. command:: gtest_discover_tests
 
   Automatically add tests with CTest by querying the compiled test executable
-  for available tests::
+  for available tests:
+
+  .. code-block:: cmake
 
     gtest_discover_tests(target
                          [EXTRA_ARGS args...]

Modules/MacroAddFileDependencies.cmake

@@ -7,7 +7,7 @@ MacroAddFileDependencies
 
 .. deprecated:: 3.14
 
-::
+.. code-block:: cmake
 
   MACRO_ADD_FILE_DEPENDENCIES(<source> <files>...)
 

Modules/UseJava.cmake

@@ -39,7 +39,9 @@ Creating And Installing JARs
 
 .. command:: add_jar
 
-  Creates a jar file containing java objects and, optionally, resources::
+  Creates a jar file containing java objects and, optionally, resources:
+
+  .. code-block:: cmake
 
     add_jar(<target_name>
             [SOURCES] <source1> [<source2>...] [<resource1>...]
@@ -216,7 +218,9 @@ Creating And Installing JARs
 
 .. command:: install_jar
 
-  This command installs the jar file to the given destination::
+  This command installs the jar file to the given destination:
+
+  .. code-block:: cmake
 
    install_jar(<target_name> <destination>)
    install_jar(<target_name> DESTINATION <destination> [COMPONENT <component>])
@@ -246,7 +250,9 @@ Creating And Installing JARs
 
 .. command:: install_jni_symlink
 
-  Installs JNI symlinks for target generated by :ref:`add_jar() <add_jar>`::
+  Installs JNI symlinks for target generated by :ref:`add_jar() <add_jar>`:
+
+  .. code-block:: cmake
 
    install_jni_symlink(<target_name> <destination>)
    install_jni_symlink(<target_name> DESTINATION <destination> [COMPONENT <component>])
@@ -283,7 +289,9 @@ Header Generation
 
   .. versionadded:: 3.4
 
-  Generates C header files for java classes::
+  Generates C header files for java classes:
+
+  .. code-block:: cmake
 
    create_javah(TARGET <target> | GENERATED_FILES <VAR>
                 CLASSES <class>...
@@ -353,7 +361,9 @@ Exporting JAR Targets
 
   .. versionadded:: 3.7
 
-  Installs a target export file::
+  Installs a target export file:
+
+  .. code-block:: cmake
 
    install_jar_exports(TARGETS <jars>...
                        [NAMESPACE <namespace>]
@@ -390,7 +400,9 @@ Exporting JAR Targets
 
   .. versionadded:: 3.7
 
-  Writes a target export file::
+  Writes a target export file:
+
+  .. code-block:: cmake
 
    export_jars(TARGETS <jars>...
                [NAMESPACE <namespace>]
@@ -418,7 +430,9 @@ Finding JARs
 
 .. command:: find_jar
 
-  Finds the specified jar file::
+  Finds the specified jar file:
+
+  .. code-block:: cmake
 
     find_jar(<VAR>
              <name> | NAMES <name1> [<name2>...]
@@ -455,7 +469,9 @@ Creating Java Documentation
 
 .. command:: create_javadoc
 
-  Creates java documentation based on files and packages::
+  Creates java documentation based on files and packages:
+
+  .. code-block:: cmake
 
     create_javadoc(<VAR>
                    (PACKAGES <pkg1> [<pkg2>...] | FILES <file1> [<file2>...])

Modules/UseSWIG.cmake

@@ -21,7 +21,9 @@ The following command is defined for use with ``SWIG``:
 
   .. versionadded:: 3.8
 
-  Define swig module with given name and specified language::
+  Define swig module with given name and specified language:
+
+  .. code-block:: cmake
 
     swig_add_library(<name>
                      [TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>]
@@ -372,7 +374,9 @@ Deprecated Commands
     Use :command:`target_link_libraries` with the standard target name,
     or with ``${SWIG_MODULE_<name>_REAL_NAME}`` for legacy target naming.
 
-  Link libraries to swig module::
+  Link libraries to swig module:
+
+  .. code-block:: cmake
 
     swig_link_libraries(<name> <item>...)
 

Modules/UsewxWidgets.cmake

@@ -13,7 +13,7 @@ called.
 
 USAGE
 
-::
+.. code-block:: cmake
 
   # Note that for MinGW users the order of libs is important!
   find_package(wxWidgets REQUIRED net gl core base)

Modules/WriteBasicConfigVersionFile.cmake

@@ -10,7 +10,7 @@ WriteBasicConfigVersionFile
   Use the identical command :command:`write_basic_package_version_file()`
   from module :module:`CMakePackageConfigHelpers`.
 
-::
+.. code-block:: cmake
 
   WRITE_BASIC_CONFIG_VERSION_FILE( filename
     [VERSION major.minor.patch]

Modules/WriteCompilerDetectionHeader.cmake

@@ -14,7 +14,9 @@ WriteCompilerDetectionHeader
 This module provides the function ``write_compiler_detection_header()``.
 
 This function can be used to generate a file suitable for preprocessor
-inclusion which contains macros to be used in source code::
+inclusion which contains macros to be used in source code:
+
+.. code-block:: cmake
 
    write_compiler_detection_header(
              FILE <file>