Merge topic 'doc-formatting'
c3f40f4f Help: Improve formatting of command documentationThis commit is contained in:
Brad King
CMake Topic Stage
commit
1adcec3983
|
|
@ -12,23 +12,23 @@ Add a subdirectory to the build. The source_dir specifies the
|
|||
directory in which the source CMakeLists.txt and code files are
|
||||
located. If it is a relative path it will be evaluated with respect
|
||||
to the current directory (the typical usage), but it may also be an
|
||||
absolute path. The binary_dir specifies the directory in which to
|
||||
absolute path. The ``binary_dir`` specifies the directory in which to
|
||||
place the output files. If it is a relative path it will be evaluated
|
||||
with respect to the current output directory, but it may also be an
|
||||
absolute path. If binary_dir is not specified, the value of
|
||||
source_dir, before expanding any relative path, will be used (the
|
||||
absolute path. If ``binary_dir`` is not specified, the value of
|
||||
``source_dir``, before expanding any relative path, will be used (the
|
||||
typical usage). The CMakeLists.txt file in the specified source
|
||||
directory will be processed immediately by CMake before processing in
|
||||
the current input file continues beyond this command.
|
||||
|
||||
If the EXCLUDE_FROM_ALL argument is provided then targets in the
|
||||
subdirectory will not be included in the ALL target of the parent
|
||||
If the ``EXCLUDE_FROM_ALL`` argument is provided then targets in the
|
||||
subdirectory will not be included in the ``ALL`` target of the parent
|
||||
directory by default, and will be excluded from IDE project files.
|
||||
Users must explicitly build targets in the subdirectory. This is
|
||||
meant for use when the subdirectory contains a separate part of the
|
||||
project that is useful but not necessary, such as a set of examples.
|
||||
Typically the subdirectory should contain its own project() command
|
||||
invocation so that a full build system will be generated in the
|
||||
Typically the subdirectory should contain its own :command:`project`
|
||||
command invocation so that a full build system will be generated in the
|
||||
subdirectory (such as a VS IDE solution file). Note that inter-target
|
||||
dependencies supercede this exclusion. If a target built by the
|
||||
parent project depends on a target in the subdirectory, the dependee
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Find all source files in a directory.
|
|||
aux_source_directory(<dir> <variable>)
|
||||
|
||||
Collects the names of all the source files in the specified directory
|
||||
and stores the list in the <variable> provided. This command is
|
||||
and stores the list in the ``<variable>`` provided. This command is
|
||||
intended to be used by projects that use explicit template
|
||||
instantiation. Template instantiation files can be stored in a
|
||||
"Templates" subdirectory and collected automatically using this
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ build_name
|
|||
|
||||
Disallowed. See CMake Policy :policy:`CMP0036`.
|
||||
|
||||
Use ${CMAKE_SYSTEM} and ${CMAKE_CXX_COMPILER} instead.
|
||||
Use ``${CMAKE_SYSTEM}`` and ``${CMAKE_CXX_COMPILER}`` instead.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -11,4 +11,5 @@ Use ${CMAKE_SYSTEM} and ${CMAKE_CXX_COMPILER} instead.
|
|||
|
||||
Sets the specified variable to a string representing the platform and
|
||||
compiler settings. These values are now available through the
|
||||
CMAKE_SYSTEM and CMAKE_CXX_COMPILER variables.
|
||||
:variable:`CMAKE_SYSTEM` and
|
||||
:variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>` variables.
|
||||
|
|
|
|||
|
|
@ -8,10 +8,10 @@ Query host system specific information.
|
|||
cmake_host_system_information(RESULT <variable> QUERY <key> ...)
|
||||
|
||||
Queries system information of the host system on which cmake runs.
|
||||
One or more <key> can be provided to select the information to be
|
||||
queried. The list of queried values is stored in <variable>.
|
||||
One or more ``<key>`` can be provided to select the information to be
|
||||
queried. The list of queried values is stored in ``<variable>``.
|
||||
|
||||
<key> can be one of the following values:
|
||||
``<key>`` can be one of the following values:
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ When version 2.4 or lower is given the command implicitly invokes
|
|||
|
||||
which enables compatibility features for CMake 2.4 and lower.
|
||||
|
||||
The FATAL_ERROR option is accepted but ignored by CMake 2.6 and
|
||||
The ``FATAL_ERROR`` option is accepted but ignored by CMake 2.6 and
|
||||
higher. It should be specified so CMake versions 2.4 and lower fail
|
||||
with an error instead of just a warning.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,17 +14,17 @@ A test driver is a program that links together many small tests into a
|
|||
single executable. This is useful when building static executables
|
||||
with large libraries to shrink the total required size. The list of
|
||||
source files needed to build the test driver will be in
|
||||
sourceListName. DriverName is the name of the test driver program.
|
||||
``sourceListName``. ``driverName`` is the name of the test driver program.
|
||||
The rest of the arguments consist of a list of test source files, can
|
||||
be semicolon separated. Each test source file should have a function
|
||||
in it that is the same name as the file with no extension (foo.cxx
|
||||
should have int foo(int, char*[]);) DriverName will be able to call
|
||||
each of the tests by name on the command line. If EXTRA_INCLUDE is
|
||||
should have int foo(int, char*[]);) ``driverName`` will be able to call
|
||||
each of the tests by name on the command line. If ``EXTRA_INCLUDE`` is
|
||||
specified, then the next argument is included into the generated file.
|
||||
If FUNCTION is specified, then the next argument is taken as a
|
||||
If ``FUNCTION`` is specified, then the next argument is taken as a
|
||||
function name that is passed a pointer to ac and av. This can be used
|
||||
to add extra command line processing to each test. The cmake variable
|
||||
CMAKE_TESTDRIVER_BEFORE_TESTMAIN can be set to have code that will be
|
||||
placed directly before calling the test main function.
|
||||
CMAKE_TESTDRIVER_AFTER_TESTMAIN can be set to have code that will be
|
||||
placed directly after the call to the test main function.
|
||||
to add extra command line processing to each test. The
|
||||
``CMAKE_TESTDRIVER_BEFORE_TESTMAIN`` cmake variable can be set to
|
||||
have code that will be placed directly before calling the test main function.
|
||||
``CMAKE_TESTDRIVER_AFTER_TESTMAIN`` can be set to have code that
|
||||
will be placed directly after the call to the test main function.
|
||||
|
|
|
|||
|
|
@ -10,6 +10,6 @@ runs a ctest -S script
|
|||
|
||||
Runs a script or scripts much like if it was run from ctest -S. If no
|
||||
argument is provided then the current script is run using the current
|
||||
settings of the variables. If NEW_PROCESS is specified then each
|
||||
script will be run in a separate process.If RETURN_VALUE is specified
|
||||
the return value of the last script run will be put into var.
|
||||
settings of the variables. If ``NEW_PROCESS`` is specified then each
|
||||
script will be run in a separate process.If ``RETURN_VALUE`` is specified
|
||||
the return value of the last script run will be put into ``var``.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ after the binary directory is initialized. If the 'source' and
|
|||
If the track is
|
||||
specified, the submissions will go to the specified track. If APPEND
|
||||
is used, the existing TAG is used rather than creating a new one based
|
||||
on the current time stamp. If QUIET is used, CTest will suppress any
|
||||
on the current time stamp. If ``QUIET`` is used, CTest will suppress any
|
||||
non-error messages that it otherwise would have printed to the console.
|
||||
|
||||
If the :variable:`CTEST_CHECKOUT_COMMAND` variable
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ Define and document custom properties.
|
|||
BRIEF_DOCS <brief-doc> [docs...]
|
||||
FULL_DOCS <full-doc> [docs...])
|
||||
|
||||
Define one property in a scope for use with the set_property and
|
||||
get_property commands. This is primarily useful to associate
|
||||
Define one property in a scope for use with the :command:`set_property` and
|
||||
:command:`get_property` commands. This is primarily useful to associate
|
||||
documentation with property names that may be retrieved with the
|
||||
get_property command. The first argument determines the kind of scope
|
||||
in which the property should be used. It must be one of the
|
||||
:command:`get_property` command. The first argument determines the kind of
|
||||
scope in which the property should be used. It must be one of the
|
||||
following:
|
||||
|
||||
::
|
||||
|
|
@ -28,18 +28,18 @@ following:
|
|||
VARIABLE = documents a CMake language variable
|
||||
CACHED_VARIABLE = documents a CMake cache variable
|
||||
|
||||
Note that unlike set_property and get_property no actual scope needs
|
||||
to be given; only the kind of scope is important.
|
||||
Note that unlike :command:`set_property` and :command:`get_property` no
|
||||
actual scope needs to be given; only the kind of scope is important.
|
||||
|
||||
The required PROPERTY option is immediately followed by the name of
|
||||
The required ``PROPERTY`` option is immediately followed by the name of
|
||||
the property being defined.
|
||||
|
||||
If the INHERITED option then the get_property command will chain up to
|
||||
the next higher scope when the requested property is not set in the
|
||||
scope given to the command. DIRECTORY scope chains to GLOBAL.
|
||||
TARGET, SOURCE, and TEST chain to DIRECTORY.
|
||||
If the ``INHERITED`` option then the :command:`get_property` command will
|
||||
chain up to the next higher scope when the requested property is not set
|
||||
in the scope given to the command. ``DIRECTORY`` scope chains to
|
||||
``GLOBAL``. ``TARGET``, ``SOURCE``, and ``TEST`` chain to ``DIRECTORY``.
|
||||
|
||||
The BRIEF_DOCS and FULL_DOCS options are followed by strings to be
|
||||
The ``BRIEF_DOCS`` and ``FULL_DOCS`` options are followed by strings to be
|
||||
associated with the property as its brief and full documentation.
|
||||
Corresponding options to the get_property command will retrieve the
|
||||
documentation.
|
||||
Corresponding options to the :command:`get_property` command will retrieve
|
||||
the documentation.
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Starts the else portion of an if block.
|
|||
|
||||
else(expression)
|
||||
|
||||
See the if command.
|
||||
See the :command:`if` command.
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Starts the elseif portion of an if block.
|
|||
|
||||
elseif(expression)
|
||||
|
||||
See the if command.
|
||||
See the :command:`if` command.
|
||||
|
|
|
|||
|
|
@ -18,5 +18,5 @@ targets using the named language directly for compiling sources or
|
|||
indirectly through link dependencies. It is simplest to enable all
|
||||
needed languages in the top-level directory of a project.
|
||||
|
||||
The OPTIONAL keyword is a placeholder for future implementation and
|
||||
The ``OPTIONAL`` keyword is a placeholder for future implementation and
|
||||
does not currently work.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Enable testing for current directory and below.
|
|||
|
||||
enable_testing()
|
||||
|
||||
Enables testing for this directory and below. See also the add_test
|
||||
command. Note that ctest expects to find a test file in the build
|
||||
directory root. Therefore, this command should be in the source
|
||||
directory root.
|
||||
Enables testing for this directory and below. See also the
|
||||
:command:`add_test` command. Note that ctest expects to find a test file
|
||||
in the build directory root. Therefore, this command should be in the
|
||||
source directory root.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
endforeach
|
||||
----------
|
||||
|
||||
Ends a list of commands in a FOREACH block.
|
||||
Ends a list of commands in a foreach block.
|
||||
|
||||
::
|
||||
|
||||
endforeach(expression)
|
||||
|
||||
See the FOREACH command.
|
||||
See the :command:`foreach` command.
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Ends a list of commands in a function block.
|
|||
|
||||
endfunction(expression)
|
||||
|
||||
See the function command.
|
||||
See the :command:`function` command.
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Ends a list of commands in an if block.
|
|||
|
||||
endif(expression)
|
||||
|
||||
See the if command.
|
||||
See the :command:`if` command.
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Ends a list of commands in a macro block.
|
|||
|
||||
endmacro(expression)
|
||||
|
||||
See the macro command.
|
||||
See the :command:`macro` command.
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Ends a list of commands in a while block.
|
|||
|
||||
endwhile(expression)
|
||||
|
||||
See the while command.
|
||||
See the :command:`while` command.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
exec_program
|
||||
------------
|
||||
|
||||
Deprecated. Use the execute_process() command instead.
|
||||
Deprecated. Use the :command:`execute_process` command instead.
|
||||
|
||||
Run an executable program during the processing of the CMakeList.txt
|
||||
file.
|
||||
|
|
@ -15,10 +15,10 @@ file.
|
|||
|
||||
The executable is run in the optionally specified directory. The
|
||||
executable can include arguments if it is double quoted, but it is
|
||||
better to use the optional ARGS argument to specify arguments to the
|
||||
better to use the optional ``ARGS`` argument to specify arguments to the
|
||||
program. This is because cmake will then be able to escape spaces in
|
||||
the executable path. An optional argument OUTPUT_VARIABLE specifies a
|
||||
the executable path. An optional argument ``OUTPUT_VARIABLE`` specifies a
|
||||
variable in which to store the output. To capture the return value of
|
||||
the execution, provide a RETURN_VALUE. If OUTPUT_VARIABLE is
|
||||
the execution, provide a ``RETURN_VALUE``. If ``OUTPUT_VARIABLE`` is
|
||||
specified, then no output will go to the stdout/stderr of the console
|
||||
running cmake.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ A single standard error pipe is used for all processes.
|
|||
|
||||
Options:
|
||||
|
||||
COMMAND
|
||||
``COMMAND``
|
||||
A child process command line.
|
||||
|
||||
CMake executes the child process using operating system APIs directly.
|
||||
|
|
@ -36,31 +36,31 @@ COMMAND
|
|||
(Use the ``INPUT_*``, ``OUTPUT_*``, and ``ERROR_*`` options to
|
||||
redirect stdin, stdout, and stderr.)
|
||||
|
||||
WORKING_DIRECTORY
|
||||
``WORKING_DIRECTORY``
|
||||
The named directory will be set as the current working directory of
|
||||
the child processes.
|
||||
|
||||
TIMEOUT
|
||||
``TIMEOUT``
|
||||
The child processes will be terminated if they do not finish in the
|
||||
specified number of seconds (fractions are allowed).
|
||||
|
||||
RESULT_VARIABLE
|
||||
``RESULT_VARIABLE``
|
||||
The variable will be set to contain the result of running the processes.
|
||||
This will be an integer return code from the last child or a string
|
||||
describing an error condition.
|
||||
|
||||
OUTPUT_VARIABLE, ERROR_VARIABLE
|
||||
``OUTPUT_VARIABLE``, ``ERROR_VARIABLE``
|
||||
The variable named will be set with the contents of the standard output
|
||||
and standard error pipes, respectively. If the same variable is named
|
||||
for both pipes their output will be merged in the order produced.
|
||||
|
||||
INPUT_FILE, OUTPUT_FILE, ERROR_FILE
|
||||
``INPUT_FILE, OUTPUT_FILE``, ``ERROR_FILE``
|
||||
The file named will be attached to the standard input of the first
|
||||
process, standard output of the last process, or standard error of
|
||||
all processes, respectively. If the same file is named for both
|
||||
output and error then it will be used for both.
|
||||
|
||||
OUTPUT_QUIET, ERROR_QUIET
|
||||
``OUTPUT_QUIET``, ``ERROR_QUIET``
|
||||
The standard output or standard error results will be quietly ignored.
|
||||
|
||||
If more than one ``OUTPUT_*`` or ``ERROR_*`` option is given for the
|
||||
|
|
|
|||
|
|
@ -7,20 +7,20 @@ Export targets from the build tree for use by outside projects.
|
|||
|
||||
export(EXPORT <export-name> [NAMESPACE <namespace>] [FILE <filename>])
|
||||
|
||||
Create a file <filename> that may be included by outside projects to
|
||||
Create a file ``<filename>`` that may be included by outside projects to
|
||||
import targets from the current project's build tree. This is useful
|
||||
during cross-compiling to build utility executables that can run on
|
||||
the host platform in one project and then import them into another
|
||||
project being compiled for the target platform. If the NAMESPACE
|
||||
option is given the <namespace> string will be prepended to all target
|
||||
project being compiled for the target platform. If the ``NAMESPACE``
|
||||
option is given the ``<namespace>`` string will be prepended to all target
|
||||
names written to the file.
|
||||
|
||||
Target installations are associated with the export <export-name>
|
||||
Target installations are associated with the export ``<export-name>``
|
||||
using the ``EXPORT`` option of the :command:`install(TARGETS)` command.
|
||||
|
||||
The file created by this command is specific to the build tree and
|
||||
should never be installed. See the install(EXPORT) command to export
|
||||
targets from an installation tree.
|
||||
should never be installed. See the :command:`install(EXPORT)` command to
|
||||
export targets from an installation tree.
|
||||
|
||||
The properties set on the generated IMPORTED targets will have the
|
||||
same values as the final values of the input TARGETS.
|
||||
|
|
@ -45,12 +45,12 @@ unspecified.
|
|||
export(PACKAGE <name>)
|
||||
|
||||
Store the current build directory in the CMake user package registry
|
||||
for package <name>. The find_package command may consider the
|
||||
directory while searching for package <name>. This helps dependent
|
||||
for package ``<name>``. The find_package command may consider the
|
||||
directory while searching for package ``<name>``. This helps dependent
|
||||
projects find and use a package from the current project's build tree
|
||||
without help from the user. Note that the entry in the package
|
||||
registry that this command creates works only in conjunction with a
|
||||
package configuration file (<name>Config.cmake) that works with the
|
||||
package configuration file (``<name>Config.cmake``) that works with the
|
||||
build tree. In some cases, for example for packaging and for system
|
||||
wide installations, it is not desirable to write the user package
|
||||
registry. If the :variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable
|
||||
|
|
|
|||
|
|
@ -7,22 +7,22 @@ Use :command:`install(EXPORT)` or :command:`export` command.
|
|||
|
||||
This command generates an old-style library dependencies file.
|
||||
Projects requiring CMake 2.6 or later should not use the command. Use
|
||||
instead the install(EXPORT) command to help export targets from an
|
||||
installation tree and the export() command to export targets from a
|
||||
instead the :command:`install(EXPORT)` command to help export targets from an
|
||||
installation tree and the :command:`export` command to export targets from a
|
||||
build tree.
|
||||
|
||||
The old-style library dependencies file does not take into account
|
||||
per-configuration names of libraries or the LINK_INTERFACE_LIBRARIES
|
||||
target property.
|
||||
per-configuration names of libraries or the
|
||||
:prop_tgt:`LINK_INTERFACE_LIBRARIES` target property.
|
||||
|
||||
::
|
||||
|
||||
export_library_dependencies(<file> [APPEND])
|
||||
|
||||
Create a file named <file> that can be included into a CMake listfile
|
||||
Create a file named ``<file>`` that can be included into a CMake listfile
|
||||
with the INCLUDE command. The file will contain a number of SET
|
||||
commands that will set all the variables needed for library dependency
|
||||
information. This should be the last command in the top level
|
||||
CMakeLists.txt file of the project. If the APPEND option is
|
||||
CMakeLists.txt file of the project. If the ``APPEND`` option is
|
||||
specified, the SET commands will be appended to the given file instead
|
||||
of replacing it.
|
||||
|
|
|
|||
|
|
@ -10,5 +10,5 @@ Create FLTK user interfaces Wrappers.
|
|||
|
||||
Produce .h and .cxx files for all the .fl and .fld files listed. The
|
||||
resulting .h and .cxx files will be added to a variable named
|
||||
resultingLibraryName_FLTK_UI_SRCS which should be added to your
|
||||
``resultingLibraryName_FLTK_UI_SRCS`` which should be added to your
|
||||
library.
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ All commands between foreach and the matching endforeach are recorded
|
|||
without being invoked. Once the endforeach is evaluated, the recorded
|
||||
list of commands is invoked once for each argument listed in the
|
||||
original foreach command. Before each iteration of the loop
|
||||
"${loop_var}" will be set as a variable with the current value in the
|
||||
``${loop_var}`` will be set as a variable with the current value in the
|
||||
list.
|
||||
|
||||
::
|
||||
|
|
@ -40,8 +40,8 @@ three types of this iteration:
|
|||
foreach(loop_var IN [LISTS [list1 [...]]]
|
||||
[ITEMS [item1 [...]]])
|
||||
|
||||
Iterates over a precise list of items. The LISTS option names
|
||||
Iterates over a precise list of items. The ``LISTS`` option names
|
||||
list-valued variables to be traversed, including empty elements (an
|
||||
empty string is a zero-length list). (Note macro
|
||||
arguments are not variables.) The ITEMS option ends argument
|
||||
arguments are not variables.) The ``ITEMS`` option ends argument
|
||||
parsing and includes all arguments following it in the iteration.
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ Get a property of the CMake instance.
|
|||
get_cmake_property(VAR property)
|
||||
|
||||
Get a property from the CMake instance. The value of the property is
|
||||
stored in the variable VAR. If the property is not found, VAR will be
|
||||
set to "NOTFOUND". Some supported properties include: VARIABLES,
|
||||
CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS.
|
||||
stored in the variable ``VAR``. If the property is not found, ``VAR``
|
||||
will be set to "NOTFOUND". See the :manual:`cmake-properties(7)` manual
|
||||
for available properties.
|
||||
|
||||
See also the more general get_property() command.
|
||||
See also the more general :command:`get_property` command.
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
get_directory_property
|
||||
----------------------
|
||||
|
||||
Get a property of DIRECTORY scope.
|
||||
Get a property of ``DIRECTORY`` scope.
|
||||
|
||||
::
|
||||
|
||||
get_directory_property(<variable> [DIRECTORY <dir>] <prop-name>)
|
||||
|
||||
Store a property of directory scope in the named variable. If the
|
||||
property is not defined the empty-string is returned. The DIRECTORY
|
||||
property is not defined the empty-string is returned. The ``DIRECTORY``
|
||||
argument specifies another directory from which to retrieve the
|
||||
property value. The specified directory must have already been
|
||||
traversed by CMake.
|
||||
|
|
@ -21,4 +21,4 @@ traversed by CMake.
|
|||
Get a variable definition from a directory. This form is useful to
|
||||
get a variable definition from another directory.
|
||||
|
||||
See also the more general get_property() command.
|
||||
See also the more general :command:`get_property` command.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Get a specific component of a full filename.
|
|||
|
||||
get_filename_component(<VAR> <FileName> <COMP> [CACHE])
|
||||
|
||||
Set <VAR> to a component of <FileName>, where <COMP> is one of:
|
||||
Set ``<VAR>`` to a component of ``<FileName>``, where ``<COMP>`` is one of:
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ Set <VAR> to a component of <FileName>, where <COMP> is one of:
|
|||
|
||||
Paths are returned with forward slashes and have no trailing slahes.
|
||||
The longest file extension is always considered. If the optional
|
||||
CACHE argument is specified, the result variable is added to the
|
||||
``CACHE`` argument is specified, the result variable is added to the
|
||||
cache.
|
||||
|
||||
::
|
||||
|
|
@ -30,8 +30,8 @@ cache.
|
|||
PROGRAM [PROGRAM_ARGS <ARG_VAR>]
|
||||
[CACHE])
|
||||
|
||||
The program in FileName will be found in the system search path or
|
||||
left as a full path. If PROGRAM_ARGS is present with PROGRAM, then
|
||||
any command-line arguments present in the FileName string are split
|
||||
from the program name and stored in <ARG_VAR>. This is used to
|
||||
The program in ``FileName`` will be found in the system search path or
|
||||
left as a full path. If ``PROGRAM_ARGS`` is present with ``PROGRAM``, then
|
||||
any command-line arguments present in the ``FileName`` string are split
|
||||
from the program name and stored in ``<ARG_VAR>``. This is used to
|
||||
separate a program name from its arguments in a command line string.
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@ Get a property for a source file.
|
|||
get_source_file_property(VAR file property)
|
||||
|
||||
Get a property from a source file. The value of the property is
|
||||
stored in the variable VAR. If the property is not found, VAR will be
|
||||
set to "NOTFOUND". Use set_source_files_properties to set property
|
||||
values. Source file properties usually control how the file is built.
|
||||
One property that is always there is LOCATION
|
||||
stored in the variable ``VAR``. If the property is not found, ``VAR``
|
||||
will be set to "NOTFOUND". Use :command:`set_source_files_properties`
|
||||
to set property values. Source file properties usually control how the
|
||||
file is built. One property that is always there is :prop_sf:`LOCATION`
|
||||
|
||||
See also the more general get_property() command.
|
||||
See also the more general :command:`get_property` command.
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ Get a property from a target.
|
|||
get_target_property(VAR target property)
|
||||
|
||||
Get a property from a target. The value of the property is stored in
|
||||
the variable VAR. If the property is not found, VAR will be set to
|
||||
"NOTFOUND". Use set_target_properties to set property values.
|
||||
the variable ``VAR``. If the property is not found, ``VAR`` will be set to
|
||||
"NOTFOUND". Use :command:`set_target_properties` to set property values.
|
||||
Properties are usually used to control how a target is built, but some
|
||||
query the target instead. This command can get properties for any
|
||||
target so far created. The targets do not need to be in the current
|
||||
CMakeLists.txt file.
|
||||
|
||||
See also the more general get_property() command.
|
||||
See also the more general :command:`get_property` command.
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ Get a property of the test.
|
|||
get_test_property(test property VAR)
|
||||
|
||||
Get a property from the test. The value of the property is stored in
|
||||
the variable VAR. If the test or property is not found, VAR will be
|
||||
set to "NOTFOUND". For a list of standard properties you can type cmake
|
||||
--help-property-list.
|
||||
the variable ``VAR``. If the test or property is not found, ``VAR`` will
|
||||
be set to "NOTFOUND". For a list of standard properties you can type
|
||||
``cmake --help-property-list``.
|
||||
|
||||
See also the more general get_property() command.
|
||||
See also the more general :command:`get_property` command.
|
||||
|
|
|
|||
|
|
@ -9,17 +9,17 @@ Load and run CMake code from a file or module.
|
|||
[NO_POLICY_SCOPE])
|
||||
|
||||
Load and run CMake code from the file given. Variable reads and
|
||||
writes access the scope of the caller (dynamic scoping). If OPTIONAL
|
||||
writes access the scope of the caller (dynamic scoping). If ``OPTIONAL``
|
||||
is present, then no error is raised if the file does not exist. If
|
||||
RESULT_VARIABLE is given the variable will be set to the full filename
|
||||
``RESULT_VARIABLE`` is given the variable will be set to the full filename
|
||||
which has been included or NOTFOUND if it failed.
|
||||
|
||||
If a module is specified instead of a file, the file with name
|
||||
<modulename>.cmake is searched first in CMAKE_MODULE_PATH, then in the
|
||||
CMake module directory. There is one exception to this: if the file
|
||||
which calls include() is located itself in the CMake module directory,
|
||||
then first the CMake module directory is searched and
|
||||
CMAKE_MODULE_PATH afterwards. See also policy CMP0017.
|
||||
<modulename>.cmake is searched first in :variable:`CMAKE_MODULE_PATH`,
|
||||
then in the CMake module directory. There is one exception to this: if
|
||||
the file which calls ``include()`` is located itself in the CMake module
|
||||
directory, then first the CMake module directory is searched and
|
||||
:variable:`CMAKE_MODULE_PATH` afterwards. See also policy :policy:`CMP0017`.
|
||||
|
||||
See the cmake_policy() command documentation for discussion of the
|
||||
NO_POLICY_SCOPE option.
|
||||
See the :command:`cmake_policy` command documentation for discussion of the
|
||||
``NO_POLICY_SCOPE`` option.
|
||||
|
|
|
|||
|
|
@ -13,10 +13,10 @@ Include an external Microsoft project file in a workspace.
|
|||
|
||||
Includes an external Microsoft project in the generated workspace
|
||||
file. Currently does nothing on UNIX. This will create a target
|
||||
named [projectname]. This can be used in the add_dependencies command
|
||||
to make things depend on the external project.
|
||||
named [projectname]. This can be used in the :command:`add_dependencies`
|
||||
command to make things depend on the external project.
|
||||
|
||||
TYPE, GUID and PLATFORM are optional parameters that allow one to
|
||||
``TYPE``, ``GUID`` and ``PLATFORM`` are optional parameters that allow one to
|
||||
specify the type of project, id (GUID) of the project and the name of
|
||||
the target platform. This is useful for projects requiring values
|
||||
other than the default (e.g. WIX projects). These options are not
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ Set the regular expression used for dependency checking.
|
|||
include_regular_expression(regex_match [regex_complain])
|
||||
|
||||
Set the regular expressions used in dependency checking. Only files
|
||||
matching regex_match will be traced as dependencies. Only files
|
||||
matching regex_complain will generate warnings if they cannot be found
|
||||
matching ``regex_match`` will be traced as dependencies. Only files
|
||||
matching ``regex_complain`` will generate warnings if they cannot be found
|
||||
(standard header paths are not searched). The defaults are:
|
||||
|
||||
::
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
install_files
|
||||
-------------
|
||||
|
||||
Deprecated. Use the install(FILES ) command instead.
|
||||
Deprecated. Use the :command:`install(FILES)` command instead.
|
||||
|
||||
This command has been superceded by the install command. It is
|
||||
provided for compatibility with older CMake code. The FILES form is
|
||||
directly replaced by the FILES form of the install command. The
|
||||
regexp form can be expressed more clearly using the GLOB form of the
|
||||
file command.
|
||||
This command has been superceded by the :command:`install` command. It is
|
||||
provided for compatibility with older CMake code. The ``FILES`` form is
|
||||
directly replaced by the ``FILES`` form of the :command:`install`
|
||||
command. The regexp form can be expressed more clearly using the ``GLOB``
|
||||
form of the :command:`file` command.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -32,8 +32,8 @@ expression will be installed.
|
|||
|
||||
install_files(<dir> FILES file file ...)
|
||||
|
||||
Any files listed after the FILES keyword will be installed explicitly
|
||||
Any files listed after the ``FILES`` keyword will be installed explicitly
|
||||
from the names given. Full paths are allowed in this form.
|
||||
|
||||
The directory <dir> is relative to the installation prefix, which is
|
||||
stored in the variable CMAKE_INSTALL_PREFIX.
|
||||
The directory ``<dir>`` is relative to the installation prefix, which is
|
||||
stored in the variable :variable:`CMAKE_INSTALL_PREFIX`.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
install_programs
|
||||
----------------
|
||||
|
||||
Deprecated. Use the install(PROGRAMS ) command instead.
|
||||
Deprecated. Use the :command:`install(PROGRAMS)` command instead.
|
||||
|
||||
This command has been superceded by the install command. It is
|
||||
provided for compatibility with older CMake code. The FILES form is
|
||||
directly replaced by the PROGRAMS form of the INSTALL command. The
|
||||
regexp form can be expressed more clearly using the GLOB form of the
|
||||
FILE command.
|
||||
This command has been superceded by the :command:`install` command. It is
|
||||
provided for compatibility with older CMake code. The ``FILES`` form is
|
||||
directly replaced by the ``PROGRAMS`` form of the :command:`install`
|
||||
command. The regexp form can be expressed more clearly using the ``GLOB``
|
||||
form of the :command:`file` command.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ FILE command.
|
|||
install_programs(<dir> FILES file1 [file2 ...])
|
||||
|
||||
Create rules to install the listed programs into the given directory.
|
||||
Use the FILES argument to guarantee that the file list version of the
|
||||
Use the ``FILES`` argument to guarantee that the file list version of the
|
||||
command will be used even when there is only one argument.
|
||||
|
||||
::
|
||||
|
|
@ -26,8 +26,9 @@ In the second form any program in the current source directory that
|
|||
matches the regular expression will be installed.
|
||||
|
||||
This command is intended to install programs that are not built by
|
||||
cmake, such as shell scripts. See the TARGETS form of the INSTALL
|
||||
command to create installation rules for targets built by cmake.
|
||||
cmake, such as shell scripts. See the ``TARGETS`` form of the
|
||||
:command:`install` command to create installation rules for targets built
|
||||
by cmake.
|
||||
|
||||
The directory <dir> is relative to the installation prefix, which is
|
||||
stored in the variable CMAKE_INSTALL_PREFIX.
|
||||
The directory ``<dir>`` is relative to the installation prefix, which is
|
||||
stored in the variable :variable:`CMAKE_INSTALL_PREFIX`.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
install_targets
|
||||
---------------
|
||||
|
||||
Deprecated. Use the install(TARGETS ) command instead.
|
||||
Deprecated. Use the :command:`install(TARGETS)` command instead.
|
||||
|
||||
This command has been superceded by the install command. It is
|
||||
This command has been superceded by the :command:`install` command. It is
|
||||
provided for compatibility with older CMake code.
|
||||
|
||||
::
|
||||
|
|
@ -11,7 +11,7 @@ provided for compatibility with older CMake code.
|
|||
install_targets(<dir> [RUNTIME_DIRECTORY dir] target target)
|
||||
|
||||
Create rules to install the listed targets into the given directory.
|
||||
The directory <dir> is relative to the installation prefix, which is
|
||||
stored in the variable CMAKE_INSTALL_PREFIX. If RUNTIME_DIRECTORY is
|
||||
specified, then on systems with special runtime files (Windows DLL),
|
||||
the files will be copied to that directory.
|
||||
The directory ``<dir>`` is relative to the installation prefix, which is
|
||||
stored in the variable :variable:`CMAKE_INSTALL_PREFIX`. If
|
||||
``RUNTIME_DIRECTORY`` is specified, then on systems with special runtime
|
||||
files (Windows DLL), the files will be copied to that directory.
|
||||
|
|
|
|||
|
|
@ -10,10 +10,10 @@ Specify directories in which the linker will look for libraries.
|
|||
Specify the paths in which the linker should search for libraries.
|
||||
The command will apply only to targets created after it is called.
|
||||
Relative paths given to this command are interpreted as relative to
|
||||
the current source directory, see CMP0015.
|
||||
the current source directory, see :policy:`CMP0015`.
|
||||
|
||||
Note that this command is rarely necessary. Library locations
|
||||
returned by find_package() and find_library() are absolute paths.
|
||||
Pass these absolute library file paths directly to the
|
||||
target_link_libraries() command. CMake will ensure the linker finds
|
||||
returned by :command:`find_package` and :command:`find_library` are
|
||||
absolute paths. Pass these absolute library file paths directly to the
|
||||
:command:`target_link_libraries` command. CMake will ensure the linker finds
|
||||
them.
|
||||
|
|
|
|||
|
|
@ -17,45 +17,45 @@ List operations.
|
|||
list(REVERSE <list>)
|
||||
list(SORT <list>)
|
||||
|
||||
LENGTH will return a given list's length.
|
||||
``LENGTH`` will return a given list's length.
|
||||
|
||||
GET will return list of elements specified by indices from the list.
|
||||
``GET`` will return list of elements specified by indices from the list.
|
||||
|
||||
APPEND will append elements to the list.
|
||||
``APPEND`` will append elements to the list.
|
||||
|
||||
FIND will return the index of the element specified in the list or -1
|
||||
``FIND`` will return the index of the element specified in the list or -1
|
||||
if it wasn't found.
|
||||
|
||||
INSERT will insert elements to the list to the specified location.
|
||||
``INSERT`` will insert elements to the list to the specified location.
|
||||
|
||||
REMOVE_AT and REMOVE_ITEM will remove items from the list. The
|
||||
difference is that REMOVE_ITEM will remove the given items, while
|
||||
REMOVE_AT will remove the items at the given indices.
|
||||
``REMOVE_AT`` and ``REMOVE_ITEM`` will remove items from the list. The
|
||||
difference is that ``REMOVE_ITEM`` will remove the given items, while
|
||||
``REMOVE_AT`` will remove the items at the given indices.
|
||||
|
||||
REMOVE_DUPLICATES will remove duplicated items in the list.
|
||||
``REMOVE_DUPLICATES`` will remove duplicated items in the list.
|
||||
|
||||
REVERSE reverses the contents of the list in-place.
|
||||
``REVERSE`` reverses the contents of the list in-place.
|
||||
|
||||
SORT sorts the list in-place alphabetically.
|
||||
``SORT`` sorts the list in-place alphabetically.
|
||||
|
||||
The list subcommands APPEND, INSERT, REMOVE_AT, REMOVE_ITEM,
|
||||
REMOVE_DUPLICATES, REVERSE and SORT may create new values for the list
|
||||
within the current CMake variable scope. Similar to the SET command,
|
||||
the LIST command creates new variable values in the current scope,
|
||||
even if the list itself is actually defined in a parent scope. To
|
||||
propagate the results of these operations upwards, use SET with
|
||||
PARENT_SCOPE, SET with CACHE INTERNAL, or some other means of value
|
||||
propagation.
|
||||
The list subcommands ``APPEND``, ``INSERT``, ``REMOVE_AT``, ``REMOVE_ITEM``,
|
||||
``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new values for
|
||||
the list within the current CMake variable scope. Similar to the
|
||||
:command:`set` command, the LIST command creates new variable values in the
|
||||
current scope, even if the list itself is actually defined in a parent
|
||||
scope. To propagate the results of these operations upwards, use
|
||||
:command:`set` with ``PARENT_SCOPE``, :command:`set` with
|
||||
``CACHE INTERNAL``, or some other means of value propagation.
|
||||
|
||||
NOTES: A list in cmake is a ; separated group of strings. To create a
|
||||
list the set command can be used. For example, set(var a b c d e)
|
||||
creates a list with a;b;c;d;e, and set(var "a b c d e") creates a
|
||||
NOTES: A list in cmake is a ``;`` separated group of strings. To create a
|
||||
list the set command can be used. For example, ``set(var a b c d e)``
|
||||
creates a list with ``a;b;c;d;e``, and ``set(var "a b c d e")`` creates a
|
||||
string or a list with one item in it. (Note macro arguments are not
|
||||
variables, and therefore cannot be used in LIST commands.)
|
||||
|
||||
When specifying index values, if <element index> is 0 or greater, it
|
||||
When specifying index values, if ``<element index>`` is 0 or greater, it
|
||||
is indexed from the beginning of the list, with 0 representing the
|
||||
first list element. If <element index> is -1 or lesser, it is indexed
|
||||
first list element. If ``<element index>`` is -1 or lesser, it is indexed
|
||||
from the end of the list, with -1 representing the last list element.
|
||||
Be careful when counting with negative indices: they do not start from
|
||||
0. -0 is equivalent to 0, the first list element.
|
||||
|
|
|
|||
|
|
@ -19,9 +19,9 @@ does not create entries in the local project's cache.
|
|||
|
||||
Load in the values from another cache and store them in the local
|
||||
project's cache as internal entries. This is useful for a project
|
||||
that depends on another project built in a different tree. EXCLUDE
|
||||
that depends on another project built in a different tree. ``EXCLUDE``
|
||||
option can be used to provide a list of entries to be excluded.
|
||||
INCLUDE_INTERNALS can be used to provide a list of internal entries to
|
||||
``INCLUDE_INTERNALS`` can be used to provide a list of internal entries to
|
||||
be included. Normally, no internal entries are brought in. Use of
|
||||
this form of the command is strongly discouraged, but it is provided
|
||||
for backward compatibility.
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ Load a command into a running CMake.
|
|||
|
||||
The given locations are searched for a library whose name is
|
||||
cmCOMMAND_NAME. If found, it is loaded as a module and the command is
|
||||
added to the set of available CMake commands. Usually, TRY_COMPILE is
|
||||
used before this command to compile the module. If the command is
|
||||
successfully loaded a variable named
|
||||
added to the set of available CMake commands. Usually,
|
||||
:command:`try_compile` is used before this command to compile the
|
||||
module. If the command is successfully loaded a variable named
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
make_directory
|
||||
--------------
|
||||
|
||||
Deprecated. Use the file(MAKE_DIRECTORY ) command instead.
|
||||
Deprecated. Use the :command:`file(MAKE_DIRECTORY)` command instead.
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -9,10 +9,10 @@ Mark cmake cached variables as advanced.
|
|||
|
||||
Mark the named cached variables as advanced. An advanced variable
|
||||
will not be displayed in any of the cmake GUIs unless the show
|
||||
advanced option is on. If CLEAR is the first argument advanced
|
||||
variables are changed back to unadvanced. If FORCE is the first
|
||||
argument, then the variable is made advanced. If neither FORCE nor
|
||||
CLEAR is specified, new values will be marked as advanced, but if the
|
||||
advanced option is on. If ``CLEAR`` is the first argument advanced
|
||||
variables are changed back to unadvanced. If ``FORCE`` is the first
|
||||
argument, then the variable is made advanced. If neither ``FORCE`` nor
|
||||
``CLEAR`` is specified, new values will be marked as advanced, but if the
|
||||
variable already has an advanced/non-advanced state, it will not be
|
||||
changed.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Mathematical expressions.
|
|||
|
||||
math(EXPR <output variable> <math expression>)
|
||||
|
||||
EXPR evaluates mathematical expression and returns result in the
|
||||
``EXPR`` evaluates mathematical expression and returns result in the
|
||||
output variable. Example mathematical expression is '5 * ( 10 + 13
|
||||
)'. Supported operators are + - * / % | & ^ ~ << >> * / %. They have
|
||||
the same meaning as they do in C code.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Display a message to the user.
|
|||
|
||||
message([<mode>] "message to display" ...)
|
||||
|
||||
The optional <mode> keyword determines the type of message:
|
||||
The optional ``<mode>`` keyword determines the type of message:
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ Provides an option that the user can optionally select.
|
|||
option(<option_variable> "help string describing option"
|
||||
[initial value])
|
||||
|
||||
Provide an option for the user to select as ON or OFF. If no initial
|
||||
value is provided, OFF is used.
|
||||
Provide an option for the user to select as ``ON`` or ``OFF``. If no
|
||||
initial value is provided, ``OFF`` is used.
|
||||
|
||||
If you have options that depend on the values of other options, see
|
||||
the module help for CMakeDependentOption.
|
||||
the module help for :module:`CMakeDependentOption`.
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ Create Qt Wrappers.
|
|||
SourceLists ...)
|
||||
|
||||
Produce moc files for all the .h files listed in the SourceLists. The
|
||||
moc files will be added to the library using the DestName source list.
|
||||
moc files will be added to the library using the ``DestName`` source list.
|
||||
|
|
|
|||
|
|
@ -9,6 +9,6 @@ Create Qt user interfaces Wrappers.
|
|||
SourcesDestName SourceLists ...)
|
||||
|
||||
Produce .h and .cxx files for all the .ui files listed in the
|
||||
SourceLists. The .h files will be added to the library using the
|
||||
HeadersDestNamesource list. The .cxx files will be added to the
|
||||
library using the SourcesDestNamesource list.
|
||||
``SourceLists``. The .h files will be added to the library using the
|
||||
``HeadersDestNamesource`` list. The .cxx files will be added to the
|
||||
library using the ``SourcesDestNamesource`` list.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
remove
|
||||
------
|
||||
|
||||
Deprecated. Use the list(REMOVE_ITEM ) command instead.
|
||||
Deprecated. Use the :command:`list(REMOVE_ITEM)` command instead.
|
||||
|
||||
::
|
||||
|
||||
remove(VAR VALUE VALUE ...)
|
||||
|
||||
Removes VALUE from the variable VAR. This is typically used to remove
|
||||
entries from a vector (e.g. semicolon separated list). VALUE is
|
||||
expanded.
|
||||
Removes ``VALUE`` from the variable ``VAR``. This is typically used to
|
||||
remove entries from a vector (e.g. semicolon separated list). ``VALUE``
|
||||
is expanded.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
remove_definitions
|
||||
------------------
|
||||
|
||||
Removes -D define flags added by add_definitions.
|
||||
Removes -D define flags added by :command:`add_definitions`.
|
||||
|
||||
::
|
||||
|
||||
remove_definitions(-DFOO -DBAR ...)
|
||||
|
||||
Removes flags (added by add_definitions) from the compiler command
|
||||
line for sources in the current directory and below.
|
||||
Removes flags (added by :command:`add_definitions`) from the compiler
|
||||
command line for sources in the current directory and below.
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ Return from a file, directory or function.
|
|||
return()
|
||||
|
||||
Returns from a file, directory or function. When this command is
|
||||
encountered in an included file (via include() or find_package()), it
|
||||
causes processing of the current file to stop and control is returned
|
||||
to the including file. If it is encountered in a file which is not
|
||||
included by another file, e.g. a CMakeLists.txt, control is returned
|
||||
to the parent directory if there is one. If return is called in a
|
||||
function, control is returned to the caller of the function. Note
|
||||
that a macro is not a function and does not handle return like a
|
||||
encountered in an included file (via :command:`include` or
|
||||
:command:`find_package`), it causes processing of the current file to stop
|
||||
and control is returned to the including file. If it is encountered in a
|
||||
file which is not included by another file, e.g. a ``CMakeLists.txt``,
|
||||
control is returned to the parent directory if there is one. If return is
|
||||
called in a function, control is returned to the caller of the function.
|
||||
Note that a macro is not a function and does not handle return like a
|
||||
function does.
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ Parse space-separated arguments into a semicolon-separated list.
|
|||
separate_arguments(<var> <UNIX|WINDOWS>_COMMAND "<args>")
|
||||
|
||||
Parses a unix- or windows-style command-line string "<args>" and
|
||||
stores a semicolon-separated list of the arguments in <var>. The
|
||||
stores a semicolon-separated list of the arguments in ``<var>``. The
|
||||
entire command line must be given in one "<args>" argument.
|
||||
|
||||
The UNIX_COMMAND mode separates arguments by unquoted whitespace. It
|
||||
The ``UNIX_COMMAND`` mode separates arguments by unquoted whitespace. It
|
||||
recognizes both single-quote and double-quote pairs. A backslash
|
||||
escapes the next literal character (\" is "); there are no special
|
||||
escapes (\n is just n).
|
||||
|
||||
The WINDOWS_COMMAND mode parses a windows command-line using the same
|
||||
The ``WINDOWS_COMMAND`` mode parses a windows command-line using the same
|
||||
syntax the runtime library uses to construct argv at startup. It
|
||||
separates arguments by whitespace that is not double-quoted.
|
||||
Backslashes are literal unless they precede double-quotes. See the
|
||||
|
|
@ -26,6 +26,6 @@ MSDN article "Parsing C Command-Line Arguments" for details.
|
|||
|
||||
separate_arguments(VARIABLE)
|
||||
|
||||
Convert the value of VARIABLE to a semi-colon separated list. All
|
||||
Convert the value of ``VARIABLE`` to a semi-colon separated list. All
|
||||
spaces are replaced with ';'. This helps with generating command
|
||||
lines.
|
||||
|
|
|
|||
|
|
@ -12,93 +12,98 @@ Targets can have properties that affect how they are built.
|
|||
Set properties on a target. The syntax for the command is to list all
|
||||
the files you want to change, and then provide the values you want to
|
||||
set next. You can use any prop value pair you want and extract it
|
||||
later with the GET_TARGET_PROPERTY command.
|
||||
later with the :command:`get_target_property` command.
|
||||
|
||||
Properties that affect the name of a target's output file are as
|
||||
follows. The PREFIX and SUFFIX properties override the default target
|
||||
name prefix (such as "lib") and suffix (such as ".so"). IMPORT_PREFIX
|
||||
and IMPORT_SUFFIX are the equivalent properties for the import library
|
||||
corresponding to a DLL (for SHARED library targets). OUTPUT_NAME sets
|
||||
the real name of a target when it is built and can be used to help
|
||||
create two targets of the same name even though CMake requires unique
|
||||
logical target names. There is also a <CONFIG>_OUTPUT_NAME that can
|
||||
set the output name on a per-configuration basis. <CONFIG>_POSTFIX
|
||||
sets a postfix for the real name of the target when it is built under
|
||||
the configuration named by <CONFIG> (in upper-case, such as
|
||||
"DEBUG_POSTFIX"). The value of this property is initialized when the
|
||||
target is created to the value of the variable CMAKE_<CONFIG>_POSTFIX
|
||||
follows. The :prop_tgt:`PREFIX` and :prop_tgt:`SUFFIX` properties
|
||||
override the default target name prefix (such as "lib") and suffix
|
||||
(such as ".so"). :prop_tgt:`IMPORT_PREFIX` and
|
||||
:prop_tgt:`IMPORT_SUFFIX` are the equivalent properties for the import
|
||||
library corresponding to a DLL (for SHARED library targets).
|
||||
:prop_tgt:`OUTPUT_NAME` sets the real name of a target when it is built
|
||||
and can be used to help create two targets of the same name even though
|
||||
CMake requires unique logical target names. There is also a
|
||||
:prop_tgt:`<CONFIG>_OUTPUT_NAME` that can set the output name on a
|
||||
per-configuration basis. :prop_tgt:`<CONFIG>_POSTFIX` sets a postfix for
|
||||
the real name of the target when it is built under the configuration named
|
||||
by ``<CONFIG>`` (in upper-case, such as "DEBUG_POSTFIX"). The value of this
|
||||
property is initialized when the target is created to the value of the
|
||||
variable :variable:`CMAKE_<CONFIG>_POSTFIX`
|
||||
(except for executable targets because earlier CMake versions which
|
||||
did not use this variable for executables).
|
||||
|
||||
The LINK_FLAGS property can be used to add extra flags to the link
|
||||
step of a target. LINK_FLAGS_<CONFIG> will add to the configuration
|
||||
<CONFIG>, for example, DEBUG, RELEASE, MINSIZEREL, RELWITHDEBINFO.
|
||||
DEFINE_SYMBOL sets the name of the preprocessor symbol defined when
|
||||
compiling sources in a shared library. If not set here then it is set
|
||||
to target_EXPORTS by default (with some substitutions if the target is
|
||||
not a valid C identifier). This is useful for headers to know whether
|
||||
they are being included from inside their library or outside to
|
||||
properly setup dllexport/dllimport decorations. The COMPILE_FLAGS
|
||||
property sets additional compiler flags used to build sources within
|
||||
the target. It may also be used to pass additional preprocessor
|
||||
definitions.
|
||||
The :prop_tgt:`LINK_FLAGS` property can be used to add extra flags to the
|
||||
link step of a target. :prop_tgt:`LINK_FLAGS_<CONFIG>` will add to the
|
||||
configuration ``<CONFIG>``, for example, ``DEBUG``, ``RELEASE``,
|
||||
``MINSIZEREL``,``RELWITHDEBINFO``. :prop_tgt:`DEFINE_SYMBOL` sets the name
|
||||
of the preprocessor symbol defined when compiling sources in a shared
|
||||
library. If not set here then it is set to target_EXPORTS by default
|
||||
(with some substitutions if the target is not a valid C identifier). This
|
||||
is useful for headers to know whether they are being included from inside
|
||||
their library or outside to properly setup dllexport/dllimport
|
||||
decorations. The :prop_tgt:`COMPILE_FLAGS` property sets additional
|
||||
compiler flags used to build sources within the target. It may also be
|
||||
used to pass additional preprocessor definitions.
|
||||
|
||||
The LINKER_LANGUAGE property is used to change the tool used to link
|
||||
an executable or shared library. The default is set the language to
|
||||
match the files in the library. CXX and C are common values for this
|
||||
The :prop_tgt:`LINKER_LANGUAGE` property is used to change the tool used
|
||||
to link an executable or shared library. The default is set the language to
|
||||
match the files in the library. ``CXX`` and ``C`` are common values for this
|
||||
property.
|
||||
|
||||
For shared libraries VERSION and SOVERSION can be used to specify the
|
||||
build version and API version respectively. When building or
|
||||
installing appropriate symlinks are created if the platform supports
|
||||
symlinks and the linker supports so-names. If only one of both is
|
||||
For shared libraries :prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` can be
|
||||
used to specify the build version and API version respectively. When
|
||||
building or installing appropriate symlinks are created if the platform
|
||||
supports symlinks and the linker supports so-names. If only one of both is
|
||||
specified the missing is assumed to have the same version number. For
|
||||
executables VERSION can be used to specify the build version. When
|
||||
building or installing appropriate symlinks are created if the
|
||||
platform supports symlinks. For shared libraries and executables on
|
||||
Windows the VERSION attribute is parsed to extract a "major.minor"
|
||||
version number. These numbers are used as the image version of the
|
||||
binary.
|
||||
executables :prop_tgt:`VERSION` can be used to specify the build
|
||||
version. When building or installing appropriate symlinks are created if
|
||||
the platform supports symlinks. For shared libraries and executables on
|
||||
Windows the :prop_tgt:`VERSION` attribute is parsed to extract a
|
||||
"major.minor" version number. These numbers are used as the image
|
||||
version of the binary.
|
||||
|
||||
There are a few properties used to specify RPATH rules. INSTALL_RPATH
|
||||
is a semicolon-separated list specifying the rpath to use in installed
|
||||
targets (for platforms that support it). INSTALL_RPATH_USE_LINK_PATH
|
||||
is a boolean that if set to true will append directories in the linker
|
||||
search path and outside the project to the INSTALL_RPATH.
|
||||
SKIP_BUILD_RPATH is a boolean specifying whether to skip automatic
|
||||
generation of an rpath allowing the target to run from the build tree.
|
||||
BUILD_WITH_INSTALL_RPATH is a boolean specifying whether to link the
|
||||
target in the build tree with the INSTALL_RPATH. This takes
|
||||
precedence over SKIP_BUILD_RPATH and avoids the need for relinking
|
||||
before installation. INSTALL_NAME_DIR is a string specifying the
|
||||
There are a few properties used to specify RPATH rules.
|
||||
:prop_tgt:`INSTALL_RPATH` is a semicolon-separated list specifying the
|
||||
rpath to use in installed targets (for platforms that support it).
|
||||
:prop_tgt:`INSTALL_RPATH_USE_LINK_PATH` is a boolean that if set to true
|
||||
will append directories in the linker search path and outside the project
|
||||
to the :prop_tgt:`INSTALL_RPATH`. :prop_tgt:`SKIP_BUILD_RPATH` is a boolean
|
||||
specifying whether to skip automatic generation of an rpath allowing the
|
||||
target to run from the build tree. :prop_tgt:`BUILD_WITH_INSTALL_RPATH` is
|
||||
a boolean specifying whether to link the target in the build tree with the
|
||||
:prop_tgt:`INSTALL_RPATH`. This takes precedence over
|
||||
:prop_tgt:`SKIP_BUILD_RPATH` and avoids the need for relinking before
|
||||
installation. :prop_tgt:`INSTALL_NAME_DIR` is a string specifying the
|
||||
directory portion of the "install_name" field of shared libraries on
|
||||
Mac OSX to use in the installed targets. When the target is created
|
||||
the values of the variables CMAKE_INSTALL_RPATH,
|
||||
CMAKE_INSTALL_RPATH_USE_LINK_PATH, CMAKE_SKIP_BUILD_RPATH,
|
||||
CMAKE_BUILD_WITH_INSTALL_RPATH, and CMAKE_INSTALL_NAME_DIR are used to
|
||||
initialize these properties.
|
||||
the values of the variables :variable:`CMAKE_INSTALL_RPATH`,
|
||||
:variable:`CMAKE_INSTALL_RPATH_USE_LINK_PATH`,
|
||||
:variable:`CMAKE_SKIP_BUILD_RPATH`,
|
||||
:variable:`CMAKE_BUILD_WITH_INSTALL_RPATH`, and
|
||||
:variable:`CMAKE_INSTALL_NAME_DIR` are used to initialize these properties.
|
||||
|
||||
PROJECT_LABEL can be used to change the name of the target in an IDE
|
||||
like visual studio. VS_KEYWORD can be set to change the visual studio
|
||||
keyword, for example Qt integration works better if this is set to
|
||||
Qt4VSv1.0.
|
||||
:prop_tgt:`PROJECT_LABEL` can be used to change the name of the target in
|
||||
an IDE like visual studio. :prop_tgt:`VS_KEYWORD` can be set to change
|
||||
the visual studio keyword, for example Qt integration works better if this
|
||||
is set to ``Qt4VSv1.0``.
|
||||
|
||||
VS_SCC_PROJECTNAME, VS_SCC_LOCALPATH, VS_SCC_PROVIDER and
|
||||
VS_SCC_AUXPATH can be set to add support for source control bindings
|
||||
in a Visual Studio project file.
|
||||
:prop_tgt:`VS_SCC_PROJECTNAME`, :prop_tgt:`VS_SCC_LOCALPATH`,
|
||||
:prop_tgt:`VS_SCC_PROVIDER` and :prop_tgt:`VS_SCC_AUXPATH` can be set to
|
||||
add support for source control bindings in a Visual Studio project file.
|
||||
|
||||
VS_GLOBAL_<variable> can be set to add a Visual Studio
|
||||
:prop_tgt:`VS_GLOBAL_<variable>` can be set to add a Visual Studio
|
||||
project-specific global variable. Qt integration works better if
|
||||
VS_GLOBAL_QtVersion is set to the Qt version FindQt4.cmake found. For
|
||||
example, "4.7.3"
|
||||
``VS_GLOBAL_QtVersion`` is set to the Qt version :module:`FindQt4`
|
||||
found. For example, "4.7.3"
|
||||
|
||||
The PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT properties are the old
|
||||
way to specify CMake scripts to run before and after installing a
|
||||
target. They are used only when the old INSTALL_TARGETS command is
|
||||
used to install the target. Use the INSTALL command instead.
|
||||
The :prop_tgt:`PRE_INSTALL_SCRIPT` and :prop_tgt:`POST_INSTALL_SCRIPT`
|
||||
properties are the old way to specify CMake scripts to run before and
|
||||
after installing a target. They are used only when the old
|
||||
:command:`install_targets` command is used to install the target. Use the
|
||||
:command:`install` command instead.
|
||||
|
||||
The EXCLUDE_FROM_DEFAULT_BUILD property is used by the visual studio
|
||||
generators. If it is set to 1 the target will not be part of the
|
||||
The :prop_tgt:`EXCLUDE_FROM_DEFAULT_BUILD` property is used by the visual
|
||||
studio generators. If it is set to 1 the target will not be part of the
|
||||
default build when you select "Build Solution". This can also be set
|
||||
on a per-configuration basis using
|
||||
EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>.
|
||||
:prop_tgt:`EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>`.
|
||||
|
|
|
|||
|
|
@ -39,41 +39,41 @@ String operations.
|
|||
string(UUID <output variable> NAMESPACE <namespace> NAME <name>
|
||||
TYPE <MD5|SHA1> [UPPER])
|
||||
|
||||
REGEX MATCH will match the regular expression once and store the match
|
||||
``REGEX MATCH`` will match the regular expression once and store the match
|
||||
in the output variable.
|
||||
|
||||
REGEX MATCHALL will match the regular expression as many times as
|
||||
``REGEX MATCHALL`` will match the regular expression as many times as
|
||||
possible and store the matches in the output variable as a list.
|
||||
|
||||
REGEX REPLACE will match the regular expression as many times as
|
||||
``REGEX REPLACE`` will match the regular expression as many times as
|
||||
possible and substitute the replacement expression for the match in
|
||||
the output. The replace expression may refer to paren-delimited
|
||||
subexpressions of the match using \1, \2, ..., \9. Note that two
|
||||
backslashes (\\1) are required in CMake code to get a backslash
|
||||
through argument parsing.
|
||||
|
||||
REPLACE will replace all occurrences of match_string in the input with
|
||||
replace_string and store the result in the output.
|
||||
``REPLACE`` will replace all occurrences of ``match_string`` in the input
|
||||
with ``replace_string`` and store the result in the output.
|
||||
|
||||
CONCAT will concatenate all the input arguments together and store
|
||||
``CONCAT`` will concatenate all the input arguments together and store
|
||||
the result in the named output variable.
|
||||
|
||||
MD5, SHA1, SHA224, SHA256, SHA384, and SHA512 will compute a
|
||||
cryptographic hash of the input string.
|
||||
``MD5``, ``SHA1``, ``SHA224``, ``SHA256``, ``SHA384``, and ``SHA512`` will
|
||||
compute a cryptographic hash of the input string.
|
||||
|
||||
COMPARE EQUAL/NOTEQUAL/LESS/GREATER will compare the strings and store
|
||||
true or false in the output variable.
|
||||
``COMPARE EQUAL``/``COMPARE NOTEQUAL``/``COMPARE LESS/GREATER`` will
|
||||
compare the strings and store true or false in the output variable.
|
||||
|
||||
ASCII will convert all numbers into corresponding ASCII characters.
|
||||
``ASCII`` will convert all numbers into corresponding ASCII characters.
|
||||
|
||||
CONFIGURE will transform a string like CONFIGURE_FILE transforms a
|
||||
file.
|
||||
``CONFIGURE`` will transform a string like :command:`configure_file`
|
||||
transforms a file.
|
||||
|
||||
TOUPPER/TOLOWER will convert string to upper/lower characters.
|
||||
``TOUPPER``/``TOLOWER`` will convert string to upper/lower characters.
|
||||
|
||||
LENGTH will return a given string's length.
|
||||
``LENGTH`` will return a given string's length.
|
||||
|
||||
SUBSTRING will return a substring of a given string. If length is -1
|
||||
``SUBSTRING`` will return a substring of a given string. If length is -1
|
||||
the remainder of the string starting at begin will be returned.
|
||||
If string is shorter than length then end of string is used instead.
|
||||
|
||||
|
|
@ -81,17 +81,17 @@ If string is shorter than length then end of string is used instead.
|
|||
CMake 3.1 and below reported an error if length pointed past
|
||||
the end of string.
|
||||
|
||||
STRIP will return a substring of a given string with leading and
|
||||
``STRIP`` will return a substring of a given string with leading and
|
||||
trailing spaces removed.
|
||||
|
||||
RANDOM will return a random string of given length consisting of
|
||||
``RANDOM`` will return a random string of given length consisting of
|
||||
characters from the given alphabet. Default length is 5 characters
|
||||
and default alphabet is all numbers and upper and lower case letters.
|
||||
If an integer RANDOM_SEED is given, its value will be used to seed the
|
||||
If an integer ``RANDOM_SEED`` is given, its value will be used to seed the
|
||||
random number generator.
|
||||
|
||||
FIND will return the position where the given substring was found in
|
||||
the supplied string. If the REVERSE flag was used, the command will
|
||||
``FIND`` will return the position where the given substring was found in
|
||||
the supplied string. If the ``REVERSE`` flag was used, the command will
|
||||
search for the position of the last occurrence of the specified
|
||||
substring.
|
||||
|
||||
|
|
@ -118,21 +118,21 @@ The following characters have special meaning in regular expressions:
|
|||
by all regular expression-related commands, including
|
||||
e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).
|
||||
|
||||
``*``, ``+`` and ``?`` have higher precedence than concatenation. | has lower
|
||||
precedence than concatenation. This means that the regular expression
|
||||
"^ab+d$" matches "abbd" but not "ababd", and the regular expression
|
||||
"^(ab|cd)$" matches "ab" but not "abd".
|
||||
``*``, ``+`` and ``?`` have higher precedence than concatenation. ``|``
|
||||
has lower precedence than concatenation. This means that the regular
|
||||
expression "^ab+d$" matches "abbd" but not "ababd", and the regular
|
||||
expression "^(ab|cd)$" matches "ab" but not "abd".
|
||||
|
||||
TIMESTAMP will write a string representation of the current date
|
||||
``TIMESTAMP`` will write a string representation of the current date
|
||||
and/or time to the output variable.
|
||||
|
||||
Should the command be unable to obtain a timestamp the output variable
|
||||
will be set to the empty string "".
|
||||
|
||||
The optional UTC flag requests the current date/time representation to
|
||||
The optional ``UTC`` flag requests the current date/time representation to
|
||||
be in Coordinated Universal Time (UTC) rather than local time.
|
||||
|
||||
The optional <format string> may contain the following format
|
||||
The optional ``<format string>`` may contain the following format
|
||||
specifiers:
|
||||
|
||||
::
|
||||
|
|
@ -153,23 +153,23 @@ specifiers:
|
|||
Unknown format specifiers will be ignored and copied to the output
|
||||
as-is.
|
||||
|
||||
If no explicit <format string> is given it will default to:
|
||||
If no explicit ``<format string>`` is given it will default to:
|
||||
|
||||
::
|
||||
|
||||
%Y-%m-%dT%H:%M:%S for local time.
|
||||
%Y-%m-%dT%H:%M:%SZ for UTC.
|
||||
|
||||
MAKE_C_IDENTIFIER will write a string which can be used as an
|
||||
``MAKE_C_IDENTIFIER`` will write a string which can be used as an
|
||||
identifier in C.
|
||||
|
||||
``GENEX_STRIP`` will strip any
|
||||
:manual:`generator expressions <cmake-generator-expressions(7)>` from the
|
||||
``input string`` and store the result in the ``output variable``.
|
||||
|
||||
UUID creates a univerally unique identifier (aka GUID) as per RFC4122
|
||||
based on the hash of the combined values of <namespace>
|
||||
(which itself has to be a valid UUID) and <name>.
|
||||
``UUID`` creates a univerally unique identifier (aka GUID) as per RFC4122
|
||||
based on the hash of the combined values of ``<namespace>``
|
||||
(which itself has to be a valid UUID) and ``<name>``.
|
||||
The hash algorithm can be either ``MD5`` (Version 3 UUID) or
|
||||
``SHA1`` (Version 5 UUID).
|
||||
A UUID has the format ``xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx``
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
subdirs
|
||||
-------
|
||||
|
||||
Deprecated. Use the add_subdirectory() command instead.
|
||||
Deprecated. Use the :command:`add_subdirectory` command instead.
|
||||
|
||||
Add a list of subdirectories to the build.
|
||||
|
||||
|
|
@ -10,12 +10,12 @@ Add a list of subdirectories to the build.
|
|||
subdirs(dir1 dir2 ...[EXCLUDE_FROM_ALL exclude_dir1 exclude_dir2 ...]
|
||||
[PREORDER] )
|
||||
|
||||
Add a list of subdirectories to the build. The add_subdirectory
|
||||
command should be used instead of subdirs although subdirs will still
|
||||
Add a list of subdirectories to the build. The :command:`add_subdirectory`
|
||||
command should be used instead of ``subdirs`` although ``subdirs`` will still
|
||||
work. This will cause any CMakeLists.txt files in the sub directories
|
||||
to be processed by CMake. Any directories after the PREORDER flag are
|
||||
traversed first by makefile builds, the PREORDER flag has no effect on
|
||||
IDE projects. Any directories after the EXCLUDE_FROM_ALL marker will
|
||||
to be processed by CMake. Any directories after the ``PREORDER`` flag are
|
||||
traversed first by makefile builds, the ``PREORDER`` flag has no effect on
|
||||
IDE projects. Any directories after the ``EXCLUDE_FROM_ALL`` marker will
|
||||
not be included in the top level makefile or project file. This is
|
||||
useful for having CMake create makefiles or projects for a set of
|
||||
examples in a project. You would want CMake to generate makefiles or
|
||||
|
|
|
|||
|
|
@ -8,14 +8,14 @@ Unset a variable, cache variable, or environment variable.
|
|||
unset(<variable> [CACHE | PARENT_SCOPE])
|
||||
|
||||
Removes the specified variable causing it to become undefined. If
|
||||
CACHE is present then the variable is removed from the cache instead
|
||||
``CACHE`` is present then the variable is removed from the cache instead
|
||||
of the current scope.
|
||||
|
||||
If PARENT_SCOPE is present then the variable is removed from the scope
|
||||
above the current scope. See the same option in the set() command for
|
||||
further details.
|
||||
If ``PARENT_SCOPE`` is present then the variable is removed from the scope
|
||||
above the current scope. See the same option in the :command:`set` command
|
||||
for further details.
|
||||
|
||||
<variable> can be an environment variable such as:
|
||||
``<variable>`` can be an environment variable such as:
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -12,11 +12,11 @@ Specify the source tree of a third-party utility.
|
|||
|
||||
When a third-party utility's source is included in the distribution,
|
||||
this command specifies its location and name. The cache entry will
|
||||
not be set unless the path_to_source and all listed files exist. It
|
||||
not be set unless the ``path_to_source`` and all listed files exist. It
|
||||
is assumed that the source tree of the utility will have been built
|
||||
before it is needed.
|
||||
|
||||
When cross compiling CMake will print a warning if a utility_source()
|
||||
When cross compiling CMake will print a warning if a ``utility_source()``
|
||||
command is executed, because in many cases it is used to build an
|
||||
executable which is executed later on. This doesn't work when cross
|
||||
compiling, since the executable can run only on their target platform.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ variable_requires
|
|||
|
||||
Disallowed. See CMake Policy :policy:`CMP0035`.
|
||||
|
||||
Use the if() command instead.
|
||||
Use the :command:`if` command instead.
|
||||
|
||||
Assert satisfaction of an option's required variables.
|
||||
|
||||
|
|
@ -13,10 +13,10 @@ Assert satisfaction of an option's required variables.
|
|||
REQUIRED_VARIABLE1
|
||||
REQUIRED_VARIABLE2 ...)
|
||||
|
||||
The first argument (TEST_VARIABLE) is the name of the variable to be
|
||||
The first argument (``TEST_VARIABLE``) is the name of the variable to be
|
||||
tested, if that variable is false nothing else is done. If
|
||||
TEST_VARIABLE is true, then the next argument (RESULT_VARIABLE) is a
|
||||
variable that is set to true if all the required variables are set.
|
||||
``TEST_VARIABLE`` is true, then the next argument (``RESULT_VARIABLE``)
|
||||
is a variable that is set to true if all the required variables are set.
|
||||
The rest of the arguments are variables that must be true or not set
|
||||
to NOTFOUND to avoid an error. If any are not true, an error is
|
||||
reported.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Evaluate a group of commands while a condition is true
|
|||
...
|
||||
endwhile(condition)
|
||||
|
||||
All commands between while and the matching endwhile are recorded
|
||||
without being invoked. Once the endwhile is evaluated, the recorded
|
||||
list of commands is invoked as long as the condition is true. The
|
||||
condition is evaluated using the same logic as the if command.
|
||||
All commands between while and the matching :command:`endwhile` are recorded
|
||||
without being invoked. Once the :command:`endwhile` is evaluated, the
|
||||
recorded list of commands is invoked as long as the condition is true. The
|
||||
condition is evaluated using the same logic as the :command:`if` command.
|
||||
|
|
|
|||
|
|
@ -1,20 +1,20 @@
|
|||
write_file
|
||||
----------
|
||||
|
||||
Deprecated. Use the file(WRITE ) command instead.
|
||||
Deprecated. Use the :command:`file(WRITE)` command instead.
|
||||
|
||||
::
|
||||
|
||||
write_file(filename "message to write"... [APPEND])
|
||||
|
||||
The first argument is the file name, the rest of the arguments are
|
||||
messages to write. If the argument APPEND is specified, then the
|
||||
messages to write. If the argument ``APPEND`` is specified, then the
|
||||
message will be appended.
|
||||
|
||||
NOTE 1: file(WRITE ... and file(APPEND ... do exactly the same as
|
||||
this one but add some more functionality.
|
||||
NOTE 1: :command:`file(WRITE)` and :command:`file(APPEND)` do exactly
|
||||
the same as this one but add some more functionality.
|
||||
|
||||
NOTE 2: When using write_file the produced file cannot be used as an
|
||||
NOTE 2: When using ``write_file`` the produced file cannot be used as an
|
||||
input to CMake (CONFIGURE_FILE, source file ...) because it will lead
|
||||
to an infinite loop. Use configure_file if you want to generate input
|
||||
files to CMake.
|
||||
to an infinite loop. Use :command:`configure_file` if you want to
|
||||
generate input files to CMake.
|
||||
|
|
|
|||
Loading…
Reference in New Issue