1
0
mirror of https://github.com/Kitware/CMake.git synced 2025-10-14 02:08:27 +08:00

Help: More syntax highlighting for literal blocks

Covers almost all blocks containing actual code, except:

* Parsed-literal blocks can't be highlighted, including many command
  summaries and substitution-heavy docs like find_... commands.
  This is a Sphinx limitation.

* Code with errors, like CMP0049, DEPLOYMENT_ADDITIONAL_FILES,
  DEPLOYMENT_REMOTE_DIRECTORY, @PACKAGE_INIT@ substitution in the
  tutorial, bracket arguments/comments in cmake-language.7 and
  cmake-developer.7.

* FindQt4 module, which needs reformatting.
This commit is contained in:
Nikita Nemkin
2025-01-29 20:05:12 +05:00
committed by Brad King
parent e806a490b6
commit 9890cfc4ec
79 changed files with 339 additions and 176 deletions

View File

@@ -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>]

View File

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

View File

@@ -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...]]

View File

@@ -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")

View File

@@ -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.

View File

@@ -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

View File

@@ -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]

View File

@@ -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...>

View File

@@ -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

View File

@@ -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>)

View File

@@ -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)

View File

@@ -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 ")

View File

@@ -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)

View File

@@ -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)

View File

@@ -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 "")

View File

@@ -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)

View File

@@ -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>

View File

@@ -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

View File

@@ -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")

View File

@@ -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>

View File

@@ -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>>:...>"

View File

@@ -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]])

View File

@@ -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")

View File

@@ -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")

View File

@@ -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}

View File

@@ -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")

View File

@@ -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

View File

@@ -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

View File

@@ -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)

View File

@@ -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}

View File

@@ -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> [...])

View File

@@ -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)

View File

@@ -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)

View File

@@ -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}

View File

@@ -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]

View File

@@ -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> ...)

View File

@@ -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>)

View File

@@ -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)

View File

@@ -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>]

View File

@@ -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>...])

View File

@@ -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)

View File

@@ -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>])

View File

@@ -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

View File

@@ -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})

View File

@@ -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

View File

@@ -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.

View File

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

View File

@@ -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>...)

View File

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

View File

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

View File

@@ -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)

View File

@@ -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)

View File

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

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>

View File

@@ -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

View File

@@ -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"

View File

@@ -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})

View File

@@ -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)

View File

@@ -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> ...])

View File

@@ -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> ...])

View File

@@ -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> ...])

View File

@@ -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)

View File

@@ -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)

View File

@@ -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

View File

@@ -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)
#]=======================================================================]

View File

@@ -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})

View File

@@ -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)

View File

@@ -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])

View File

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

View File

@@ -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>)

View File

@@ -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...]

View File

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

View File

@@ -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>...])

View File

@@ -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>...)

View File

@@ -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)

View File

@@ -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]

View File

@@ -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>