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:
@@ -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>]
|
||||
|
@@ -12,7 +12,7 @@ Process pkg-config format package files.
|
||||
Synopsis
|
||||
^^^^^^^^
|
||||
|
||||
.. parsed-literal::
|
||||
.. code-block:: cmake
|
||||
|
||||
cmake_pkg_config(EXTRACT <package> [<version>] [...])
|
||||
|
||||
|
@@ -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...]]
|
||||
|
@@ -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")
|
||||
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
||||
|
@@ -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]
|
||||
|
@@ -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...>
|
||||
|
@@ -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
|
||||
|
@@ -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>)
|
||||
|
||||
|
@@ -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)
|
||||
|
@@ -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 ")
|
||||
|
||||
|
@@ -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)
|
||||
|
||||
|
@@ -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)
|
||||
|
@@ -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 "")
|
||||
|
||||
|
@@ -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)
|
||||
|
@@ -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>
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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")
|
||||
|
@@ -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>
|
||||
|
||||
|
@@ -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>>:...>"
|
||||
|
||||
|
@@ -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]])
|
||||
|
||||
|
@@ -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")
|
||||
|
||||
|
@@ -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")
|
||||
|
@@ -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}
|
||||
|
@@ -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")
|
||||
|
||||
|
@@ -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
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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)
|
||||
|
@@ -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}
|
||||
|
@@ -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> [...])
|
||||
|
||||
|
@@ -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)
|
||||
|
@@ -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)
|
||||
|
@@ -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}
|
||||
|
||||
|
@@ -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]
|
||||
|
@@ -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> ...)
|
||||
|
||||
|
@@ -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>)
|
||||
|
||||
|
@@ -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)
|
||||
|
||||
|
@@ -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>]
|
||||
|
@@ -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>...])
|
||||
|
@@ -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)
|
||||
|
@@ -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>])
|
||||
|
@@ -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
|
||||
|
@@ -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})
|
||||
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -16,7 +16,7 @@ The module defines the following variables:
|
||||
|
||||
Example usage:
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
find_package(CVS)
|
||||
if(CVS_FOUND)
|
||||
|
@@ -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>...)
|
||||
|
@@ -69,7 +69,7 @@ Functions
|
||||
ability to customize the Doxygen configuration used to build the
|
||||
documentation.
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
doxygen_add_docs(targetName
|
||||
[filesOrDirs...]
|
||||
|
@@ -77,7 +77,7 @@ The following cache variables may also be set:
|
||||
Example usage
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
enable_testing()
|
||||
find_package(GTest REQUIRED)
|
||||
|
@@ -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)
|
||||
|
@@ -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)
|
||||
|
@@ -50,7 +50,9 @@ Possible components are::
|
||||
LATEX2HTML
|
||||
HTLATEX
|
||||
|
||||
Example Usages::
|
||||
Example Usages:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
find_package(LATEX)
|
||||
find_package(LATEX COMPONENTS PDFLATEX)
|
||||
|
@@ -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>
|
||||
|
||||
|
@@ -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>
|
||||
|
||||
|
@@ -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>
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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"
|
||||
|
@@ -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})
|
||||
|
@@ -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)
|
||||
|
@@ -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> ...])
|
||||
|
@@ -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> ...])
|
||||
|
@@ -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> ...])
|
||||
|
@@ -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)
|
||||
|
@@ -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)
|
||||
|
@@ -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
|
||||
|
@@ -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)
|
||||
#]=======================================================================]
|
||||
|
@@ -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})
|
||||
|
@@ -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)
|
||||
|
@@ -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])
|
||||
|
||||
|
@@ -131,7 +131,7 @@ Macros
|
||||
|
||||
.. command:: GNUInstallDirs_get_absolute_install_dir
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
GNUInstallDirs_get_absolute_install_dir(absvar var dirname)
|
||||
|
||||
|
@@ -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>)
|
||||
|
||||
|
@@ -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...]
|
||||
|
@@ -7,7 +7,7 @@ MacroAddFileDependencies
|
||||
|
||||
.. deprecated:: 3.14
|
||||
|
||||
::
|
||||
.. code-block:: cmake
|
||||
|
||||
MACRO_ADD_FILE_DEPENDENCIES(<source> <files>...)
|
||||
|
||||
|
@@ -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>...])
|
||||
|
@@ -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>...)
|
||||
|
||||
|
@@ -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)
|
||||
|
@@ -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]
|
||||
|
@@ -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>
|
||||
|
Reference in New Issue
Block a user