amass/qt-build-tools
1
0
Fork 0
mirror of https://github.com/crystalidea/qt-build-tools.git synced 2025-02-24 03:44:48 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

qt 6.5.1: use cmake portable 3.27.7

Browse Source
This commit is contained in:
kleuter 2023-11-01 01:44:24 +01:00
parent 72a8e4201b
commit 67db56d36a
3516 changed files with 72487 additions and 25435 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
6.5.1/_tools/cmake/bin/cmake-gui.exe
View File

Binary file not shown.

BIN
6.5.1/_tools/cmake/bin/cmake.exe
View File

Binary file not shown.

BIN
6.5.1/_tools/cmake/bin/cmcldeps.exe
View File

Binary file not shown.

BIN
6.5.1/_tools/cmake/bin/cpack.exe
View File

Binary file not shown.

BIN
6.5.1/_tools/cmake/bin/ctest.exe
View File

Binary file not shown.

2
6.5.1/_tools/cmake/share/aclocal/cmake.m4
View File

@ -13,7 +13,7 @@ fi
# $2: language (e.g. C/CXX/Fortran)
# $3: The compiler ID, defaults to GNU.
# Possible values are: GNU, Intel, Clang, SunPro, HP, XL, VisualAge, PGI,
# PathScale, Cray, SCO, MSVC
# PathScale, Cray, SCO, MSVC, LCC
# $4: optional extra arguments to cmake, e.g. "-DCMAKE_SIZEOF_VOID_P=8"
# $5: optional path to cmake binary
AC_DEFUN([CMAKE_FIND_PACKAGE], [

38
6.5.1/_tools/cmake/share/bash-completion/completions/cmake
View File

@ -96,7 +96,15 @@ _cmake()
_filedir
return
;;
--build|--install|--open)
--build)
# Seed the reply with non-directory arguments that we know are
# allowed to follow --build. _filedir will then prepend any valid
# directory matches to these.
COMPREPLY=( $( compgen -W "--preset --list-presets" -- "$cur" ) )
_filedir -d
return
;;
--install|--open)
_filedir -d
return
;;
@ -149,6 +157,34 @@ _cmake()
2>/dev/null | grep -v "^cmake version " )' -- "$cur" ) )
return
;;
--list-presets)
local IFS=$'\n'
local quoted
printf -v quoted %q "$cur"
if [[ ! "${IFS}${COMP_WORDS[*]}${IFS}" =~ "${IFS}--build${IFS}" ]]; then
COMPREPLY=( $( compgen -W "configure${IFS}build${IFS}test${IFS}all" -- "$quoted" ) )
fi
return
;;
--preset)
local IFS=$'\n'
local quoted
printf -v quoted %q "$cur"
local build_or_configure="configure"
if [[ "${IFS}${COMP_WORDS[*]}${IFS}" =~ "${IFS}--build${IFS}" ]]; then
build_or_configure="build"
fi
local presets=$( cmake --list-presets="$build_or_configure" 2>/dev/null |
grep -o "^ \".*\"" | sed \
-e "s/^ //g" \
-e "s/\"//g" \
-e 's/ /\\\\ /g' )
COMPREPLY=( $( compgen -W "$presets" -- "$quoted" ) )
return
;;
esac
$split && return

11
6.5.1/_tools/cmake/share/bash-completion/completions/ctest
View File

@ -103,6 +103,17 @@ _ctest()
2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
return
;;
--preset)
local IFS=$'\n'
local quoted
printf -v quoted %q "$cur"
COMPREPLY=( $( compgen -W '$( ctest --list-presets 2>/dev/null |
grep -o "^ \".*\"" | sed \
-e "s/^ //g" \
-e "s/\"//g" \
-e "s/ /\\\\ /g" )' -- "$quoted" ) )
return
;;
esac
if [[ "$cur" == -* ]]; then

11
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/DEVICE_LINK_OPTIONS.txt
View File

@ -1,11 +0,0 @@
When a device link step is involved, which is controlled by
:prop_tgt:`CUDA_SEPARABLE_COMPILATION` and
:prop_tgt:`CUDA_RESOLVE_DEVICE_SYMBOLS` properties and policy :policy:`CMP0105`,
the raw options will be delivered to the host and device link steps (wrapped in
``-Xcompiler`` or equivalent for device link). Options wrapped with
``$<DEVICE_LINK:...>``
:manual:`generator expression <cmake-generator-expressions(7)>` will be used
only for the device link step. Options wrapped with ``$<HOST_LINK:...>``
:manual:`generator expression <cmake-generator-expressions(7)>` will be used
only for the host link step.

9
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/OPTIONS_SHELL.txt
View File

@ -1,9 +0,0 @@
The final set of compile or link options used for a target is constructed by
accumulating options from the current target and the usage requirements of
its dependencies. The set of options is de-duplicated to avoid repetition.
While beneficial for individual options, the de-duplication step can break
up option groups. For example, ``-D A -D B`` becomes ``-D A B``. One may
specify a group of options using shell-like quoting along with a ``SHELL:``
prefix. The ``SHELL:`` prefix is dropped, and the rest of the option string
is parsed using the :command:`separate_arguments` ``UNIX_COMMAND`` mode.
For example, ``"SHELL:-D A" "SHELL:-D B"`` becomes ``-D A -D B``.

51
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/add_compile_options.rst
View File

@ -1,51 +0,0 @@
add_compile_options
-------------------
Add options to the compilation of source files.
.. code-block:: cmake
add_compile_options(<option> ...)
Adds options to the :prop_dir:`COMPILE_OPTIONS` directory property.
These options are used when compiling targets from the current
directory and below.
Arguments
^^^^^^^^^
Arguments to ``add_compile_options`` may use "generator expressions" with
the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
manual for more on defining buildsystem properties.
.. include:: OPTIONS_SHELL.txt
Example
^^^^^^^
Since different compilers support different options, a typical use of
this command is in a compiler-specific conditional clause:
.. code-block:: cmake
if (MSVC)
# warning level 4 and all warnings as errors
add_compile_options(/W4 /WX)
else()
# lots of warnings and all warnings as errors
add_compile_options(-Wall -Wextra -pedantic -Werror)
endif()
See Also
^^^^^^^^
This command can be used to add any options. However, for
adding preprocessor definitions and include directories it is recommended
to use the more specific commands :command:`add_compile_definitions`
and :command:`include_directories`.
The command :command:`target_compile_options` adds target-specific options.
The source file property :prop_sf:`COMPILE_OPTIONS` adds options to one
source file.

281
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/add_custom_command.rst
View File

@ -1,281 +0,0 @@
add_custom_command
------------------
Add a custom build rule to the generated build system.
There are two main signatures for ``add_custom_command``.
Generating Files
^^^^^^^^^^^^^^^^
The first signature is for adding a custom command to produce an output:
.. code-block:: cmake
add_custom_command(OUTPUT output1 [output2 ...]
COMMAND command1 [ARGS] [args1...]
[COMMAND command2 [ARGS] [args2...] ...]
[MAIN_DEPENDENCY depend]
[DEPENDS [depends...]]
[BYPRODUCTS [files...]]
[IMPLICIT_DEPENDS <lang1> depend1
[<lang2> depend2] ...]
[WORKING_DIRECTORY dir]
[COMMENT comment]
[DEPFILE depfile]
[JOB_POOL job_pool]
[VERBATIM] [APPEND] [USES_TERMINAL]
[COMMAND_EXPAND_LISTS])
This defines a command to generate specified ``OUTPUT`` file(s).
A target created in the same directory (``CMakeLists.txt`` file)
that specifies any output of the custom command as a source file
is given a rule to generate the file using the command at build time.
Do not list the output in more than one independent target that
may build in parallel or the two instances of the rule may conflict
(instead use the :command:`add_custom_target` command to drive the
command and make the other targets depend on that one).
In makefile terms this creates a new target in the following form::
OUTPUT: MAIN_DEPENDENCY DEPENDS
COMMAND
The options are:
``APPEND``
Append the ``COMMAND`` and ``DEPENDS`` option values to the custom
command for the first output specified. There must have already
been a previous call to this command with the same output.
The ``COMMENT``, ``MAIN_DEPENDENCY``, and ``WORKING_DIRECTORY``
options are currently ignored when APPEND is given, but may be
used in the future.
``BYPRODUCTS``
Specify the files the command is expected to produce but whose
modification time may or may not be newer than the dependencies.
If a byproduct name is a relative path it will be interpreted
relative to the build tree directory corresponding to the
current source directory.
Each byproduct file will be marked with the :prop_sf:`GENERATED`
source file property automatically.
Explicit specification of byproducts is supported by the
:generator:`Ninja` generator to tell the ``ninja`` build tool
how to regenerate byproducts when they are missing. It is
also useful when other build rules (e.g. custom commands)
depend on the byproducts. Ninja requires a build rule for any
generated file on which another rule depends even if there are
order-only dependencies to ensure the byproducts will be
available before their dependents build.
The :ref:`Makefile Generators` will remove ``BYPRODUCTS`` and other
:prop_sf:`GENERATED` files during ``make clean``.
``COMMAND``
Specify the command-line(s) to execute at build time.
If more than one ``COMMAND`` is specified they will be executed in order,
but *not* necessarily composed into a stateful shell or batch script.
(To run a full script, use the :command:`configure_file` command or the
:command:`file(GENERATE)` command to create it, and then specify
a ``COMMAND`` to launch it.)
The optional ``ARGS`` argument is for backward compatibility and
will be ignored.
If ``COMMAND`` specifies an executable target name (created by the
:command:`add_executable` command), it will automatically be replaced
by the location of the executable created at build time if either of
the following is true:
* The target is not being cross-compiled (i.e. the
:variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
* The target is being cross-compiled and an emulator is provided (i.e.
its :prop_tgt:`CROSSCOMPILING_EMULATOR` target property is set).
In this case, the contents of :prop_tgt:`CROSSCOMPILING_EMULATOR` will be
prepended to the command before the location of the target executable.
If neither of the above conditions are met, it is assumed that the
command name is a program to be found on the ``PATH`` at build time.
Arguments to ``COMMAND`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
Use the ``TARGET_FILE`` generator expression to refer to the location of
a target later in the command line (i.e. as a command argument rather
than as the command to execute).
Whenever a target is used as a command to execute or is mentioned in a
generator expression as a command argument, a target-level dependency
will be added automatically so that the mentioned target will be built
before any target using this custom command. However this does NOT add
a file-level dependency that would cause the custom command to re-run
whenever the executable is recompiled. List target names with
the ``DEPENDS`` option to add such file-level dependencies.
``COMMENT``
Display the given message before the commands are executed at
build time.
``DEPENDS``
Specify files on which the command depends. Each argument is converted
to a dependency as follows:
1. If the argument is the name of a target (created by the
:command:`add_custom_target`, :command:`add_executable`, or
:command:`add_library` command) a target-level dependency is
created to make sure the target is built before any target
using this custom command. Additionally, if the target is an
executable or library, a file-level dependency is created to
cause the custom command to re-run whenever the target is
recompiled.
2. If the argument is an absolute path, a file-level dependency
is created on that path.
3. If the argument is the name of a source file that has been
added to a target or on which a source file property has been set,
a file-level dependency is created on that source file.
4. If the argument is a relative path and it exists in the current
source directory, a file-level dependency is created on that
file in the current source directory.
5. Otherwise, a file-level dependency is created on that path relative
to the current binary directory.
If any dependency is an ``OUTPUT`` of another custom command in the same
directory (``CMakeLists.txt`` file), CMake automatically brings the other
custom command into the target in which this command is built.
A target-level dependency is added if any dependency is listed as
``BYPRODUCTS`` of a target or any of its build events in the same
directory to ensure the byproducts will be available.
If ``DEPENDS`` is not specified, the command will run whenever
the ``OUTPUT`` is missing; if the command does not actually
create the ``OUTPUT``, the rule will always run.
Arguments to ``DEPENDS`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
``COMMAND_EXPAND_LISTS``
Lists in ``COMMAND`` arguments will be expanded, including those
created with
:manual:`generator expressions <cmake-generator-expressions(7)>`,
allowing ``COMMAND`` arguments such as
``${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc``
to be properly expanded.
``IMPLICIT_DEPENDS``
Request scanning of implicit dependencies of an input file.
The language given specifies the programming language whose
corresponding dependency scanner should be used.
Currently only ``C`` and ``CXX`` language scanners are supported.
The language has to be specified for every file in the
``IMPLICIT_DEPENDS`` list. Dependencies discovered from the
scanning are added to those of the custom command at build time.
Note that the ``IMPLICIT_DEPENDS`` option is currently supported
only for Makefile generators and will be ignored by other generators.
``JOB_POOL``
Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
generator. Incompatible with ``USES_TERMINAL``, which implies
the ``console`` pool.
Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
an error by ninja at build time.
``MAIN_DEPENDENCY``
Specify the primary input source file to the command. This is
treated just like any value given to the ``DEPENDS`` option
but also suggests to Visual Studio generators where to hang
the custom command. Each source file may have at most one command
specifying it as its main dependency. A compile command (i.e. for a
library or an executable) counts as an implicit main dependency which
gets silently overwritten by a custom command specification.
``OUTPUT``
Specify the output files the command is expected to produce.
If an output name is a relative path it will be interpreted
relative to the build tree directory corresponding to the
current source directory.
Each output file will be marked with the :prop_sf:`GENERATED`
source file property automatically.
If the output of the custom command is not actually created
as a file on disk it should be marked with the :prop_sf:`SYMBOLIC`
source file property.
``USES_TERMINAL``
The command will be given direct access to the terminal if possible.
With the :generator:`Ninja` generator, this places the command in
the ``console`` :prop_gbl:`pool <JOB_POOLS>`.
``VERBATIM``
All arguments to the commands will be escaped properly for the
build tool so that the invoked command receives each argument
unchanged. Note that one level of escapes is still used by the
CMake language processor before add_custom_command even sees the
arguments. Use of ``VERBATIM`` is recommended as it enables
correct behavior. When ``VERBATIM`` is not given the behavior
is platform specific because there is no protection of
tool-specific special characters.
``WORKING_DIRECTORY``
Execute the command with the given current working directory.
If it is a relative path it will be interpreted relative to the
build tree directory corresponding to the current source directory.
Arguments to ``WORKING_DIRECTORY`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
``DEPFILE``
Specify a ``.d`` depfile for the :generator:`Ninja` generator.
A ``.d`` file holds dependencies usually emitted by the custom
command itself.
Using ``DEPFILE`` with other generators than Ninja is an error.
Build Events
^^^^^^^^^^^^
The second signature adds a custom command to a target such as a
library or executable. This is useful for performing an operation
before or after building the target. The command becomes part of the
target and will only execute when the target itself is built. If the
target is already built, the command will not execute.
.. code-block:: cmake
add_custom_command(TARGET <target>
PRE_BUILD | PRE_LINK | POST_BUILD
COMMAND command1 [ARGS] [args1...]
[COMMAND command2 [ARGS] [args2...] ...]
[BYPRODUCTS [files...]]
[WORKING_DIRECTORY dir]
[COMMENT comment]
[VERBATIM] [USES_TERMINAL]
[COMMAND_EXPAND_LISTS])
This defines a new command that will be associated with building the
specified ``<target>``. The ``<target>`` must be defined in the current
directory; targets defined in other directories may not be specified.
When the command will happen is determined by which
of the following is specified:
``PRE_BUILD``
On :ref:`Visual Studio Generators`, run before any other rules are
executed within the target.
On other generators, run just before ``PRE_LINK`` commands.
``PRE_LINK``
Run after sources have been compiled but before linking the binary
or running the librarian or archiver tool of a static library.
This is not defined for targets created by the
:command:`add_custom_target` command.
``POST_BUILD``
Run after all other rules within the target have been executed.
.. note::
Because generator expressions can be used in custom commands,
it is possible to define ``COMMAND`` lines or whole custom commands
which evaluate to empty strings for certain configurations.
For **Visual Studio 2010 (and newer)** generators these command
lines or custom commands will be omitted for the specific
configuration and no "empty-string-command" will be added.
This allows to add individual build events for every configuration.

187
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/add_library.rst
View File

@ -1,187 +0,0 @@
add_library
-----------
.. only:: html
.. contents::
Add a library to the project using the specified source files.
Normal Libraries
^^^^^^^^^^^^^^^^
.. code-block:: cmake
add_library(<name> [STATIC | SHARED | MODULE]
[EXCLUDE_FROM_ALL]
[source1] [source2 ...])
Adds a library target called ``<name>`` to be built from the source files
listed in the command invocation. (The source files can be omitted here
if they are added later using :command:`target_sources`.) The ``<name>``
corresponds to the logical target name and must be globally unique within
a project. The actual file name of the library built is constructed based
on conventions of the native platform (such as ``lib<name>.a`` or
``<name>.lib``).
``STATIC``, ``SHARED``, or ``MODULE`` may be given to specify the type of
library to be created. ``STATIC`` libraries are archives of object files
for use when linking other targets. ``SHARED`` libraries are linked
dynamically and loaded at runtime. ``MODULE`` libraries are plugins that
are not linked into other targets but may be loaded dynamically at runtime
using dlopen-like functionality. If no type is given explicitly the
type is ``STATIC`` or ``SHARED`` based on whether the current value of the
variable :variable:`BUILD_SHARED_LIBS` is ``ON``. For ``SHARED`` and
``MODULE`` libraries the :prop_tgt:`POSITION_INDEPENDENT_CODE` target
property is set to ``ON`` automatically.
A ``SHARED`` or ``STATIC`` library may be marked with the :prop_tgt:`FRAMEWORK`
target property to create an macOS Framework.
If a library does not export any symbols, it must not be declared as a
``SHARED`` library. For example, a Windows resource DLL or a managed C++/CLI
DLL that exports no unmanaged symbols would need to be a ``MODULE`` library.
This is because CMake expects a ``SHARED`` library to always have an
associated import library on Windows.
By default the library file will be created in the build tree directory
corresponding to the source tree directory in which the command was
invoked. See documentation of the :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY`,
:prop_tgt:`LIBRARY_OUTPUT_DIRECTORY`, and
:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` target properties to change this
location. See documentation of the :prop_tgt:`OUTPUT_NAME` target
property to change the ``<name>`` part of the final file name.
If ``EXCLUDE_FROM_ALL`` is given the corresponding property will be set on
the created target. See documentation of the :prop_tgt:`EXCLUDE_FROM_ALL`
target property for details.
Source arguments to ``add_library`` may use "generator expressions" with
the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
manual for more on defining buildsystem properties.
See also :prop_sf:`HEADER_FILE_ONLY` on what to do if some sources are
pre-processed, and you want to have the original sources reachable from
within IDE.
Imported Libraries
^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
add_library(<name> <SHARED|STATIC|MODULE|OBJECT|UNKNOWN> IMPORTED
[GLOBAL])
An :ref:`IMPORTED library target <Imported Targets>` references a library
file located outside the project. No rules are generated to build it, and
the :prop_tgt:`IMPORTED` target property is ``True``. The target name has
scope in the directory in which it is created and below, but the ``GLOBAL``
option extends visibility. It may be referenced like any target built
within the project. ``IMPORTED`` libraries are useful for convenient
reference from commands like :command:`target_link_libraries`. Details
about the imported library are specified by setting properties whose names
begin in ``IMPORTED_`` and ``INTERFACE_``.
The most important properties are:
* :prop_tgt:`IMPORTED_LOCATION` (and its per-configuration
variant :prop_tgt:`IMPORTED_LOCATION_<CONFIG>`) which specifies the
location of the main library file on disk.
* :prop_tgt:`IMPORTED_OBJECTS` (and :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>`)
for object libraries, specifies the locations of object files on disk.
* :prop_tgt:`PUBLIC_HEADER` files to be installed during :command:`install` invocation
See documentation of the ``IMPORTED_*`` and ``INTERFACE_*`` properties
for more information.
An ``UNKNOWN`` library type is typically only used in the implementation of
:ref:`Find Modules`. It allows the path to an imported library (often found
using the :command:`find_library` command) to be used without having to know
what type of library it is. This is especially useful on Windows where a
static library and a DLL's import library both have the same file extension.
Object Libraries
^^^^^^^^^^^^^^^^
.. code-block:: cmake
add_library(<name> OBJECT <src>...)
Creates an :ref:`Object Library <Object Libraries>`. An object library
compiles source files but does not archive or link their object files into a
library. Instead other targets created by :command:`add_library` or
:command:`add_executable` may reference the objects using an expression of the
form ``$<TARGET_OBJECTS:objlib>`` as a source, where ``objlib`` is the
object library name. For example:
.. code-block:: cmake
add_library(... $<TARGET_OBJECTS:objlib> ...)
add_executable(... $<TARGET_OBJECTS:objlib> ...)
will include objlib's object files in a library and an executable
along with those compiled from their own sources. Object libraries
may contain only sources that compile, header files, and other files
that would not affect linking of a normal library (e.g. ``.txt``).
They may contain custom commands generating such sources, but not
``PRE_BUILD``, ``PRE_LINK``, or ``POST_BUILD`` commands. Some native build
systems (such as Xcode) may not like targets that have only object files, so
consider adding at least one real source file to any target that references
``$<TARGET_OBJECTS:objlib>``.
Alias Libraries
^^^^^^^^^^^^^^^
.. code-block:: cmake
add_library(<name> ALIAS <target>)
Creates an :ref:`Alias Target <Alias Targets>`, such that ``<name>`` can be
used to refer to ``<target>`` in subsequent commands. The ``<name>`` does
not appear in the generated buildsystem as a make target. The ``<target>``
may not be an ``ALIAS``.
An ``ALIAS`` to a non-``GLOBAL`` :ref:`Imported Target <Imported Targets>`
has scope in the directory in which the alias is created and below.
The :prop_tgt:`ALIAS_GLOBAL` target property can be used to check if the
alias is global or not.
``ALIAS`` targets can be used as linkable targets and as targets to
read properties from. They can also be tested for existence with the
regular :command:`if(TARGET)` subcommand. The ``<name>`` may not be used
to modify properties of ``<target>``, that is, it may not be used as the
operand of :command:`set_property`, :command:`set_target_properties`,
:command:`target_link_libraries` etc. An ``ALIAS`` target may not be
installed or exported.
Interface Libraries
^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
add_library(<name> INTERFACE [IMPORTED [GLOBAL]])
Creates an :ref:`Interface Library <Interface Libraries>`. An ``INTERFACE``
library target does not directly create build output, though it may
have properties set on it and it may be installed, exported and
imported. Typically the ``INTERFACE_*`` properties are populated on
the interface target using the commands:
* :command:`set_property`,
* :command:`target_link_libraries(INTERFACE)`,
* :command:`target_link_options(INTERFACE)`,
* :command:`target_include_directories(INTERFACE)`,
* :command:`target_compile_options(INTERFACE)`,
* :command:`target_compile_definitions(INTERFACE)`, and
* :command:`target_sources(INTERFACE)`,
and then it is used as an argument to :command:`target_link_libraries`
like any other target.
An ``INTERFACE`` :ref:`Imported Target <Imported Targets>` may also be
created with this signature. An ``IMPORTED`` library target references a
library defined outside the project. The target name has scope in the
directory in which it is created and below, but the ``GLOBAL`` option
extends visibility. It may be referenced like any target built within
the project. ``IMPORTED`` libraries are useful for convenient reference
from commands like :command:`target_link_libraries`.

76
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/add_test.rst
View File

@ -1,76 +0,0 @@
add_test
--------
Add a test to the project to be run by :manual:`ctest(1)`.
.. code-block:: cmake
add_test(NAME <name> COMMAND <command> [<arg>...]
[CONFIGURATIONS <config>...]
[WORKING_DIRECTORY <dir>]
[COMMAND_EXPAND_LISTS])
Adds a test called ``<name>``. The test name may not contain spaces,
quotes, or other characters special in CMake syntax. The options are:
``COMMAND``
Specify the test command-line. If ``<command>`` specifies an
executable target (created by :command:`add_executable`) it will
automatically be replaced by the location of the executable created
at build time.
``CONFIGURATIONS``
Restrict execution of the test only to the named configurations.
``WORKING_DIRECTORY``
Set the :prop_test:`WORKING_DIRECTORY` test property to
specify the working directory in which to execute the test.
If not specified the test will be run with the current working
directory set to the build directory corresponding to the
current source directory.
``COMMAND_EXPAND_LISTS``
Lists in ``COMMAND`` arguments will be expanded, including those
created with
:manual:`generator expressions <cmake-generator-expressions(7)>`.
The given test command is expected to exit with code ``0`` to pass and
non-zero to fail, or vice-versa if the :prop_test:`WILL_FAIL` test
property is set. Any output written to stdout or stderr will be
captured by :manual:`ctest(1)` but does not affect the pass/fail status
unless the :prop_test:`PASS_REGULAR_EXPRESSION`,
:prop_test:`FAIL_REGULAR_EXPRESSION` or
:prop_test:`SKIP_REGULAR_EXPRESSION` test property is used.
The ``COMMAND`` and ``WORKING_DIRECTORY`` options may use "generator
expressions" with the syntax ``$<...>``. See the
:manual:`cmake-generator-expressions(7)` manual for available expressions.
Example usage:
.. code-block:: cmake
add_test(NAME mytest
COMMAND testDriver --config $<CONFIGURATION>
--exe $<TARGET_FILE:myexe>)
This creates a test ``mytest`` whose command runs a ``testDriver`` tool
passing the configuration name and the full path to the executable
file produced by target ``myexe``.
.. note::
CMake will generate tests only if the :command:`enable_testing`
command has been invoked. The :module:`CTest` module invokes the
command automatically unless the ``BUILD_TESTING`` option is turned
``OFF``.
---------------------------------------------------------------------
.. code-block:: cmake
add_test(<name> <command> [<arg>...])
Add a test called ``<name>`` with the given command-line. Unlike
the above ``NAME`` signature no transformation is performed on the
command-line to support target names or generator expressions.

50
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/cmake_host_system_information.rst
View File

@ -1,50 +0,0 @@
cmake_host_system_information
-----------------------------
Query host system specific information.
.. code-block:: cmake
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>``.
``<key>`` can be one of the following values:
============================= ================================================
Key Description
============================= ================================================
``NUMBER_OF_LOGICAL_CORES`` Number of logical cores
``NUMBER_OF_PHYSICAL_CORES`` Number of physical cores
``HOSTNAME`` Hostname
``FQDN`` Fully qualified domain name
``TOTAL_VIRTUAL_MEMORY`` Total virtual memory in MiB [#mebibytes]_
``AVAILABLE_VIRTUAL_MEMORY`` Available virtual memory in MiB [#mebibytes]_
``TOTAL_PHYSICAL_MEMORY`` Total physical memory in MiB [#mebibytes]_
``AVAILABLE_PHYSICAL_MEMORY`` Available physical memory in MiB [#mebibytes]_
``IS_64BIT`` One if processor is 64Bit
``HAS_FPU`` One if processor has floating point unit
``HAS_MMX`` One if processor supports MMX instructions
``HAS_MMX_PLUS`` One if processor supports Ext. MMX instructions
``HAS_SSE`` One if processor supports SSE instructions
``HAS_SSE2`` One if processor supports SSE2 instructions
``HAS_SSE_FP`` One if processor supports SSE FP instructions
``HAS_SSE_MMX`` One if processor supports SSE MMX instructions
``HAS_AMD_3DNOW`` One if processor supports 3DNow instructions
``HAS_AMD_3DNOW_PLUS`` One if processor supports 3DNow+ instructions
``HAS_IA64`` One if IA64 processor emulating x86
``HAS_SERIAL_NUMBER`` One if processor has serial number
``PROCESSOR_SERIAL_NUMBER`` Processor serial number
``PROCESSOR_NAME`` Human readable processor name
``PROCESSOR_DESCRIPTION`` Human readable full processor description
``OS_NAME`` See :variable:`CMAKE_HOST_SYSTEM_NAME`
``OS_RELEASE`` The OS sub-type e.g. on Windows ``Professional``
``OS_VERSION`` The OS build ID
``OS_PLATFORM`` See :variable:`CMAKE_HOST_SYSTEM_PROCESSOR`
============================= ================================================
.. rubric:: Footnotes
.. [#mebibytes] One MiB (mebibyte) is equal to 1024x1024 bytes.

99
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/cmake_language.rst
View File

@ -1,99 +0,0 @@
cmake_language
--------------
Call meta-operations on CMake commands.
Synopsis
^^^^^^^^
.. parsed-literal::
cmake_language(`CALL`_ <command> [<args>...])
cmake_language(`EVAL`_ CODE <code>...)
Introduction
^^^^^^^^^^^^
This command will call meta-operations on built-in CMake commands or
those created via the :command:`macro` or :command:`function` commands.
``cmake_language`` does not introduce a new variable or policy scope.
Calling Commands
^^^^^^^^^^^^^^^^
.. _CALL:
.. code-block:: cmake
cmake_language(CALL <command> [<args>...])
Calls the named ``<command>`` with the given arguments (if any).
For example, the code:
.. code-block:: cmake
set(message_command "message")
cmake_language(CALL ${message_command} STATUS "Hello World!")
is equivalent to
.. code-block:: cmake
message(STATUS "Hello World!")
.. note::
To ensure consistency of the code, the following commands are not allowed:
* ``if`` / ``elseif`` / ``else`` / ``endif``
* ``while`` / ``endwhile``
* ``foreach`` / ``endforeach``
* ``function`` / ``endfunction``
* ``macro`` / ``endmacro``
Evaluating Code
^^^^^^^^^^^^^^^
.. _EVAL:
.. code-block:: cmake
cmake_language(EVAL CODE <code>...)
Evaluates the ``<code>...`` as CMake code.
For example, the code:
.. code-block:: cmake
set(A TRUE)
set(B TRUE)
set(C TRUE)
set(condition "(A AND B) OR C")
cmake_language(EVAL CODE "
if (${condition})
message(STATUS TRUE)
else()
message(STATUS FALSE)
endif()"
)
is equivalent to
.. code-block:: cmake
set(A TRUE)
set(B TRUE)
set(C TRUE)
set(condition "(A AND B) OR C")
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/eval.cmake "
if (${condition})
message(STATUS TRUE)
else()
message(STATUS FALSE)
endif()"
)
include(${CMAKE_CURRENT_BINARY_DIR}/eval.cmake)

14
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/continue.rst
View File

@ -1,14 +0,0 @@
continue
--------
Continue to the top of enclosing foreach or while loop.
.. code-block:: cmake
continue()
The ``continue`` command allows a cmake script to abort the rest of a block
in a :command:`foreach` or :command:`while` loop, and start at the top of
the next iteration.
See also the :command:`break` command.

144
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/ctest_test.rst
View File

@ -1,144 +0,0 @@
ctest_test
----------
Perform the :ref:`CTest Test Step` as a :ref:`Dashboard Client`.
::
ctest_test([BUILD <build-dir>] [APPEND]
[START <start-number>]
[END <end-number>]
[STRIDE <stride-number>]
[EXCLUDE <exclude-regex>]
[INCLUDE <include-regex>]
[EXCLUDE_LABEL <label-exclude-regex>]
[INCLUDE_LABEL <label-include-regex>]
[EXCLUDE_FIXTURE <regex>]
[EXCLUDE_FIXTURE_SETUP <regex>]
[EXCLUDE_FIXTURE_CLEANUP <regex>]
[PARALLEL_LEVEL <level>]
[RESOURCE_SPEC_FILE <file>]
[TEST_LOAD <threshold>]
[SCHEDULE_RANDOM <ON|OFF>]
[STOP_ON_FAILURE]
[STOP_TIME <time-of-day>]
[RETURN_VALUE <result-var>]
[CAPTURE_CMAKE_ERROR <result-var>]
[REPEAT <mode>:<n>]
[QUIET]
)
Run tests in the project build tree and store results in
``Test.xml`` for submission with the :command:`ctest_submit` command.
The options are:
``BUILD <build-dir>``
Specify the top-level build directory. If not given, the
:variable:`CTEST_BINARY_DIRECTORY` variable is used.
``APPEND``
Mark ``Test.xml`` for append to results previously submitted to a
dashboard server since the last :command:`ctest_start` call.
Append semantics are defined by the dashboard server in use.
This does *not* cause results to be appended to a ``.xml`` file
produced by a previous call to this command.
``START <start-number>``
Specify the beginning of a range of test numbers.
``END <end-number>``
Specify the end of a range of test numbers.
``STRIDE <stride-number>``
Specify the stride by which to step across a range of test numbers.
``EXCLUDE <exclude-regex>``
Specify a regular expression matching test names to exclude.
``INCLUDE <include-regex>``
Specify a regular expression matching test names to include.
Tests not matching this expression are excluded.
``EXCLUDE_LABEL <label-exclude-regex>``
Specify a regular expression matching test labels to exclude.
``INCLUDE_LABEL <label-include-regex>``
Specify a regular expression matching test labels to include.
Tests not matching this expression are excluded.
``EXCLUDE_FIXTURE <regex>``
If a test in the set of tests to be executed requires a particular fixture,
that fixture's setup and cleanup tests would normally be added to the test
set automatically. This option prevents adding setup or cleanup tests for
fixtures matching the ``<regex>``. Note that all other fixture behavior is
retained, including test dependencies and skipping tests that have fixture
setup tests that fail.
``EXCLUDE_FIXTURE_SETUP <regex>``
Same as ``EXCLUDE_FIXTURE`` except only matching setup tests are excluded.
``EXCLUDE_FIXTURE_CLEANUP <regex>``
Same as ``EXCLUDE_FIXTURE`` except only matching cleanup tests are excluded.
``PARALLEL_LEVEL <level>``
Specify a positive number representing the number of tests to
be run in parallel.
``RESOURCE_SPEC_FILE <file>``
Specify a
:ref:`resource specification file <ctest-resource-specification-file>`. See
:ref:`ctest-resource-allocation` for more information.
``TEST_LOAD <threshold>``
While running tests in parallel, try not to start tests when they
may cause the CPU load to pass above a given threshold. If not
specified the :variable:`CTEST_TEST_LOAD` variable will be checked,
and then the ``--test-load`` command-line argument to :manual:`ctest(1)`.
See also the ``TestLoad`` setting in the :ref:`CTest Test Step`.
``REPEAT <mode>:<n>``
Run tests repeatedly based on the given ``<mode>`` up to ``<n>`` times.
The modes are:
``UNTIL_FAIL``
Require each test to run ``<n>`` times without failing in order to pass.
This is useful in finding sporadic failures in test cases.
``UNTIL_PASS``
Allow each test to run up to ``<n>`` times in order to pass.
Repeats tests if they fail for any reason.
This is useful in tolerating sporadic failures in test cases.
``AFTER_TIMEOUT``
Allow each test to run up to ``<n>`` times in order to pass.
Repeats tests only if they timeout.
This is useful in tolerating sporadic timeouts in test cases
on busy machines.
``SCHEDULE_RANDOM <ON|OFF>``
Launch tests in a random order. This may be useful for detecting
implicit test dependencies.
``STOP_ON_FAILURE``
Stop the execution of the tests once one has failed.
``STOP_TIME <time-of-day>``
Specify a time of day at which the tests should all stop running.
``RETURN_VALUE <result-var>``
Store in the ``<result-var>`` variable ``0`` if all tests passed.
Store non-zero if anything went wrong.
``CAPTURE_CMAKE_ERROR <result-var>``
Store in the ``<result-var>`` variable -1 if there are any errors running
the command and prevent ctest from returning non-zero if an error occurs.
``QUIET``
Suppress any CTest-specific non-error messages that would have otherwise
been printed to the console. Output from the underlying test command is not
affected. Summary info detailing the percentage of passing tests is also
unaffected by the ``QUIET`` option.
See also the :variable:`CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE`
and :variable:`CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE` variables.

86
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/export.rst
View File

@ -1,86 +0,0 @@
export
------
Export targets from the build tree for use by outside projects.
.. code-block:: cmake
export(EXPORT <export-name> [NAMESPACE <namespace>] [FILE <filename>])
Creates 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
names written to the file.
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 :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.
.. code-block:: cmake
export(TARGETS [target1 [target2 [...]]] [NAMESPACE <namespace>]
[APPEND] FILE <filename> [EXPORT_LINK_INTERFACE_LIBRARIES])
This signature is similar to the ``EXPORT`` signature, but targets are listed
explicitly rather than specified as an export-name. If the APPEND option is
given the generated code will be appended to the file instead of overwriting it.
The EXPORT_LINK_INTERFACE_LIBRARIES keyword, if present, causes the
contents of the properties matching
``(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?`` to be exported, when
policy CMP0022 is NEW. If a library target is included in the export
but a target to which it links is not included the behavior is
unspecified.
.. note::
:ref:`Object Libraries` under :generator:`Xcode` have special handling if
multiple architectures are listed in :variable:`CMAKE_OSX_ARCHITECTURES`.
In this case they will be exported as :ref:`Interface Libraries` with
no object files available to clients. This is sufficient to satisfy
transitive usage requirements of other targets that link to the
object libraries in their implementation.
.. code-block:: cmake
export(PACKAGE <PackageName>)
Store the current build directory in the CMake user package registry
for package ``<PackageName>``. The :command:`find_package` command may consider the
directory while searching for package ``<PackageName>``. 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 (``<PackageName>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.
By default the ``export(PACKAGE)`` command does nothing (see policy
:policy:`CMP0090`) because populating the user package registry has effects
outside the source and build trees. Set the
:variable:`CMAKE_EXPORT_PACKAGE_REGISTRY` variable to add build directories to
the CMake user package registry.
.. code-block:: cmake
export(TARGETS [target1 [target2 [...]]] [ANDROID_MK <filename>])
This signature exports cmake built targets to the android ndk build system
by creating an Android.mk file that references the prebuilt targets. The
Android NDK supports the use of prebuilt libraries, both static and shared.
This allows cmake to build the libraries of a project and make them available
to an ndk build system complete with transitive dependencies, include flags
and defines required to use the libraries. The signature takes a list of
targets and puts them in the Android.mk file specified by the ``<filename>``
given. This signature can only be used if policy CMP0022 is NEW for all
targets given. A error will be issued if that policy is set to OLD for one
of the targets.

955
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/file.rst
View File

@ -1,955 +0,0 @@
file
----
File manipulation command.
Synopsis
^^^^^^^^
.. parsed-literal::
`Reading`_
file(`READ`_ <filename> <out-var> [...])
file(`STRINGS`_ <filename> <out-var> [...])
file(`\<HASH\> <HASH_>`_ <filename> <out-var>)
file(`TIMESTAMP`_ <filename> <out-var> [...])
file(`GET_RUNTIME_DEPENDENCIES`_ [...])
`Writing`_
file({`WRITE`_ | `APPEND`_} <filename> <content>...)
file({`TOUCH`_ | `TOUCH_NOCREATE`_} [<file>...])
file(`GENERATE`_ OUTPUT <output-file> [...])
file(`CONFIGURE`_ OUTPUT <output-file> CONTENT <content> [...])
`Filesystem`_
file({`GLOB`_ | `GLOB_RECURSE`_} <out-var> [...] [<globbing-expr>...])
file(`RENAME`_ <oldname> <newname>)
file({`REMOVE`_ | `REMOVE_RECURSE`_ } [<files>...])
file(`MAKE_DIRECTORY`_ [<dir>...])
file({`COPY`_ | `INSTALL`_} <file>... DESTINATION <dir> [...])
file(`SIZE`_ <filename> <out-var>)
file(`READ_SYMLINK`_ <linkname> <out-var>)
file(`CREATE_LINK`_ <original> <linkname> [...])
`Path Conversion`_
file(`RELATIVE_PATH`_ <out-var> <directory> <file>)
file({`TO_CMAKE_PATH`_ | `TO_NATIVE_PATH`_} <path> <out-var>)
`Transfer`_
file(`DOWNLOAD`_ <url> <file> [...])
file(`UPLOAD`_ <file> <url> [...])
`Locking`_
file(`LOCK`_ <path> [...])
`Archiving`_
file(`ARCHIVE_CREATE`_ OUTPUT <archive> PATHS <paths>... [...])
file(`ARCHIVE_EXTRACT`_ INPUT <archive> [...])
Reading
^^^^^^^
.. _READ:
.. code-block:: cmake
file(READ <filename> <variable>
[OFFSET <offset>] [LIMIT <max-in>] [HEX])
Read content from a file called ``<filename>`` and store it in a
``<variable>``. Optionally start from the given ``<offset>`` and
read at most ``<max-in>`` bytes. The ``HEX`` option causes data to
be converted to a hexadecimal representation (useful for binary data). If the
``HEX`` option is specified, letters in the output (``a`` through ``f``) are in
lowercase.
.. _STRINGS:
.. code-block:: cmake
file(STRINGS <filename> <variable> [<options>...])
Parse a list of ASCII strings from ``<filename>`` and store it in
``<variable>``. Binary data in the file are ignored. Carriage return
(``\r``, CR) characters are ignored. The options are:
``LENGTH_MAXIMUM <max-len>``
Consider only strings of at most a given length.
``LENGTH_MINIMUM <min-len>``
Consider only strings of at least a given length.
``LIMIT_COUNT <max-num>``
Limit the number of distinct strings to be extracted.
``LIMIT_INPUT <max-in>``
Limit the number of input bytes to read from the file.
``LIMIT_OUTPUT <max-out>``
Limit the number of total bytes to store in the ``<variable>``.
``NEWLINE_CONSUME``
Treat newline characters (``\n``, LF) as part of string content
instead of terminating at them.
``NO_HEX_CONVERSION``
Intel Hex and Motorola S-record files are automatically converted to
binary while reading unless this option is given.
``REGEX <regex>``
Consider only strings that match the given regular expression.
``ENCODING <encoding-type>``
Consider strings of a given encoding. Currently supported encodings are:
UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE. If the ENCODING option
is not provided and the file has a Byte Order Mark, the ENCODING option
will be defaulted to respect the Byte Order Mark.
For example, the code
.. code-block:: cmake
file(STRINGS myfile.txt myfile)
stores a list in the variable ``myfile`` in which each item is a line
from the input file.
.. _HASH:
.. code-block:: cmake
file(<HASH> <filename> <variable>)
Compute a cryptographic hash of the content of ``<filename>`` and
store it in a ``<variable>``. The supported ``<HASH>`` algorithm names
are those listed by the :ref:`string(\<HASH\>) <Supported Hash Algorithms>`
command.
.. _TIMESTAMP:
.. code-block:: cmake
file(TIMESTAMP <filename> <variable> [<format>] [UTC])
Compute a string representation of the modification time of ``<filename>``
and store it in ``<variable>``. Should the command be unable to obtain a
timestamp variable will be set to the empty string ("").
See the :command:`string(TIMESTAMP)` command for documentation of
the ``<format>`` and ``UTC`` options.
.. _GET_RUNTIME_DEPENDENCIES:
.. code-block:: cmake
file(GET_RUNTIME_DEPENDENCIES
[RESOLVED_DEPENDENCIES_VAR <deps_var>]
[UNRESOLVED_DEPENDENCIES_VAR <unresolved_deps_var>]
[CONFLICTING_DEPENDENCIES_PREFIX <conflicting_deps_prefix>]
[EXECUTABLES [<executable_files>...]]
[LIBRARIES [<library_files>...]]
[MODULES [<module_files>...]]
[DIRECTORIES [<directories>...]]
[BUNDLE_EXECUTABLE <bundle_executable_file>]
[PRE_INCLUDE_REGEXES [<regexes>...]]
[PRE_EXCLUDE_REGEXES [<regexes>...]]
[POST_INCLUDE_REGEXES [<regexes>...]]
[POST_EXCLUDE_REGEXES [<regexes>...]]
)
Recursively get the list of libraries depended on by the given files.
Please note that this sub-command is not intended to be used in project mode.
Instead, use it in an :command:`install(CODE)` or :command:`install(SCRIPT)`
block. For example:
.. code-block:: cmake
install(CODE [[
file(GET_RUNTIME_DEPENDENCIES
# ...
)
]])
The arguments are as follows:
``RESOLVED_DEPENDENCIES_VAR <deps_var>``
Name of the variable in which to store the list of resolved dependencies.
``UNRESOLVED_DEPENDENCIES_VAR <unresolved_deps_var>``
Name of the variable in which to store the list of unresolved dependencies.
If this variable is not specified, and there are any unresolved dependencies,
an error is issued.
``CONFLICTING_DEPENDENCIES_PREFIX <conflicting_deps_prefix>``
Variable prefix in which to store conflicting dependency information.
Dependencies are conflicting if two files with the same name are found in
two different directories. The list of filenames that conflict are stored in
``<conflicting_deps_prefix>_FILENAMES``. For each filename, the list of paths
that were found for that filename are stored in
``<conflicting_deps_prefix>_<filename>``.
``EXECUTABLES <executable_files>``
List of executable files to read for dependencies. These are executables that
are typically created with :command:`add_executable`, but they do not have to
be created by CMake. On Apple platforms, the paths to these files determine
the value of ``@executable_path`` when recursively resolving the libraries.
Specifying any kind of library (``STATIC``, ``MODULE``, or ``SHARED``) here
will result in undefined behavior.
``LIBRARIES <library_files>``
List of library files to read for dependencies. These are libraries that are
typically created with :command:`add_library(SHARED)`, but they do not have
to be created by CMake. Specifying ``STATIC`` libraries, ``MODULE``
libraries, or executables here will result in undefined behavior.
``MODULES <module_files>``
List of loadable module files to read for dependencies. These are modules
that are typically created with :command:`add_library(MODULE)`, but they do
not have to be created by CMake. They are typically used by calling
``dlopen()`` at runtime rather than linked at link time with ``ld -l``.
Specifying ``STATIC`` libraries, ``SHARED`` libraries, or executables here
will result in undefined behavior.
``DIRECTORIES <directories>``
List of additional directories to search for dependencies. On Linux
platforms, these directories are searched if the dependency is not found in
any of the other usual paths. If it is found in such a directory, a warning
is issued, because it means that the file is incomplete (it does not list all
of the directories that contain its dependencies). On Windows platforms,
these directories are searched if the dependency is not found in any of the
other search paths, but no warning is issued, because searching other paths
is a normal part of Windows dependency resolution. On Apple platforms, this
argument has no effect.
``BUNDLE_EXECUTABLE <bundle_executable_file>``
Executable to treat as the "bundle executable" when resolving libraries. On
Apple platforms, this argument determines the value of ``@executable_path``
when recursively resolving libraries for ``LIBRARIES`` and ``MODULES`` files.
It has no effect on ``EXECUTABLES`` files. On other platforms, it has no
effect. This is typically (but not always) one of the executables in the
``EXECUTABLES`` argument which designates the "main" executable of the
package.
The following arguments specify filters for including or excluding libraries to
be resolved. See below for a full description of how they work.
``PRE_INCLUDE_REGEXES <regexes>``
List of pre-include regexes through which to filter the names of
not-yet-resolved dependencies.
``PRE_EXCLUDE_REGEXES <regexes>``
List of pre-exclude regexes through which to filter the names of
not-yet-resolved dependencies.
``POST_INCLUDE_REGEXES <regexes>``
List of post-include regexes through which to filter the names of resolved
dependencies.
``POST_EXCLUDE_REGEXES <regexes>``
List of post-exclude regexes through which to filter the names of resolved
dependencies.
These arguments can be used to exclude unwanted system libraries when
resolving the dependencies, or to include libraries from a specific
directory. The filtering works as follows:
1. If the not-yet-resolved dependency matches any of the
``PRE_INCLUDE_REGEXES``, steps 2 and 3 are skipped, and the dependency
resolution proceeds to step 4.
2. If the not-yet-resolved dependency matches any of the
``PRE_EXCLUDE_REGEXES``, dependency resolution stops for that dependency.
3. Otherwise, dependency resolution proceeds.
4. ``file(GET_RUNTIME_DEPENDENCIES)`` searches for the dependency according to
the linking rules of the platform (see below).
5. If the dependency is found, and its full path matches one of the
``POST_INCLUDE_REGEXES``, the full path is added to the resolved
dependencies, and ``file(GET_RUNTIME_DEPENDENCIES)`` recursively resolves
that library's own dependencies. Otherwise, resolution proceeds to step 6.
6. If the dependency is found, but its full path matches one of the
``POST_EXCLUDE_REGEXES``, it is not added to the resolved dependencies, and
dependency resolution stops for that dependency.
7. If the dependency is found, and its full path does not match either
``POST_INCLUDE_REGEXES`` or ``POST_EXCLUDE_REGEXES``, the full path is added
to the resolved dependencies, and ``file(GET_RUNTIME_DEPENDENCIES)``
recursively resolves that library's own dependencies.
Different platforms have different rules for how dependencies are resolved.
These specifics are described here.
On Linux platforms, library resolution works as follows:
1. If the depending file does not have any ``RUNPATH`` entries, and the library
exists in one of the depending file's ``RPATH`` entries, or its parents', in
that order, the dependency is resolved to that file.
2. Otherwise, if the depending file has any ``RUNPATH`` entries, and the
library exists in one of those entries, the dependency is resolved to that
file.
3. Otherwise, if the library exists in one of the directories listed by
``ldconfig``, the dependency is resolved to that file.
4. Otherwise, if the library exists in one of the ``DIRECTORIES`` entries, the
dependency is resolved to that file. In this case, a warning is issued,
because finding a file in one of the ``DIRECTORIES`` means that the
depending file is not complete (it does not list all the directories from
which it pulls dependencies).
5. Otherwise, the dependency is unresolved.
On Windows platforms, library resolution works as follows:
1. The dependent DLL name is converted to lowercase. Windows DLL names are
case-insensitive, and some linkers mangle the case of the DLL dependency
names. However, this makes it more difficult for ``PRE_INCLUDE_REGEXES``,
``PRE_EXCLUDE_REGEXES``, ``POST_INCLUDE_REGEXES``, and
``POST_EXCLUDE_REGEXES`` to properly filter DLL names - every regex would
have to check for both uppercase and lowercase letters. For example:
.. code-block:: cmake
file(GET_RUNTIME_DEPENDENCIES
# ...
PRE_INCLUDE_REGEXES "^[Mm][Yy][Ll][Ii][Bb][Rr][Aa][Rr][Yy]\\.[Dd][Ll][Ll]$"
)
Converting the DLL name to lowercase allows the regexes to only match
lowercase names, thus simplifying the regex. For example:
.. code-block:: cmake
file(GET_RUNTIME_DEPENDENCIES
# ...
PRE_INCLUDE_REGEXES "^mylibrary\\.dll$"
)
This regex will match ``mylibrary.dll`` regardless of how it is cased,
either on disk or in the depending file. (For example, it will match
``mylibrary.dll``, ``MyLibrary.dll``, and ``MYLIBRARY.DLL``.)
Please note that the directory portion of any resolved DLLs retains its
casing and is not converted to lowercase. Only the filename portion is
converted.
2. (**Not yet implemented**) If the depending file is a Windows Store app, and
the dependency is listed as a dependency in the application's package
manifest, the dependency is resolved to that file.
3. Otherwise, if the library exists in the same directory as the depending
file, the dependency is resolved to that file.
4. Otherwise, if the library exists in either the operating system's
``system32`` directory or the ``Windows`` directory, in that order, the
dependency is resolved to that file.
5. Otherwise, if the library exists in one of the directories specified by
``DIRECTORIES``, in the order they are listed, the dependency is resolved to
that file. In this case, a warning is not issued, because searching other
directories is a normal part of Windows library resolution.
6. Otherwise, the dependency is unresolved.
On Apple platforms, library resolution works as follows:
1. If the dependency starts with ``@executable_path/``, and an ``EXECUTABLES``
argument is in the process of being resolved, and replacing
``@executable_path/`` with the directory of the executable yields an
existing file, the dependency is resolved to that file.
2. Otherwise, if the dependency starts with ``@executable_path/``, and there is
a ``BUNDLE_EXECUTABLE`` argument, and replacing ``@executable_path/`` with
the directory of the bundle executable yields an existing file, the
dependency is resolved to that file.
3. Otherwise, if the dependency starts with ``@loader_path/``, and replacing
``@loader_path/`` with the directory of the depending file yields an
existing file, the dependency is resolved to that file.
4. Otherwise, if the dependency starts with ``@rpath/``, and replacing
``@rpath/`` with one of the ``RPATH`` entries of the depending file yields
an existing file, the dependency is resolved to that file. Note that
``RPATH`` entries that start with ``@executable_path/`` or ``@loader_path/``
also have these items replaced with the appropriate path.
5. Otherwise, if the dependency is an absolute file that exists, the dependency
is resolved to that file.
6. Otherwise, the dependency is unresolved.
This function accepts several variables that determine which tool is used for
dependency resolution:
.. variable:: CMAKE_GET_RUNTIME_DEPENDENCIES_PLATFORM
Determines which operating system and executable format the files are built
for. This could be one of several values:
* ``linux+elf``
* ``windows+pe``
* ``macos+macho``
If this variable is not specified, it is determined automatically by system
introspection.
.. variable:: CMAKE_GET_RUNTIME_DEPENDENCIES_TOOL
Determines the tool to use for dependency resolution. It could be one of
several values, depending on the value of
:variable:`CMAKE_GET_RUNTIME_DEPENDENCIES_PLATFORM`:
================================================= =============================================
``CMAKE_GET_RUNTIME_DEPENDENCIES_PLATFORM`` ``CMAKE_GET_RUNTIME_DEPENDENCIES_TOOL``
================================================= =============================================
``linux+elf`` ``objdump``
``windows+pe`` ``dumpbin``
``windows+pe`` ``objdump``
``macos+macho`` ``otool``
================================================= =============================================
If this variable is not specified, it is determined automatically by system
introspection.
.. variable:: CMAKE_GET_RUNTIME_DEPENDENCIES_COMMAND
Determines the path to the tool to use for dependency resolution. This is the
actual path to ``objdump``, ``dumpbin``, or ``otool``.
If this variable is not specified, it is determined by the value of
``CMAKE_OBJDUMP`` if set, else by system introspection.
Writing
^^^^^^^
.. _WRITE:
.. _APPEND:
.. code-block:: cmake
file(WRITE <filename> <content>...)
file(APPEND <filename> <content>...)
Write ``<content>`` into a file called ``<filename>``. If the file does
not exist, it will be created. If the file already exists, ``WRITE``
mode will overwrite it and ``APPEND`` mode will append to the end.
Any directories in the path specified by ``<filename>`` that do not
exist will be created.
If the file is a build input, use the :command:`configure_file` command
to update the file only when its content changes.
.. _TOUCH:
.. _TOUCH_NOCREATE:
.. code-block:: cmake
file(TOUCH [<files>...])
file(TOUCH_NOCREATE [<files>...])
Create a file with no content if it does not yet exist. If the file already
exists, its access and/or modification will be updated to the time when the
function call is executed.
Use TOUCH_NOCREATE to touch a file if it exists but not create it. If a file
does not exist it will be silently ignored.
With TOUCH and TOUCH_NOCREATE the contents of an existing file will not be
modified.
.. _GENERATE:
.. code-block:: cmake
file(GENERATE OUTPUT output-file
<INPUT input-file|CONTENT content>
[CONDITION expression])
Generate an output file for each build configuration supported by the current
:manual:`CMake Generator <cmake-generators(7)>`. Evaluate
:manual:`generator expressions <cmake-generator-expressions(7)>`
from the input content to produce the output content. The options are:
``CONDITION <condition>``
Generate the output file for a particular configuration only if
the condition is true. The condition must be either ``0`` or ``1``
after evaluating generator expressions.
``CONTENT <content>``
Use the content given explicitly as input.
``INPUT <input-file>``
Use the content from a given file as input.
A relative path is treated with respect to the value of
:variable:`CMAKE_CURRENT_SOURCE_DIR`. See policy :policy:`CMP0070`.
``OUTPUT <output-file>``
Specify the output file name to generate. Use generator expressions
such as ``$<CONFIG>`` to specify a configuration-specific output file
name. Multiple configurations may generate the same output file only
if the generated content is identical. Otherwise, the ``<output-file>``
must evaluate to an unique name for each configuration.
A relative path (after evaluating generator expressions) is treated
with respect to the value of :variable:`CMAKE_CURRENT_BINARY_DIR`.
See policy :policy:`CMP0070`.
Exactly one ``CONTENT`` or ``INPUT`` option must be given. A specific
``OUTPUT`` file may be named by at most one invocation of ``file(GENERATE)``.
Generated files are modified and their timestamp updated on subsequent cmake
runs only if their content is changed.
Note also that ``file(GENERATE)`` does not create the output file until the
generation phase. The output file will not yet have been written when the
``file(GENERATE)`` command returns, it is written only after processing all
of a project's ``CMakeLists.txt`` files.
.. _CONFIGURE:
.. code-block:: cmake
file(CONFIGURE OUTPUT output-file
CONTENT content
[ESCAPE_QUOTES] [@ONLY]
[NEWLINE_STYLE [UNIX|DOS|WIN32|LF|CRLF] ])
Generate an output file using the input given by ``CONTENT`` and substitute
variable values referenced as ``@VAR@`` or ``${VAR}`` contained therein. The
substitution rules behave the same as the :command:`configure_file` command.
In order to match :command:`configure_file`'s behavior, generator expressions
are not supported for both ``OUTPUT`` and ``CONTENT``.
The arguments are:
``OUTPUT <output-file>``
Specify the output file name to generate. A relative path is treated with
respect to the value of :variable:`CMAKE_CURRENT_BINARY_DIR`.
``<output-file>`` does not support generator expressions.
``CONTENT <content>``
Use the content given explicitly as input.
``<content>`` does not support generator expressions.
``ESCAPE_QUOTES``
Escape any substituted quotes with backslashes (C-style).
``@ONLY``
Restrict variable replacement to references of the form ``@VAR@``.
This is useful for configuring scripts that use ``${VAR}`` syntax.
``NEWLINE_STYLE <style>``
Specify the newline style for the output file. Specify
``UNIX`` or ``LF`` for ``\n`` newlines, or specify
``DOS``, ``WIN32``, or ``CRLF`` for ``\r\n`` newlines.
Filesystem
^^^^^^^^^^
.. _GLOB:
.. _GLOB_RECURSE:
.. code-block:: cmake
file(GLOB <variable>
[LIST_DIRECTORIES true|false] [RELATIVE <path>] [CONFIGURE_DEPENDS]
[<globbing-expressions>...])
file(GLOB_RECURSE <variable> [FOLLOW_SYMLINKS]
[LIST_DIRECTORIES true|false] [RELATIVE <path>] [CONFIGURE_DEPENDS]
[<globbing-expressions>...])
Generate a list of files that match the ``<globbing-expressions>`` and
store it into the ``<variable>``. Globbing expressions are similar to
regular expressions, but much simpler. If ``RELATIVE`` flag is
specified, the results will be returned as relative paths to the given
path. The results will be ordered lexicographically.
On Windows and macOS, globbing is case-insensitive even if the underlying
filesystem is case-sensitive (both filenames and globbing expressions are
converted to lowercase before matching). On other platforms, globbing is
case-sensitive.
If the ``CONFIGURE_DEPENDS`` flag is specified, CMake will add logic
to the main build system check target to rerun the flagged ``GLOB`` commands
at build time. If any of the outputs change, CMake will regenerate the build
system.
By default ``GLOB`` lists directories - directories are omitted in result if
``LIST_DIRECTORIES`` is set to false.
.. note::
We do not recommend using GLOB to collect a list of source files from
your source tree. If no CMakeLists.txt file changes when a source is
added or removed then the generated build system cannot know when to
ask CMake to regenerate.
The ``CONFIGURE_DEPENDS`` flag may not work reliably on all generators, or if
a new generator is added in the future that cannot support it, projects using
it will be stuck. Even if ``CONFIGURE_DEPENDS`` works reliably, there is
still a cost to perform the check on every rebuild.
Examples of globbing expressions include::
*.cxx - match all files with extension cxx
*.vt? - match all files with extension vta,...,vtz
f[3-5].txt - match files f3.txt, f4.txt, f5.txt
The ``GLOB_RECURSE`` mode will traverse all the subdirectories of the
matched directory and match the files. Subdirectories that are symlinks
are only traversed if ``FOLLOW_SYMLINKS`` is given or policy
:policy:`CMP0009` is not set to ``NEW``.
By default ``GLOB_RECURSE`` omits directories from result list - setting
``LIST_DIRECTORIES`` to true adds directories to result list.
If ``FOLLOW_SYMLINKS`` is given or policy :policy:`CMP0009` is not set to
``NEW`` then ``LIST_DIRECTORIES`` treats symlinks as directories.
Examples of recursive globbing include::
/dir/*.py - match all python files in /dir and subdirectories
.. _RENAME:
.. code-block:: cmake
file(RENAME <oldname> <newname>)
Move a file or directory within a filesystem from ``<oldname>`` to
``<newname>``, replacing the destination atomically.
.. _REMOVE:
.. _REMOVE_RECURSE:
.. code-block:: cmake
file(REMOVE [<files>...])
file(REMOVE_RECURSE [<files>...])
Remove the given files. The ``REMOVE_RECURSE`` mode will remove the given
files and directories, also non-empty directories. No error is emitted if a
given file does not exist. Relative input paths are evaluated with respect
to the current source directory. Empty input paths are ignored with a warning.
.. _MAKE_DIRECTORY:
.. code-block:: cmake
file(MAKE_DIRECTORY [<directories>...])
Create the given directories and their parents as needed.
.. _COPY:
.. _INSTALL:
.. code-block:: cmake
file(<COPY|INSTALL> <files>... DESTINATION <dir>
[FILE_PERMISSIONS <permissions>...]
[DIRECTORY_PERMISSIONS <permissions>...]
[NO_SOURCE_PERMISSIONS] [USE_SOURCE_PERMISSIONS]
[FOLLOW_SYMLINK_CHAIN]
[FILES_MATCHING]
[[PATTERN <pattern> | REGEX <regex>]
[EXCLUDE] [PERMISSIONS <permissions>...]] [...])
The ``COPY`` signature copies files, directories, and symlinks to a
destination folder. Relative input paths are evaluated with respect
to the current source directory, and a relative destination is
evaluated with respect to the current build directory. Copying
preserves input file timestamps, and optimizes out a file if it exists
at the destination with the same timestamp. Copying preserves input
permissions unless explicit permissions or ``NO_SOURCE_PERMISSIONS``
are given (default is ``USE_SOURCE_PERMISSIONS``).
If ``FOLLOW_SYMLINK_CHAIN`` is specified, ``COPY`` will recursively resolve
the symlinks at the paths given until a real file is found, and install
a corresponding symlink in the destination for each symlink encountered. For
each symlink that is installed, the resolution is stripped of the directory,
leaving only the filename, meaning that the new symlink points to a file in
the same directory as the symlink. This feature is useful on some Unix systems,
where libraries are installed as a chain of symlinks with version numbers, with
less specific versions pointing to more specific versions.
``FOLLOW_SYMLINK_CHAIN`` will install all of these symlinks and the library
itself into the destination directory. For example, if you have the following
directory structure:
* ``/opt/foo/lib/libfoo.so.1.2.3``
* ``/opt/foo/lib/libfoo.so.1.2 -> libfoo.so.1.2.3``
* ``/opt/foo/lib/libfoo.so.1 -> libfoo.so.1.2``
* ``/opt/foo/lib/libfoo.so -> libfoo.so.1``
and you do:
.. code-block:: cmake
file(COPY /opt/foo/lib/libfoo.so DESTINATION lib FOLLOW_SYMLINK_CHAIN)
This will install all of the symlinks and ``libfoo.so.1.2.3`` itself into
``lib``.
See the :command:`install(DIRECTORY)` command for documentation of
permissions, ``FILES_MATCHING``, ``PATTERN``, ``REGEX``, and
``EXCLUDE`` options. Copying directories preserves the structure
of their content even if options are used to select a subset of
files.
The ``INSTALL`` signature differs slightly from ``COPY``: it prints
status messages (subject to the :variable:`CMAKE_INSTALL_MESSAGE` variable),
and ``NO_SOURCE_PERMISSIONS`` is default.
Installation scripts generated by the :command:`install` command
use this signature (with some undocumented options for internal use).
.. _SIZE:
.. code-block:: cmake
file(SIZE <filename> <variable>)
Determine the file size of the ``<filename>`` and put the result in
``<variable>`` variable. Requires that ``<filename>`` is a valid path
pointing to a file and is readable.
.. _READ_SYMLINK:
.. code-block:: cmake
file(READ_SYMLINK <linkname> <variable>)
This subcommand queries the symlink ``<linkname>`` and stores the path it
points to in the result ``<variable>``. If ``<linkname>`` does not exist or
is not a symlink, CMake issues a fatal error.
Note that this command returns the raw symlink path and does not resolve
a relative path. The following is an example of how to ensure that an
absolute path is obtained:
.. code-block:: cmake
set(linkname "/path/to/foo.sym")
file(READ_SYMLINK "${linkname}" result)
if(NOT IS_ABSOLUTE "${result}")
get_filename_component(dir "${linkname}" DIRECTORY)
set(result "${dir}/${result}")
endif()
.. _CREATE_LINK:
.. code-block:: cmake
file(CREATE_LINK <original> <linkname>
[RESULT <result>] [COPY_ON_ERROR] [SYMBOLIC])
Create a link ``<linkname>`` that points to ``<original>``.
It will be a hard link by default, but providing the ``SYMBOLIC`` option
results in a symbolic link instead. Hard links require that ``original``
exists and is a file, not a directory. If ``<linkname>`` already exists,
it will be overwritten.
The ``<result>`` variable, if specified, receives the status of the operation.
It is set to ``0`` upon success or an error message otherwise. If ``RESULT``
is not specified and the operation fails, a fatal error is emitted.
Specifying ``COPY_ON_ERROR`` enables copying the file as a fallback if
creating the link fails. It can be useful for handling situations such as
``<original>`` and ``<linkname>`` being on different drives or mount points,
which would make them unable to support a hard link.
Path Conversion
^^^^^^^^^^^^^^^
.. _RELATIVE_PATH:
.. code-block:: cmake
file(RELATIVE_PATH <variable> <directory> <file>)
Compute the relative path from a ``<directory>`` to a ``<file>`` and
store it in the ``<variable>``.
.. _TO_CMAKE_PATH:
.. _TO_NATIVE_PATH:
.. code-block:: cmake
file(TO_CMAKE_PATH "<path>" <variable>)
file(TO_NATIVE_PATH "<path>" <variable>)
The ``TO_CMAKE_PATH`` mode converts a native ``<path>`` into a cmake-style
path with forward-slashes (``/``). The input can be a single path or a
system search path like ``$ENV{PATH}``. A search path will be converted
to a cmake-style list separated by ``;`` characters.
The ``TO_NATIVE_PATH`` mode converts a cmake-style ``<path>`` into a native
path with platform-specific slashes (``\`` on Windows and ``/`` elsewhere).
Always use double quotes around the ``<path>`` to be sure it is treated
as a single argument to this command.
Transfer
^^^^^^^^
.. _DOWNLOAD:
.. _UPLOAD:
.. code-block:: cmake
file(DOWNLOAD <url> <file> [<options>...])
file(UPLOAD <file> <url> [<options>...])
The ``DOWNLOAD`` mode downloads the given ``<url>`` to a local ``<file>``.
The ``UPLOAD`` mode uploads a local ``<file>`` to a given ``<url>``.
Options to both ``DOWNLOAD`` and ``UPLOAD`` are:
``INACTIVITY_TIMEOUT <seconds>``
Terminate the operation after a period of inactivity.
``LOG <variable>``
Store a human-readable log of the operation in a variable.
``SHOW_PROGRESS``
Print progress information as status messages until the operation is
complete.
``STATUS <variable>``
Store the resulting status of the operation in a variable.
The status is a ``;`` separated list of length 2.
The first element is the numeric return value for the operation,
and the second element is a string value for the error.
A ``0`` numeric error means no error in the operation.
``TIMEOUT <seconds>``
Terminate the operation after a given total time has elapsed.
``USERPWD <username>:<password>``
Set username and password for operation.
``HTTPHEADER <HTTP-header>``
HTTP header for operation. Suboption can be repeated several times.
``NETRC <level>``
Specify whether the .netrc file is to be used for operation. If this
option is not specified, the value of the ``CMAKE_NETRC`` variable
will be used instead.
Valid levels are:
``IGNORED``
The .netrc file is ignored.
This is the default.
``OPTIONAL``
The .netrc file is optional, and information in the URL is preferred.
The file will be scanned to find which ever information is not specified
in the URL.
``REQUIRED``
The .netrc file is required, and information in the URL is ignored.
``NETRC_FILE <file>``
Specify an alternative .netrc file to the one in your home directory,
if the ``NETRC`` level is ``OPTIONAL`` or ``REQUIRED``. If this option
is not specified, the value of the ``CMAKE_NETRC_FILE`` variable will
be used instead.
If neither ``NETRC`` option is given CMake will check variables
``CMAKE_NETRC`` and ``CMAKE_NETRC_FILE``, respectively.
``TLS_VERIFY <ON|OFF>``
Specify whether to verify the server certificate for ``https://`` URLs.
The default is to *not* verify.
``TLS_CAINFO <file>``
Specify a custom Certificate Authority file for ``https://`` URLs.
For ``https://`` URLs CMake must be built with OpenSSL support. ``TLS/SSL``
certificates are not checked by default. Set ``TLS_VERIFY`` to ``ON`` to
check certificates. If neither ``TLS`` option is given CMake will check
variables ``CMAKE_TLS_VERIFY`` and ``CMAKE_TLS_CAINFO``, respectively.
Additional options to ``DOWNLOAD`` are:
``EXPECTED_HASH ALGO=<value>``
Verify that the downloaded content hash matches the expected value, where
``ALGO`` is one of the algorithms supported by ``file(<HASH>)``.
If it does not match, the operation fails with an error.
``EXPECTED_MD5 <value>``
Historical short-hand for ``EXPECTED_HASH MD5=<value>``.
Locking
^^^^^^^
.. _LOCK:
.. code-block:: cmake
file(LOCK <path> [DIRECTORY] [RELEASE]
[GUARD <FUNCTION|FILE|PROCESS>]
[RESULT_VARIABLE <variable>]
[TIMEOUT <seconds>])
Lock a file specified by ``<path>`` if no ``DIRECTORY`` option present and file
``<path>/cmake.lock`` otherwise. File will be locked for scope defined by
``GUARD`` option (default value is ``PROCESS``). ``RELEASE`` option can be used
to unlock file explicitly. If option ``TIMEOUT`` is not specified CMake will
wait until lock succeed or until fatal error occurs. If ``TIMEOUT`` is set to
``0`` lock will be tried once and result will be reported immediately. If
``TIMEOUT`` is not ``0`` CMake will try to lock file for the period specified
by ``<seconds>`` value. Any errors will be interpreted as fatal if there is no
``RESULT_VARIABLE`` option. Otherwise result will be stored in ``<variable>``
and will be ``0`` on success or error message on failure.
Note that lock is advisory - there is no guarantee that other processes will
respect this lock, i.e. lock synchronize two or more CMake instances sharing
some modifiable resources. Similar logic applied to ``DIRECTORY`` option -
locking parent directory doesn't prevent other ``LOCK`` commands to lock any
child directory or file.
Trying to lock file twice is not allowed. Any intermediate directories and
file itself will be created if they not exist. ``GUARD`` and ``TIMEOUT``
options ignored on ``RELEASE`` operation.
Archiving
^^^^^^^^^
.. _ARCHIVE_CREATE:
.. code-block:: cmake
file(ARCHIVE_CREATE OUTPUT <archive>
PATHS <paths>...
[FORMAT <format>]
[COMPRESSION <compression>]
[MTIME <mtime>]
[VERBOSE])
Creates the specified ``<archive>`` file with the files and directories
listed in ``<paths>``. Note that ``<paths>`` must list actual files or
directories, wildcards are not supported.
Use the ``FORMAT`` option to specify the archive format. Supported values
for ``<format>`` are ``7zip``, ``gnutar``, ``pax``, ``paxr``, ``raw`` and
``zip``. If ``FORMAT`` is not given, the default format is ``paxr``.
Some archive formats allow the type of compression to be specified.
The ``7zip`` and ``zip`` archive formats already imply a specific type of
compression. The other formats use no compression by default, but can be
directed to do so with the ``COMPRESSION`` option. Valid values for
``<compression>`` are ``None``, ``BZip2``, ``GZip``, ``XZ``, and ``Zstd``.
.. note::
With ``FORMAT`` set to ``raw`` only one file will be compressed with the
compression type specified by ``COMPRESSION``.
The ``VERBOSE`` option enables verbose output for the archive operation.
To specify the modification time recorded in tarball entries, use
the ``MTIME`` option.
.. _ARCHIVE_EXTRACT:
.. code-block:: cmake
file(ARCHIVE_EXTRACT INPUT <archive>
[DESTINATION <dir>]
[PATTERNS <patterns>...]
[LIST_ONLY]
[VERBOSE])
Extracts or lists the content of the specified ``<archive>``.
The directory where the content of the archive will be extracted to can
be specified using the ``DESTINATION`` option. If the directory does not
exist, it will be created. If ``DESTINATION`` is not given, the current
binary directory will be used.
If required, you may select which files and directories to list or extract
from the archive using the specified ``<patterns>``. Wildcards are supported.
If the ``PATTERNS`` option is not given, the entire archive will be listed or
extracted.
``LIST_ONLY`` will list the files in the archive rather than extract them.
With ``VERBOSE``, the command will produce verbose output.

426
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/find_package.rst
View File

@ -1,426 +0,0 @@
find_package
------------
.. only:: html
.. contents::
Find an external project, and load its settings.
.. _`basic signature`:
Basic Signature and Module Mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
find_package(<PackageName> [version] [EXACT] [QUIET] [MODULE]
[REQUIRED] [[COMPONENTS] [components...]]
[OPTIONAL_COMPONENTS components...]
[NO_POLICY_SCOPE])
Finds and loads settings from an external project. ``<PackageName>_FOUND``
will be set to indicate whether the package was found. When the
package is found package-specific information is provided through
variables and :ref:`Imported Targets` documented by the package itself. The
``QUIET`` option disables informational messages, including those indicating
that the package cannot be found if it is not ``REQUIRED``. The ``REQUIRED``
option stops processing with an error message if the package cannot be found.
A package-specific list of required components may be listed after the
``COMPONENTS`` option (or after the ``REQUIRED`` option if present).
Additional optional components may be listed after
``OPTIONAL_COMPONENTS``. Available components and their influence on
whether a package is considered to be found are defined by the target
package.
The ``[version]`` argument requests a version with which the package found
should be compatible (format is ``major[.minor[.patch[.tweak]]]``). The
``EXACT`` option requests that the version be matched exactly. If no
``[version]`` and/or component list is given to a recursive invocation
inside a find-module, the corresponding arguments are forwarded
automatically from the outer call (including the ``EXACT`` flag for
``[version]``). Version support is currently provided only on a
package-by-package basis (see the `Version Selection`_ section below).
See the :command:`cmake_policy` command documentation for discussion
of the ``NO_POLICY_SCOPE`` option.
The command has two modes by which it searches for packages: "Module"
mode and "Config" mode. The above signature selects Module mode.
If no module is found the command falls back to Config mode, described
below. This fall back is disabled if the ``MODULE`` option is given.
In Module mode, CMake searches for a file called ``Find<PackageName>.cmake``.
The file is first searched in the :variable:`CMAKE_MODULE_PATH`,
then among the :ref:`Find Modules` provided by the CMake installation.
If the file is found, it is read and processed by CMake. It is responsible
for finding the package, checking the version, and producing any needed
messages. Some find-modules provide limited or no support for versioning;
check the module documentation.
If the ``MODULE`` option is not specified in the above signature,
CMake first searches for the package using Module mode. Then, if the
package is not found, it searches again using Config mode. A user
may set the variable :variable:`CMAKE_FIND_PACKAGE_PREFER_CONFIG` to
``TRUE`` to direct CMake first search using Config mode before falling
back to Module mode.
Full Signature and Config Mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
User code should generally look for packages using the above `basic
signature`_. The remainder of this command documentation specifies the
full command signature and details of the search process. Project
maintainers wishing to provide a package to be found by this command
are encouraged to read on.
The complete Config mode command signature is
.. code-block:: cmake
find_package(<PackageName> [version] [EXACT] [QUIET]
[REQUIRED] [[COMPONENTS] [components...]]
[OPTIONAL_COMPONENTS components...]
[CONFIG|NO_MODULE]
[NO_POLICY_SCOPE]
[NAMES name1 [name2 ...]]
[CONFIGS config1 [config2 ...]]
[HINTS path1 [path2 ... ]]
[PATHS path1 [path2 ... ]]
[PATH_SUFFIXES suffix1 [suffix2 ...]]
[NO_DEFAULT_PATH]
[NO_PACKAGE_ROOT_PATH]
[NO_CMAKE_PATH]
[NO_CMAKE_ENVIRONMENT_PATH]
[NO_SYSTEM_ENVIRONMENT_PATH]
[NO_CMAKE_PACKAGE_REGISTRY]
[NO_CMAKE_BUILDS_PATH] # Deprecated; does nothing.
[NO_CMAKE_SYSTEM_PATH]
[NO_CMAKE_SYSTEM_PACKAGE_REGISTRY]
[CMAKE_FIND_ROOT_PATH_BOTH |
ONLY_CMAKE_FIND_ROOT_PATH |
NO_CMAKE_FIND_ROOT_PATH])
The ``CONFIG`` option, the synonymous ``NO_MODULE`` option, or the use
of options not specified in the `basic signature`_ all enforce pure Config
mode. In pure Config mode, the command skips Module mode search and
proceeds at once with Config mode search.
Config mode search attempts to locate a configuration file provided by the
package to be found. A cache entry called ``<PackageName>_DIR`` is created to
hold the directory containing the file. By default the command
searches for a package with the name ``<PackageName>``. If the ``NAMES`` option
is given the names following it are used instead of ``<PackageName>``.
The command searches for a file called ``<PackageName>Config.cmake`` or
``<lower-case-package-name>-config.cmake`` for each name specified.
A replacement set of possible configuration file names may be given
using the ``CONFIGS`` option. The search procedure is specified below.
Once found, the configuration file is read and processed by CMake.
Since the file is provided by the package it already knows the
location of package contents. The full path to the configuration file
is stored in the cmake variable ``<PackageName>_CONFIG``.
All configuration files which have been considered by CMake while
searching for an installation of the package with an appropriate
version are stored in the cmake variable ``<PackageName>_CONSIDERED_CONFIGS``,
the associated versions in ``<PackageName>_CONSIDERED_VERSIONS``.
If the package configuration file cannot be found CMake will generate
an error describing the problem unless the ``QUIET`` argument is
specified. If ``REQUIRED`` is specified and the package is not found a
fatal error is generated and the configure step stops executing. If
``<PackageName>_DIR`` has been set to a directory not containing a
configuration file CMake will ignore it and search from scratch.
Package maintainers providing CMake package configuration files are
encouraged to name and install them such that the `Search Procedure`_
outlined below will find them without requiring use of additional options.
Version Selection
^^^^^^^^^^^^^^^^^
When the ``[version]`` argument is given Config mode will only find a
version of the package that claims compatibility with the requested
version (format is ``major[.minor[.patch[.tweak]]]``). If the ``EXACT``
option is given only a version of the package claiming an exact match
of the requested version may be found. CMake does not establish any
convention for the meaning of version numbers. Package version
numbers are checked by "version" files provided by the packages
themselves. For a candidate package configuration file
``<config-file>.cmake`` the corresponding version file is located next
to it and named either ``<config-file>-version.cmake`` or
``<config-file>Version.cmake``. If no such version file is available
then the configuration file is assumed to not be compatible with any
requested version. A basic version file containing generic version
matching code can be created using the
:module:`CMakePackageConfigHelpers` module. When a version file
is found it is loaded to check the requested version number. The
version file is loaded in a nested scope in which the following
variables have been defined:
``PACKAGE_FIND_NAME``
the ``<PackageName>``
``PACKAGE_FIND_VERSION``
full requested version string
``PACKAGE_FIND_VERSION_MAJOR``
major version if requested, else 0
``PACKAGE_FIND_VERSION_MINOR``
minor version if requested, else 0
``PACKAGE_FIND_VERSION_PATCH``
patch version if requested, else 0
``PACKAGE_FIND_VERSION_TWEAK``
tweak version if requested, else 0
``PACKAGE_FIND_VERSION_COUNT``
number of version components, 0 to 4
The version file checks whether it satisfies the requested version and
sets these variables:
``PACKAGE_VERSION``
full provided version string
``PACKAGE_VERSION_EXACT``
true if version is exact match
``PACKAGE_VERSION_COMPATIBLE``
true if version is compatible
``PACKAGE_VERSION_UNSUITABLE``
true if unsuitable as any version
These variables are checked by the ``find_package`` command to determine
whether the configuration file provides an acceptable version. They
are not available after the ``find_package`` call returns. If the version
is acceptable the following variables are set:
``<PackageName>_VERSION``
full provided version string
``<PackageName>_VERSION_MAJOR``
major version if provided, else 0
``<PackageName>_VERSION_MINOR``
minor version if provided, else 0
``<PackageName>_VERSION_PATCH``
patch version if provided, else 0
``<PackageName>_VERSION_TWEAK``
tweak version if provided, else 0
``<PackageName>_VERSION_COUNT``
number of version components, 0 to 4
and the corresponding package configuration file is loaded.
When multiple package configuration files are available whose version files
claim compatibility with the version requested it is unspecified which
one is chosen: unless the variable :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER`
is set no attempt is made to choose a highest or closest version number.
To control the order in which ``find_package`` checks for compatibility use
the two variables :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` and
:variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION`.
For instance in order to select the highest version one can set
.. code-block:: cmake
SET(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
SET(CMAKE_FIND_PACKAGE_SORT_DIRECTION DEC)
before calling ``find_package``.
Search Procedure
^^^^^^^^^^^^^^^^
CMake constructs a set of possible installation prefixes for the
package. Under each prefix several directories are searched for a
configuration file. The tables below show the directories searched.
Each entry is meant for installation trees following Windows (``W``), UNIX
(``U``), or Apple (``A``) conventions::
<prefix>/ (W)
<prefix>/(cmake|CMake)/ (W)
<prefix>/<name>*/ (W)
<prefix>/<name>*/(cmake|CMake)/ (W)
<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/ (U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/ (W/U)
On systems supporting macOS :prop_tgt:`FRAMEWORK` and :prop_tgt:`BUNDLE`, the
following directories are searched for Frameworks or Application Bundles
containing a configuration file::
<prefix>/<name>.framework/Resources/ (A)
<prefix>/<name>.framework/Resources/CMake/ (A)
<prefix>/<name>.framework/Versions/*/Resources/ (A)
<prefix>/<name>.framework/Versions/*/Resources/CMake/ (A)
<prefix>/<name>.app/Contents/Resources/ (A)
<prefix>/<name>.app/Contents/Resources/CMake/ (A)
In all cases the ``<name>`` is treated as case-insensitive and corresponds
to any of the names specified (``<PackageName>`` or names given by ``NAMES``).
Paths with ``lib/<arch>`` are enabled if the
:variable:`CMAKE_LIBRARY_ARCHITECTURE` variable is set. ``lib*`` includes one
or more of the values ``lib64``, ``lib32``, ``libx32`` or ``lib`` (searched in
that order).
* Paths with ``lib64`` are searched on 64 bit platforms if the
:prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` property is set to ``TRUE``.
* Paths with ``lib32`` are searched on 32 bit platforms if the
:prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` property is set to ``TRUE``.
* Paths with ``libx32`` are searched on platforms using the x32 ABI
if the :prop_gbl:`FIND_LIBRARY_USE_LIBX32_PATHS` property is set to ``TRUE``.
* The ``lib`` path is always searched.
If ``PATH_SUFFIXES`` is specified, the suffixes are appended to each
(``W``) or (``U``) directory entry one-by-one.
This set of directories is intended to work in cooperation with
projects that provide configuration files in their installation trees.
Directories above marked with (``W``) are intended for installations on
Windows where the prefix may point at the top of an application's
installation directory. Those marked with (``U``) are intended for
installations on UNIX platforms where the prefix is shared by multiple
packages. This is merely a convention, so all (``W``) and (``U``) directories
are still searched on all platforms. Directories marked with (``A``) are
intended for installations on Apple platforms. The
:variable:`CMAKE_FIND_FRAMEWORK` and :variable:`CMAKE_FIND_APPBUNDLE`
variables determine the order of preference.
The set of installation prefixes is constructed using the following
steps. If ``NO_DEFAULT_PATH`` is specified all ``NO_*`` options are
enabled.
1. Search paths specified in the :variable:`<PackageName>_ROOT` CMake
variable and the :envvar:`<PackageName>_ROOT` environment variable,
where ``<PackageName>`` is the package to be found.
The package root variables are maintained as a stack so if
called from within a find module, root paths from the parent's find
module will also be searched after paths for the current package.
This can be skipped if ``NO_PACKAGE_ROOT_PATH`` is passed or by setting
the :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` to ``FALSE``.
See policy :policy:`CMP0074`.
2. Search paths specified in cmake-specific cache variables. These
are intended to be used on the command line with a ``-DVAR=value``.
The values are interpreted as :ref:`semicolon-separated lists <CMake Language Lists>`.
This can be skipped if ``NO_CMAKE_PATH`` is passed or by setting the
:variable:`CMAKE_FIND_USE_CMAKE_PATH` to ``FALSE``:
* :variable:`CMAKE_PREFIX_PATH`
* :variable:`CMAKE_FRAMEWORK_PATH`
* :variable:`CMAKE_APPBUNDLE_PATH`
3. Search paths specified in cmake-specific environment variables.
These are intended to be set in the user's shell configuration,
and therefore use the host's native path separator
(``;`` on Windows and ``:`` on UNIX).
This can be skipped if ``NO_CMAKE_ENVIRONMENT_PATH`` is passed or by setting
the :variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH` to ``FALSE``:
* ``<PackageName>_DIR``
* :envvar:`CMAKE_PREFIX_PATH`
* ``CMAKE_FRAMEWORK_PATH``
* ``CMAKE_APPBUNDLE_PATH``
4. Search paths specified by the ``HINTS`` option. These should be paths
computed by system introspection, such as a hint provided by the
location of another item already found. Hard-coded guesses should
be specified with the ``PATHS`` option.
5. Search the standard system environment variables. This can be
skipped if ``NO_SYSTEM_ENVIRONMENT_PATH`` is passed or by setting the
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH` to ``FALSE``. Path entries
ending in ``/bin`` or ``/sbin`` are automatically converted to their
parent directories:
* ``PATH``
6. Search paths stored in the CMake :ref:`User Package Registry`.
This can be skipped if ``NO_CMAKE_PACKAGE_REGISTRY`` is passed or by
setting the variable :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`
to ``FALSE`` or the deprecated variable
:variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` to ``TRUE``.
See the :manual:`cmake-packages(7)` manual for details on the user
package registry.
7. Search cmake variables defined in the Platform files for the
current system. This can be skipped if ``NO_CMAKE_SYSTEM_PATH`` is
passed or by setting the :variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`
to ``FALSE``:
* :variable:`CMAKE_SYSTEM_PREFIX_PATH`
* :variable:`CMAKE_SYSTEM_FRAMEWORK_PATH`
* :variable:`CMAKE_SYSTEM_APPBUNDLE_PATH`
The platform paths that these variables contain are locations that
typically include installed software. An example being ``/usr/local`` for
UNIX based platforms.
8. Search paths stored in the CMake :ref:`System Package Registry`.
This can be skipped if ``NO_CMAKE_SYSTEM_PACKAGE_REGISTRY`` is passed
or by setting the :variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`
variable to ``FALSE`` or the deprecated variable
:variable:`CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY` to ``TRUE``.
See the :manual:`cmake-packages(7)` manual for details on the system
package registry.
9. Search paths specified by the ``PATHS`` option. These are typically
hard-coded guesses.
.. |FIND_XXX| replace:: find_package
.. |FIND_ARGS_XXX| replace:: <PackageName>
.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
:variable:`CMAKE_FIND_ROOT_PATH_MODE_PACKAGE`
.. include:: FIND_XXX_ROOT.txt
.. include:: FIND_XXX_ORDER.txt
By default the value stored in the result variable will be the path at
which the file is found. The :variable:`CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS`
variable may be set to ``TRUE`` before calling ``find_package`` in order
to resolve symbolic links and store the real path to the file.
Every non-REQUIRED ``find_package`` call can be disabled by setting the
:variable:`CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` variable to ``TRUE``.
Package File Interface Variables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When loading a find module or package configuration file ``find_package``
defines variables to provide information about the call arguments (and
restores their original state before returning):
``CMAKE_FIND_PACKAGE_NAME``
the ``<PackageName>`` which is searched for
``<PackageName>_FIND_REQUIRED``
true if ``REQUIRED`` option was given
``<PackageName>_FIND_QUIETLY``
true if ``QUIET`` option was given
``<PackageName>_FIND_VERSION``
full requested version string
``<PackageName>_FIND_VERSION_MAJOR``
major version if requested, else 0
``<PackageName>_FIND_VERSION_MINOR``
minor version if requested, else 0
``<PackageName>_FIND_VERSION_PATCH``
patch version if requested, else 0
``<PackageName>_FIND_VERSION_TWEAK``
tweak version if requested, else 0
``<PackageName>_FIND_VERSION_COUNT``
number of version components, 0 to 4
``<PackageName>_FIND_VERSION_EXACT``
true if ``EXACT`` option was given
``<PackageName>_FIND_COMPONENTS``
list of requested components
``<PackageName>_FIND_REQUIRED_<c>``
true if component ``<c>`` is required,
false if component ``<c>`` is optional
In Module mode the loaded find module is responsible to honor the
request detailed by these variables; see the find module for details.
In Config mode ``find_package`` handles ``REQUIRED``, ``QUIET``, and
``[version]`` options automatically but leaves it to the package
configuration file to handle components in a way that makes sense
for the package. The package configuration file may set
``<PackageName>_FOUND`` to false to tell ``find_package`` that component
requirements are not satisfied.

280
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/if.rst
View File

@ -1,280 +0,0 @@
if
--
Conditionally execute a group of commands.
Synopsis
^^^^^^^^
.. code-block:: cmake
if(<condition>)
<commands>
elseif(<condition>) # optional block, can be repeated
<commands>
else() # optional block
<commands>
endif()
Evaluates the ``condition`` argument of the ``if`` clause according to the
`Condition syntax`_ described below. If the result is true, then the
``commands`` in the ``if`` block are executed.
Otherwise, optional ``elseif`` blocks are processed in the same way.
Finally, if no ``condition`` is true, ``commands`` in the optional ``else``
block are executed.
Per legacy, the :command:`else` and :command:`endif` commands admit
an optional ``<condition>`` argument.
If used, it must be a verbatim
repeat of the argument of the opening
``if`` command.
.. _`Condition Syntax`:
Condition Syntax
^^^^^^^^^^^^^^^^
The following syntax applies to the ``condition`` argument of
the ``if``, ``elseif`` and :command:`while` clauses.
Compound conditions are evaluated in the following order of precedence:
Innermost parentheses are evaluated first. Next come unary tests such
as ``EXISTS``, ``COMMAND``, and ``DEFINED``. Then binary tests such as
``EQUAL``, ``LESS``, ``LESS_EQUAL``, ``GREATER``, ``GREATER_EQUAL``,
``STREQUAL``, ``STRLESS``, ``STRLESS_EQUAL``, ``STRGREATER``,
``STRGREATER_EQUAL``, ``VERSION_EQUAL``, ``VERSION_LESS``,
``VERSION_LESS_EQUAL``, ``VERSION_GREATER``, ``VERSION_GREATER_EQUAL``,
and ``MATCHES``. Then the boolean operators in the order ``NOT``, ``AND``,
and finally ``OR``.
Possible conditions are:
``if(<constant>)``
True if the constant is ``1``, ``ON``, ``YES``, ``TRUE``, ``Y``,
or a non-zero number. False if the constant is ``0``, ``OFF``,
``NO``, ``FALSE``, ``N``, ``IGNORE``, ``NOTFOUND``, the empty string,
or ends in the suffix ``-NOTFOUND``. Named boolean constants are
case-insensitive. If the argument is not one of these specific
constants, it is treated as a variable or string and the following
signature is used.
``if(<variable|string>)``
True if given a variable that is defined to a value that is not a false
constant. False otherwise. (Note macro arguments are not variables.)
``if(NOT <condition>)``
True if the condition is not true.
``if(<cond1> AND <cond2>)``
True if both conditions would be considered true individually.
``if(<cond1> OR <cond2>)``
True if either condition would be considered true individually.
``if(COMMAND command-name)``
True if the given name is a command, macro or function that can be
invoked.
``if(POLICY policy-id)``
True if the given name is an existing policy (of the form ``CMP<NNNN>``).
``if(TARGET target-name)``
True if the given name is an existing logical target name created
by a call to the :command:`add_executable`, :command:`add_library`,
or :command:`add_custom_target` command that has already been invoked
(in any directory).
``if(TEST test-name)``
True if the given name is an existing test name created by the
:command:`add_test` command.
``if(EXISTS path-to-file-or-directory)``
True if the named file or directory exists. Behavior is well-defined
only for full paths. Resolves symbolic links, i.e. if the named file or
directory is a symbolic link, returns true if the target of the
symbolic link exists.
``if(file1 IS_NEWER_THAN file2)``
True if ``file1`` is newer than ``file2`` or if one of the two files doesn't
exist. Behavior is well-defined only for full paths. If the file
time stamps are exactly the same, an ``IS_NEWER_THAN`` comparison returns
true, so that any dependent build operations will occur in the event
of a tie. This includes the case of passing the same file name for
both file1 and file2.
``if(IS_DIRECTORY path-to-directory)``
True if the given name is a directory. Behavior is well-defined only
for full paths.
``if(IS_SYMLINK file-name)``
True if the given name is a symbolic link. Behavior is well-defined
only for full paths.
``if(IS_ABSOLUTE path)``
True if the given path is an absolute path.
``if(<variable|string> MATCHES regex)``
True if the given string or variable's value matches the given regular
condition. See :ref:`Regex Specification` for regex format.
``()`` groups are captured in :variable:`CMAKE_MATCH_<n>` variables.
``if(<variable|string> LESS <variable|string>)``
True if the given string or variable's value is a valid number and less
than that on the right.
``if(<variable|string> GREATER <variable|string>)``
True if the given string or variable's value is a valid number and greater
than that on the right.
``if(<variable|string> EQUAL <variable|string>)``
True if the given string or variable's value is a valid number and equal
to that on the right.
``if(<variable|string> LESS_EQUAL <variable|string>)``
True if the given string or variable's value is a valid number and less
than or equal to that on the right.
``if(<variable|string> GREATER_EQUAL <variable|string>)``
True if the given string or variable's value is a valid number and greater
than or equal to that on the right.
``if(<variable|string> STRLESS <variable|string>)``
True if the given string or variable's value is lexicographically less
than the string or variable on the right.
``if(<variable|string> STRGREATER <variable|string>)``
True if the given string or variable's value is lexicographically greater
than the string or variable on the right.
``if(<variable|string> STREQUAL <variable|string>)``
True if the given string or variable's value is lexicographically equal
to the string or variable on the right.
``if(<variable|string> STRLESS_EQUAL <variable|string>)``
True if the given string or variable's value is lexicographically less
than or equal to the string or variable on the right.
``if(<variable|string> STRGREATER_EQUAL <variable|string>)``
True if the given string or variable's value is lexicographically greater
than or equal to the string or variable on the right.
``if(<variable|string> VERSION_LESS <variable|string>)``
Component-wise integer version number comparison (version format is
``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
Any non-integer version component or non-integer trailing part of a version
component effectively truncates the string at that point.
``if(<variable|string> VERSION_GREATER <variable|string>)``
Component-wise integer version number comparison (version format is
``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
Any non-integer version component or non-integer trailing part of a version
component effectively truncates the string at that point.
``if(<variable|string> VERSION_EQUAL <variable|string>)``
Component-wise integer version number comparison (version format is
``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
Any non-integer version component or non-integer trailing part of a version
component effectively truncates the string at that point.
``if(<variable|string> VERSION_LESS_EQUAL <variable|string>)``
Component-wise integer version number comparison (version format is
``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
Any non-integer version component or non-integer trailing part of a version
component effectively truncates the string at that point.
``if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)``
Component-wise integer version number comparison (version format is
``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
Any non-integer version component or non-integer trailing part of a version
component effectively truncates the string at that point.
``if(<variable|string> IN_LIST <variable>)``
True if the given element is contained in the named list variable.
``if(DEFINED <name>|CACHE{<name>}|ENV{<name>})``
True if a variable, cache variable or environment variable
with given ``<name>`` is defined. The value of the variable
does not matter. Note that macro arguments are not variables.
``if((condition) AND (condition OR (condition)))``
The conditions inside the parenthesis are evaluated first and then
the remaining condition is evaluated as in the previous examples.
Where there are nested parenthesis the innermost are evaluated as part
of evaluating the condition that contains them.
Variable Expansion
^^^^^^^^^^^^^^^^^^
The if command was written very early in CMake's history, predating
the ``${}`` variable evaluation syntax, and for convenience evaluates
variables named by its arguments as shown in the above signatures.
Note that normal variable evaluation with ``${}`` applies before the if
command even receives the arguments. Therefore code like
.. code-block:: cmake
set(var1 OFF)
set(var2 "var1")
if(${var2})
appears to the if command as
.. code-block:: cmake
if(var1)
and is evaluated according to the ``if(<variable>)`` case documented
above. The result is ``OFF`` which is false. However, if we remove the
``${}`` from the example then the command sees
.. code-block:: cmake
if(var2)
which is true because ``var2`` is defined to ``var1`` which is not a false
constant.
Automatic evaluation applies in the other cases whenever the
above-documented condition syntax accepts ``<variable|string>``:
* The left hand argument to ``MATCHES`` is first checked to see if it is
a defined variable, if so the variable's value is used, otherwise the
original value is used.
* If the left hand argument to ``MATCHES`` is missing it returns false
without error
* Both left and right hand arguments to ``LESS``, ``GREATER``, ``EQUAL``,
``LESS_EQUAL``, and ``GREATER_EQUAL``, are independently tested to see if
they are defined variables, if so their defined values are used otherwise
the original value is used.
* Both left and right hand arguments to ``STRLESS``, ``STRGREATER``,
``STREQUAL``, ``STRLESS_EQUAL``, and ``STRGREATER_EQUAL`` are independently
tested to see if they are defined variables, if so their defined values are
used otherwise the original value is used.
* Both left and right hand arguments to ``VERSION_LESS``,
``VERSION_GREATER``, ``VERSION_EQUAL``, ``VERSION_LESS_EQUAL``, and
``VERSION_GREATER_EQUAL`` are independently tested to see if they are defined
variables, if so their defined values are used otherwise the original value
is used.
* The right hand argument to ``NOT`` is tested to see if it is a boolean
constant, if so the value is used, otherwise it is assumed to be a
variable and it is dereferenced.
* The left and right hand arguments to ``AND`` and ``OR`` are independently
tested to see if they are boolean constants, if so they are used as
such, otherwise they are assumed to be variables and are dereferenced.
To prevent ambiguity, potential variable or keyword names can be
specified in a :ref:`Quoted Argument` or a :ref:`Bracket Argument`.
A quoted or bracketed variable or keyword will be interpreted as a
string and not dereferenced or interpreted.
See policy :policy:`CMP0054`.
There is no automatic evaluation for environment or cache
:ref:`Variable References`. Their values must be referenced as
``$ENV{<name>}`` or ``$CACHE{<name>}`` wherever the above-documented
condition syntax accepts ``<variable|string>``.

332
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/list.rst
View File

@ -1,332 +0,0 @@
list
----
List operations.
Synopsis
^^^^^^^^
.. parsed-literal::
`Reading`_
list(`LENGTH`_ <list> <out-var>)
list(`GET`_ <list> <element index> [<index> ...] <out-var>)
list(`JOIN`_ <list> <glue> <out-var>)
list(`SUBLIST`_ <list> <begin> <length> <out-var>)
`Search`_
list(`FIND`_ <list> <value> <out-var>)
`Modification`_
list(`APPEND`_ <list> [<element>...])
list(`FILTER`_ <list> {INCLUDE | EXCLUDE} REGEX <regex>)
list(`INSERT`_ <list> <index> [<element>...])
list(`POP_BACK`_ <list> [<out-var>...])
list(`POP_FRONT`_ <list> [<out-var>...])
list(`PREPEND`_ <list> [<element>...])
list(`REMOVE_ITEM`_ <list> <value>...)
list(`REMOVE_AT`_ <list> <index>...)
list(`REMOVE_DUPLICATES`_ <list>)
list(`TRANSFORM`_ <list> <ACTION> [...])
`Ordering`_
list(`REVERSE`_ <list>)
list(`SORT`_ <list> [...])
Introduction
^^^^^^^^^^^^
The list subcommands ``APPEND``, ``INSERT``, ``FILTER``, ``PREPEND``,
``POP_BACK``, ``POP_FRONT``, ``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.
.. note::
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.)
.. note::
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
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.
Reading
^^^^^^^
.. _LENGTH:
.. code-block:: cmake
list(LENGTH <list> <output variable>)
Returns the list's length.
.. _GET:
.. code-block:: cmake
list(GET <list> <element index> [<element index> ...] <output variable>)
Returns the list of elements specified by indices from the list.
.. _JOIN:
.. code-block:: cmake
list(JOIN <list> <glue> <output variable>)
Returns a string joining all list's elements using the glue string.
To join multiple strings, which are not part of a list, use ``JOIN`` operator
from :command:`string` command.
.. _SUBLIST:
.. code-block:: cmake
list(SUBLIST <list> <begin> <length> <output variable>)
Returns a sublist of the given list.
If ``<length>`` is 0, an empty list will be returned.
If ``<length>`` is -1 or the list is smaller than ``<begin>+<length>`` then
the remaining elements of the list starting at ``<begin>`` will be returned.
Search
^^^^^^
.. _FIND:
.. code-block:: cmake
list(FIND <list> <value> <output variable>)
Returns the index of the element specified in the list or -1
if it wasn't found.
Modification
^^^^^^^^^^^^
.. _APPEND:
.. code-block:: cmake
list(APPEND <list> [<element> ...])
Appends elements to the list.
.. _FILTER:
.. code-block:: cmake
list(FILTER <list> <INCLUDE|EXCLUDE> REGEX <regular_expression>)
Includes or removes items from the list that match the mode's pattern.
In ``REGEX`` mode, items will be matched against the given regular expression.
For more information on regular expressions see also the
:command:`string` command.
.. _INSERT:
.. code-block:: cmake
list(INSERT <list> <element_index> <element> [<element> ...])
Inserts elements to the list to the specified location.
.. _POP_BACK:
.. code-block:: cmake
list(POP_BACK <list> [<out-var>...])
If no variable name is given, removes exactly one element. Otherwise,
assign the last element's value to the given variable and removes it,
up to the last variable name given.
.. _POP_FRONT:
.. code-block:: cmake
list(POP_FRONT <list> [<out-var>...])
If no variable name is given, removes exactly one element. Otherwise,
assign the first element's value to the given variable and removes it,
up to the last variable name given.
.. _PREPEND:
.. code-block:: cmake
list(PREPEND <list> [<element> ...])
Insert elements to the 0th position in the list.
.. _REMOVE_ITEM:
.. code-block:: cmake
list(REMOVE_ITEM <list> <value> [<value> ...])
Removes all instances of the given items from the list.
.. _REMOVE_AT:
.. code-block:: cmake
list(REMOVE_AT <list> <index> [<index> ...])
Removes items at given indices from the list.
.. _REMOVE_DUPLICATES:
.. code-block:: cmake
list(REMOVE_DUPLICATES <list>)
Removes duplicated items in the list. The relative order of items is preserved,
but if duplicates are encountered, only the first instance is preserved.
.. _TRANSFORM:
.. code-block:: cmake
list(TRANSFORM <list> <ACTION> [<SELECTOR>]
[OUTPUT_VARIABLE <output variable>])
Transforms the list by applying an action to all or, by specifying a
``<SELECTOR>``, to the selected elements of the list, storing the result
in-place or in the specified output variable.
.. note::
The ``TRANSFORM`` sub-command does not change the number of elements in the
list. If a ``<SELECTOR>`` is specified, only some elements will be changed,
the other ones will remain the same as before the transformation.
``<ACTION>`` specifies the action to apply to the elements of the list.
The actions have exactly the same semantics as sub-commands of the
:command:`string` command. ``<ACTION>`` must be one of the following:
``APPEND``, ``PREPEND``: Append, prepend specified value to each element of
the list.
.. code-block:: cmake
list(TRANSFORM <list> <APPEND|PREPEND> <value> ...)
``TOUPPER``, ``TOLOWER``: Convert each element of the list to upper, lower
characters.
.. code-block:: cmake
list(TRANSFORM <list> <TOLOWER|TOUPPER> ...)
``STRIP``: Remove leading and trailing spaces from each element of the
list.
.. code-block:: cmake
list(TRANSFORM <list> STRIP ...)
``GENEX_STRIP``: Strip any
:manual:`generator expressions <cmake-generator-expressions(7)>` from each
element of the list.
.. code-block:: cmake
list(TRANSFORM <list> GENEX_STRIP ...)
``REPLACE``: Match the regular expression as many times as possible and
substitute the replacement expression for the match for each element
of the list
(Same semantic as ``REGEX REPLACE`` from :command:`string` command).
.. code-block:: cmake
list(TRANSFORM <list> REPLACE <regular_expression>
<replace_expression> ...)
``<SELECTOR>`` determines which elements of the list will be transformed.
Only one type of selector can be specified at a time. When given,
``<SELECTOR>`` must be one of the following:
``AT``: Specify a list of indexes.
.. code-block:: cmake
list(TRANSFORM <list> <ACTION> AT <index> [<index> ...] ...)
``FOR``: Specify a range with, optionally, an increment used to iterate over
the range.
.. code-block:: cmake
list(TRANSFORM <list> <ACTION> FOR <start> <stop> [<step>] ...)
``REGEX``: Specify a regular expression. Only elements matching the regular
expression will be transformed.
.. code-block:: cmake
list(TRANSFORM <list> <ACTION> REGEX <regular_expression> ...)
Ordering
^^^^^^^^
.. _REVERSE:
.. code-block:: cmake
list(REVERSE <list>)
Reverses the contents of the list in-place.
.. _SORT:
.. code-block:: cmake
list(SORT <list> [COMPARE <compare>] [CASE <case>] [ORDER <order>])
Sorts the list in-place alphabetically.
Use the ``COMPARE`` keyword to select the comparison method for sorting.
The ``<compare>`` option should be one of:
* ``STRING``: Sorts a list of strings alphabetically. This is the
default behavior if the ``COMPARE`` option is not given.
* ``FILE_BASENAME``: Sorts a list of pathnames of files by their basenames.
* ``NATURAL``: Sorts a list of strings using natural order
(see ``strverscmp(3)`` manual), i.e. such that contiguous digits
are compared as whole numbers.
For example: the following list `10.0 1.1 2.1 8.0 2.0 3.1`
will be sorted as `1.1 2.0 2.1 3.1 8.0 10.0` if the ``NATURAL``
comparison is selected where it will be sorted as
`1.1 10.0 2.0 2.1 3.1 8.0` with the ``STRING`` comparison.
Use the ``CASE`` keyword to select a case sensitive or case insensitive
sort mode. The ``<case>`` option should be one of:
* ``SENSITIVE``: List items are sorted in a case-sensitive manner. This is
the default behavior if the ``CASE`` option is not given.
* ``INSENSITIVE``: List items are sorted case insensitively. The order of
items which differ only by upper/lowercase is not specified.
To control the sort order, the ``ORDER`` keyword can be given.
The ``<order>`` option should be one of:
* ``ASCENDING``: Sorts the list in ascending order. This is the default
behavior when the ``ORDER`` option is not given.
* ``DESCENDING``: Sorts the list in descending order.

16
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/option.rst
View File

@ -1,16 +0,0 @@
option
------
Provide an option that the user can optionally select.
.. code-block:: cmake
option(<variable> "<help_text>" [value])
Provides an option for the user to select as ``ON`` or ``OFF``.
If no initial ``<value>`` is provided, ``OFF`` is used.
If ``<variable>`` is already set as a normal or cache variable,
then the command does nothing (see policy :policy:`CMP0077`).
If you have options that depend on the values of other options, see
the module help for :module:`CMakeDependentOption`.

19
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/return.rst
View File

@ -1,19 +0,0 @@
return
------
Return from a file, directory or function.
.. code-block:: cmake
return()
Returns from a file, directory or function. When this command is
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 :command:`macro <macro>`, unlike a :command:`function <function>`,
is expanded in place and therefore cannot handle ``return()``.

104
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/set.rst
View File

@ -1,104 +0,0 @@
set
---
Set a normal, cache, or environment variable to a given value.
See the :ref:`cmake-language(7) variables <CMake Language Variables>`
documentation for the scopes and interaction of normal variables
and cache entries.
Signatures of this command that specify a ``<value>...`` placeholder
expect zero or more arguments. Multiple arguments will be joined as
a :ref:`semicolon-separated list <CMake Language Lists>` to form the actual variable
value to be set. Zero arguments will cause normal variables to be
unset. See the :command:`unset` command to unset variables explicitly.
Set Normal Variable
^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
set(<variable> <value>... [PARENT_SCOPE])
Sets the given ``<variable>`` in the current function or directory scope.
If the ``PARENT_SCOPE`` option is given the variable will be set in
the scope above the current scope. Each new directory or function
creates a new scope. This command will set the value of a variable
into the parent directory or calling function (whichever is applicable
to the case at hand). The previous state of the variable's value stays the
same in the current scope (e.g., if it was undefined before, it is still
undefined and if it had a value, it is still that value).
Set Cache Entry
^^^^^^^^^^^^^^^
.. code-block:: cmake
set(<variable> <value>... CACHE <type> <docstring> [FORCE])
Sets the given cache ``<variable>`` (cache entry). Since cache entries
are meant to provide user-settable values this does not overwrite
existing cache entries by default. Use the ``FORCE`` option to
overwrite existing entries.
The ``<type>`` must be specified as one of:
``BOOL``
Boolean ``ON/OFF`` value. :manual:`cmake-gui(1)` offers a checkbox.
``FILEPATH``
Path to a file on disk. :manual:`cmake-gui(1)` offers a file dialog.
``PATH``
Path to a directory on disk. :manual:`cmake-gui(1)` offers a file dialog.
``STRING``
A line of text. :manual:`cmake-gui(1)` offers a text field or a
drop-down selection if the :prop_cache:`STRINGS` cache entry
property is set.
``INTERNAL``
A line of text. :manual:`cmake-gui(1)` does not show internal entries.
They may be used to store variables persistently across runs.
Use of this type implies ``FORCE``.
The ``<docstring>`` must be specified as a line of text providing
a quick summary of the option for presentation to :manual:`cmake-gui(1)`
users.
If the cache entry does not exist prior to the call or the ``FORCE``
option is given then the cache entry will be set to the given value.
Furthermore, any normal variable binding in the current scope will
be removed to expose the newly cached value to any immediately
following evaluation.
It is possible for the cache entry to exist prior to the call but
have no type set if it was created on the :manual:`cmake(1)` command
line by a user through the ``-D<var>=<value>`` option without
specifying a type. In this case the ``set`` command will add the
type. Furthermore, if the ``<type>`` is ``PATH`` or ``FILEPATH``
and the ``<value>`` provided on the command line is a relative path,
then the ``set`` command will treat the path as relative to the
current working directory and convert it to an absolute path.
Set Environment Variable
^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
set(ENV{<variable>} [<value>])
Sets an :manual:`Environment Variable <cmake-env-variables(7)>`
to the given value.
Subsequent calls of ``$ENV{<variable>}`` will return this new value.
This command affects only the current CMake process, not the process
from which CMake was called, nor the system environment at large,
nor the environment of subsequent build or test processes.
If no argument is given after ``ENV{<variable>}`` or if ``<value>`` is
an empty string, then this command will clear any existing value of the
environment variable.
Arguments after ``<value>`` are ignored. If extra arguments are found,
then an author warning is issued.

17
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/set_tests_properties.rst
View File

@ -1,17 +0,0 @@
set_tests_properties
--------------------
Set a property of the tests.
.. code-block:: cmake
set_tests_properties(test1 [test2...] PROPERTIES prop1 value1 prop2 value2)
Sets a property for the tests. If the test is not found, CMake
will report an error.
:manual:`Generator expressions <cmake-generator-expressions(7)>` will be
expanded the same as supported by the test's :command:`add_test` call.
See also the :command:`set_property(TEST)` command.
See :ref:`Test Properties` for the list of properties known to CMake.

8
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/site_name.rst
View File

@ -1,8 +0,0 @@
site_name
---------
Set the given variable to the name of the computer.
.. code-block:: cmake
site_name(variable)

472
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/string.rst
View File

@ -1,472 +0,0 @@
string
------
String operations.
Synopsis
^^^^^^^^
.. parsed-literal::
`Search and Replace`_
string(`FIND`_ <string> <substring> <out-var> [...])
string(`REPLACE`_ <match-string> <replace-string> <out-var> <input>...)
string(`REGEX MATCH`_ <match-regex> <out-var> <input>...)
string(`REGEX MATCHALL`_ <match-regex> <out-var> <input>...)
string(`REGEX REPLACE`_ <match-regex> <replace-expr> <out-var> <input>...)
`Manipulation`_
string(`APPEND`_ <string-var> [<input>...])
string(`PREPEND`_ <string-var> [<input>...])
string(`CONCAT`_ <out-var> [<input>...])
string(`JOIN`_ <glue> <out-var> [<input>...])
string(`TOLOWER`_ <string> <out-var>)
string(`TOUPPER`_ <string> <out-var>)
string(`LENGTH`_ <string> <out-var>)
string(`SUBSTRING`_ <string> <begin> <length> <out-var>)
string(`STRIP`_ <string> <out-var>)
string(`GENEX_STRIP`_ <string> <out-var>)
string(`REPEAT`_ <string> <count> <out-var>)
`Comparison`_
string(`COMPARE`_ <op> <string1> <string2> <out-var>)
`Hashing`_
string(`\<HASH\> <HASH_>`_ <out-var> <input>)
`Generation`_
string(`ASCII`_ <number>... <out-var>)
string(`HEX`_ <string> <out-var>)
string(`CONFIGURE`_ <string> <out-var> [...])
string(`MAKE_C_IDENTIFIER`_ <string> <out-var>)
string(`RANDOM`_ [<option>...] <out-var>)
string(`TIMESTAMP`_ <out-var> [<format string>] [UTC])
string(`UUID`_ <out-var> ...)
Search and Replace
^^^^^^^^^^^^^^^^^^
Search and Replace With Plain Strings
"""""""""""""""""""""""""""""""""""""
.. _FIND:
.. code-block:: cmake
string(FIND <string> <substring> <output_variable> [REVERSE])
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>``. If the ``<substring>`` is not found, a position of -1 is
returned.
The ``string(FIND)`` subcommand treats all strings as ASCII-only characters.
The index stored in ``<output_variable>`` will also be counted in bytes,
so strings containing multi-byte characters may lead to unexpected results.
.. _REPLACE:
.. code-block:: cmake
string(REPLACE <match_string>
<replace_string> <output_variable>
<input> [<input>...])
Replace all occurrences of ``<match_string>`` in the ``<input>``
with ``<replace_string>`` and store the result in the ``<output_variable>``.
Search and Replace With Regular Expressions
"""""""""""""""""""""""""""""""""""""""""""
.. _`REGEX MATCH`:
.. code-block:: cmake
string(REGEX MATCH <regular_expression>
<output_variable> <input> [<input>...])
Match the ``<regular_expression>`` once and store the match in the
``<output_variable>``.
All ``<input>`` arguments are concatenated before matching.
Regular expressions are specified in the subsection just below.
.. _`REGEX MATCHALL`:
.. code-block:: cmake
string(REGEX MATCHALL <regular_expression>
<output_variable> <input> [<input>...])
Match the ``<regular_expression>`` as many times as possible and store the
matches in the ``<output_variable>`` as a list.
All ``<input>`` arguments are concatenated before matching.
.. _`REGEX REPLACE`:
.. code-block:: cmake
string(REGEX REPLACE <regular_expression>
<replacement_expression> <output_variable>
<input> [<input>...])
Match the ``<regular_expression>`` as many times as possible and substitute
the ``<replacement_expression>`` for the match in the output.
All ``<input>`` arguments are concatenated before matching.
The ``<replacement_expression>`` may refer to parenthesis-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.
.. _`Regex Specification`:
Regex Specification
"""""""""""""""""""
The following characters have special meaning in regular expressions:
``^``
Matches at beginning of input
``$``
Matches at end of input
``.``
Matches any single character
``\<char>``
Matches the single character specified by ``<char>``. Use this to
match special regex characters, e.g. ``\.`` for a literal ``.``
or ``\\`` for a literal backslash ``\``. Escaping a non-special
character is unnecessary but allowed, e.g. ``\a`` matches ``a``.
``[ ]``
Matches any character(s) inside the brackets
``[^ ]``
Matches any character(s) not inside the brackets
``-``
Inside brackets, specifies an inclusive range between
characters on either side e.g. ``[a-f]`` is ``[abcdef]``
To match a literal ``-`` using brackets, make it the first
or the last character e.g. ``[+*/-]`` matches basic
mathematical operators.
``*``
Matches preceding pattern zero or more times
``+``
Matches preceding pattern one or more times
``?``
Matches preceding pattern zero or once only
``|``
Matches a pattern on either side of the ``|``
``()``
Saves a matched subexpression, which can be referenced
in the ``REGEX REPLACE`` operation. Additionally it is saved
by all regular expression-related commands, including
e.g. :command:`if(MATCHES)`, in the variables
:variable:`CMAKE_MATCH_<n>` for ``<n>`` 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``.
CMake language :ref:`Escape Sequences` such as ``\t``, ``\r``, ``\n``,
and ``\\`` may be used to construct literal tabs, carriage returns,
newlines, and backslashes (respectively) to pass in a regex. For example:
* The quoted argument ``"[ \t\r\n]"`` specifies a regex that matches
any single whitespace character.
* The quoted argument ``"[/\\]"`` specifies a regex that matches
a single forward slash ``/`` or backslash ``\``.
* The quoted argument ``"[A-Za-z0-9_]"`` specifies a regex that matches
any single "word" character in the C locale.
* The quoted argument ``"\\(\\a\\+b\\)"`` specifies a regex that matches
the exact string ``(a+b)``. Each ``\\`` is parsed in a quoted argument
as just ``\``, so the regex itself is actually ``\(\a\+\b\)``. This
can alternatively be specified in a :ref:`bracket argument` without
having to escape the backslashes, e.g. ``[[\(\a\+\b\)]]``.
Manipulation
^^^^^^^^^^^^
.. _APPEND:
.. code-block:: cmake
string(APPEND <string_variable> [<input>...])
Append all the ``<input>`` arguments to the string.
.. _PREPEND:
.. code-block:: cmake
string(PREPEND <string_variable> [<input>...])
Prepend all the ``<input>`` arguments to the string.
.. _CONCAT:
.. code-block:: cmake
string(CONCAT <output_variable> [<input>...])
Concatenate all the ``<input>`` arguments together and store
the result in the named ``<output_variable>``.
.. _JOIN:
.. code-block:: cmake
string(JOIN <glue> <output_variable> [<input>...])
Join all the ``<input>`` arguments together using the ``<glue>``
string and store the result in the named ``<output_variable>``.
To join a list's elements, prefer to use the ``JOIN`` operator
from the :command:`list` command. This allows for the elements to have
special characters like ``;`` in them.
.. _TOLOWER:
.. code-block:: cmake
string(TOLOWER <string> <output_variable>)
Convert ``<string>`` to lower characters.
.. _TOUPPER:
.. code-block:: cmake
string(TOUPPER <string> <output_variable>)
Convert ``<string>`` to upper characters.
.. _LENGTH:
.. code-block:: cmake
string(LENGTH <string> <output_variable>)
Store in an ``<output_variable>`` a given string's length in bytes.
Note that this means if ``<string>`` contains multi-byte characters, the
result stored in ``<output_variable>`` will *not* be the number of characters.
.. _SUBSTRING:
.. code-block:: cmake
string(SUBSTRING <string> <begin> <length> <output_variable>)
Store in an ``<output_variable>`` 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 the
end of the string is used instead.
Both ``<begin>`` and ``<length>`` are counted in bytes, so care must
be exercised if ``<string>`` could contain multi-byte characters.
.. note::
CMake 3.1 and below reported an error if ``<length>`` pointed past
the end of ``<string>``.
.. _STRIP:
.. code-block:: cmake
string(STRIP <string> <output_variable>)
Store in an ``<output_variable>`` a substring of a given ``<string>`` with
leading and trailing spaces removed.
.. _GENEX_STRIP:
.. code-block:: cmake
string(GENEX_STRIP <string> <output_variable>)
Strip any :manual:`generator expressions <cmake-generator-expressions(7)>`
from the input ``<string>`` and store the result in the ``<output_variable>``.
.. _REPEAT:
.. code-block:: cmake
string(REPEAT <string> <count> <output_variable>)
Produce the output string as the input ``<string>`` repeated ``<count>`` times.
Comparison
^^^^^^^^^^
.. _COMPARE:
.. code-block:: cmake
string(COMPARE LESS <string1> <string2> <output_variable>)
string(COMPARE GREATER <string1> <string2> <output_variable>)
string(COMPARE EQUAL <string1> <string2> <output_variable>)
string(COMPARE NOTEQUAL <string1> <string2> <output_variable>)
string(COMPARE LESS_EQUAL <string1> <string2> <output_variable>)
string(COMPARE GREATER_EQUAL <string1> <string2> <output_variable>)
Compare the strings and store true or false in the ``<output_variable>``.
.. _`Supported Hash Algorithms`:
Hashing
^^^^^^^
.. _`HASH`:
.. code-block:: cmake
string(<HASH> <output_variable> <input>)
Compute a cryptographic hash of the ``<input>`` string.
The supported ``<HASH>`` algorithm names are:
``MD5``
Message-Digest Algorithm 5, RFC 1321.
``SHA1``
US Secure Hash Algorithm 1, RFC 3174.
``SHA224``
US Secure Hash Algorithms, RFC 4634.
``SHA256``
US Secure Hash Algorithms, RFC 4634.
``SHA384``
US Secure Hash Algorithms, RFC 4634.
``SHA512``
US Secure Hash Algorithms, RFC 4634.
``SHA3_224``
Keccak SHA-3.
``SHA3_256``
Keccak SHA-3.
``SHA3_384``
Keccak SHA-3.
``SHA3_512``
Keccak SHA-3.
Generation
^^^^^^^^^^
.. _ASCII:
.. code-block:: cmake
string(ASCII <number> [<number> ...] <output_variable>)
Convert all numbers into corresponding ASCII characters.
.. _HEX:
.. code-block:: cmake
string(HEX <string> <output_variable>)
Convert each byte in the input ``<string>`` to its hexadecimal representation
and store the concatenated hex digits in the ``<output_variable>``. Letters in
the output (``a`` through ``f``) are in lowercase.
.. _CONFIGURE:
.. code-block:: cmake
string(CONFIGURE <string> <output_variable>
[@ONLY] [ESCAPE_QUOTES])
Transform a ``<string>`` like :command:`configure_file` transforms a file.
.. _MAKE_C_IDENTIFIER:
.. code-block:: cmake
string(MAKE_C_IDENTIFIER <string> <output_variable>)
Convert each non-alphanumeric character in the input ``<string>`` to an
underscore and store the result in the ``<output_variable>``. If the first
character of the ``<string>`` is a digit, an underscore will also be prepended
to the result.
.. _RANDOM:
.. code-block:: cmake
string(RANDOM [LENGTH <length>] [ALPHABET <alphabet>]
[RANDOM_SEED <seed>] <output_variable>)
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
random number generator.
.. _TIMESTAMP:
.. code-block:: cmake
string(TIMESTAMP <output_variable> [<format_string>] [UTC])
Write a string representation of the current date
and/or time to the ``<output_variable>``.
If the command is 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
be in Coordinated Universal Time (UTC) rather than local time.
The optional ``<format_string>`` may contain the following format
specifiers:
::
%% A literal percent sign (%).
%d The day of the current month (01-31).
%H The hour on a 24-hour clock (00-23).
%I The hour on a 12-hour clock (01-12).
%j The day of the current year (001-366).
%m The month of the current year (01-12).
%b Abbreviated month name (e.g. Oct).
%B Full month name (e.g. October).
%M The minute of the current hour (00-59).
%s Seconds since midnight (UTC) 1-Jan-1970 (UNIX time).
%S The second of the current minute.
60 represents a leap second. (00-60)
%U The week number of the current year (00-53).
%w The day of the current week. 0 is Sunday. (0-6)
%a Abbreviated weekday name (e.g. Fri).
%A Full weekday name (e.g. Friday).
%y The last two digits of the current year (00-99)
%Y The current year.
Unknown format specifiers will be ignored and copied to the output
as-is.
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.
.. note::
If the ``SOURCE_DATE_EPOCH`` environment variable is set,
its value will be used instead of the current time.
See https://reproducible-builds.org/specs/source-date-epoch/ for details.
.. _UUID:
.. code-block:: cmake
string(UUID <output_variable> NAMESPACE <namespace> NAME <name>
TYPE <MD5|SHA1> [UPPER])
Create a universally 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``
where each ``x`` represents a lower case hexadecimal character.
Where required, an uppercase representation can be requested
with the optional ``UPPER`` flag.

50
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/target_compile_options.rst
View File

@ -1,50 +0,0 @@
target_compile_options
----------------------
Add compile options to a target.
.. code-block:: cmake
target_compile_options(<target> [BEFORE]
<INTERFACE|PUBLIC|PRIVATE> [items1...]
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
Adds options to the :prop_tgt:`COMPILE_OPTIONS` or
:prop_tgt:`INTERFACE_COMPILE_OPTIONS` target properties. These options
are used when compiling the given ``<target>``, which must have been
created by a command such as :command:`add_executable` or
:command:`add_library` and must not be an :ref:`ALIAS target <Alias Targets>`.
Arguments
^^^^^^^^^
If ``BEFORE`` is specified, the content will be prepended to the property
instead of being appended.
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
items will populate the :prop_tgt:`COMPILE_OPTIONS` property of
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
:prop_tgt:`INTERFACE_COMPILE_OPTIONS` property of ``<target>``.
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
The following arguments specify compile options. Repeated calls for the same
``<target>`` append items in the order called.
Arguments to ``target_compile_options`` may use "generator expressions"
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
manual for more on defining buildsystem properties.
.. include:: OPTIONS_SHELL.txt
See Also
^^^^^^^^
This command can be used to add any options. However, for adding
preprocessor definitions and include directories it is recommended
to use the more specific commands :command:`target_compile_definitions`
and :command:`target_include_directories`.
For directory-wide settings, there is the command :command:`add_compile_options`.
For file-specific settings, there is the source file property :prop_sf:`COMPILE_OPTIONS`.

62
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/target_include_directories.rst
View File

@ -1,62 +0,0 @@
target_include_directories
--------------------------
Add include directories to a target.
.. code-block:: cmake
target_include_directories(<target> [SYSTEM] [BEFORE]
<INTERFACE|PUBLIC|PRIVATE> [items1...]
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
Specifies include directories to use when compiling a given target.
The named ``<target>`` must have been created by a command such
as :command:`add_executable` or :command:`add_library` and must not be an
:ref:`ALIAS target <Alias Targets>`.
If ``BEFORE`` is specified, the content will be prepended to the property
instead of being appended.
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to specify
the scope of the following arguments. ``PRIVATE`` and ``PUBLIC`` items will
populate the :prop_tgt:`INCLUDE_DIRECTORIES` property of ``<target>``.
``PUBLIC`` and ``INTERFACE`` items will populate the
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` property of ``<target>``.
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
The following arguments specify include directories.
Specified include directories may be absolute paths or relative paths.
Repeated calls for the same <target> append items in the order called. If
``SYSTEM`` is specified, the compiler will be told the
directories are meant as system include directories on some platforms
(signalling this setting might achieve effects such as the compiler
skipping warnings, or these fixed-install system files not being
considered in dependency calculations - see compiler docs). If ``SYSTEM``
is used together with ``PUBLIC`` or ``INTERFACE``, the
:prop_tgt:`INTERFACE_SYSTEM_INCLUDE_DIRECTORIES` target property will be
populated with the specified directories.
Arguments to ``target_include_directories`` may use "generator expressions"
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
manual for more on defining buildsystem properties.
Include directories usage requirements commonly differ between the build-tree
and the install-tree. The ``BUILD_INTERFACE`` and ``INSTALL_INTERFACE``
generator expressions can be used to describe separate usage requirements
based on the usage location. Relative paths are allowed within the
``INSTALL_INTERFACE`` expression and are interpreted relative to the
installation prefix. For example:
.. code-block:: cmake
target_include_directories(mylib PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/mylib>
$<INSTALL_INTERFACE:include/mylib> # <prefix>/include/mylib
)
Creating Relocatable Packages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. |INTERFACE_PROPERTY_LINK| replace:: :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`
.. include:: /include/INTERFACE_INCLUDE_DIRECTORIES_WARNING.txt

34
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/target_sources.rst
View File

@ -1,34 +0,0 @@
target_sources
--------------
Add sources to a target.
.. code-block:: cmake
target_sources(<target>
<INTERFACE|PUBLIC|PRIVATE> [items1...]
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
Specifies sources to use when compiling a given target. Relative
source file paths are interpreted as being relative to the current
source directory (i.e. :variable:`CMAKE_CURRENT_SOURCE_DIR`). The
named ``<target>`` must have been created by a command such as
:command:`add_executable` or :command:`add_library` and must not be an
:ref:`ALIAS target <Alias Targets>`.
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
items will populate the :prop_tgt:`SOURCES` property of
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
:prop_tgt:`INTERFACE_SOURCES` property of ``<target>``.
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
The following arguments specify sources. Repeated calls for the same
``<target>`` append items in the order called.
Arguments to ``target_sources`` may use "generator expressions"
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
manual for more on defining buildsystem properties.
See also the :policy:`CMP0076` policy for older behavior related to the
handling of relative source file paths.

192
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/try_compile.rst
View File

@ -1,192 +0,0 @@
try_compile
-----------
.. only:: html
.. contents::
Try building some code.
Try Compiling Whole Projects
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
try_compile(<resultVar> <bindir> <srcdir>
<projectName> [<targetName>] [CMAKE_FLAGS <flags>...]
[OUTPUT_VARIABLE <var>])
Try building a project. The success or failure of the ``try_compile``,
i.e. ``TRUE`` or ``FALSE`` respectively, is returned in ``<resultVar>``.
In this form, ``<srcdir>`` should contain a complete CMake project with a
``CMakeLists.txt`` file and all sources. The ``<bindir>`` and ``<srcdir>``
will not be deleted after this command is run. Specify ``<targetName>`` to
build a specific target instead of the ``all`` or ``ALL_BUILD`` target. See
below for the meaning of other options.
Try Compiling Source Files
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
try_compile(<resultVar> <bindir> <srcfile|SOURCES srcfile...>
[CMAKE_FLAGS <flags>...]
[COMPILE_DEFINITIONS <defs>...]
[LINK_OPTIONS <options>...]
[LINK_LIBRARIES <libs>...]
[OUTPUT_VARIABLE <var>]
[COPY_FILE <fileName> [COPY_FILE_ERROR <var>]]
[<LANG>_STANDARD <std>]
[<LANG>_STANDARD_REQUIRED <bool>]
[<LANG>_EXTENSIONS <bool>]
)
Try building an executable or static library from one or more source files
(which one is determined by the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE`
variable). The success or failure of the ``try_compile``, i.e. ``TRUE`` or
``FALSE`` respectively, is returned in ``<resultVar>``.
In this form, one or more source files must be provided. If
:variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` is unset or is set to ``EXECUTABLE``,
the sources must include a definition for ``main`` and CMake will create a
``CMakeLists.txt`` file to build the source(s) as an executable.
If :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` is set to ``STATIC_LIBRARY``,
a static library will be built instead and no definition for ``main`` is
required. For an executable, the generated ``CMakeLists.txt`` file would
contain something like the following:
.. code-block:: cmake
add_definitions(<expanded COMPILE_DEFINITIONS from caller>)
include_directories(${INCLUDE_DIRECTORIES})
link_directories(${LINK_DIRECTORIES})
add_executable(cmTryCompileExec <srcfile>...)
target_link_options(cmTryCompileExec PRIVATE <LINK_OPTIONS from caller>)
target_link_libraries(cmTryCompileExec ${LINK_LIBRARIES})
The options are:
``CMAKE_FLAGS <flags>...``
Specify flags of the form ``-DVAR:TYPE=VALUE`` to be passed to
the ``cmake`` command-line used to drive the test build.
The above example shows how values for variables
``INCLUDE_DIRECTORIES``, ``LINK_DIRECTORIES``, and ``LINK_LIBRARIES``
are used.
``COMPILE_DEFINITIONS <defs>...``
Specify ``-Ddefinition`` arguments to pass to :command:`add_definitions`
in the generated test project.
``COPY_FILE <fileName>``
Copy the built executable or static library to the given ``<fileName>``.
``COPY_FILE_ERROR <var>``
Use after ``COPY_FILE`` to capture into variable ``<var>`` any error
message encountered while trying to copy the file.
``LINK_LIBRARIES <libs>...``
Specify libraries to be linked in the generated project.
The list of libraries may refer to system libraries and to
:ref:`Imported Targets <Imported Targets>` from the calling project.
If this option is specified, any ``-DLINK_LIBRARIES=...`` value
given to the ``CMAKE_FLAGS`` option will be ignored.
``LINK_OPTIONS <options>...``
Specify link step options to pass to :command:`target_link_options` or to
set the :prop_tgt:`STATIC_LIBRARY_OPTIONS` target property in the generated
project, depending on the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable.
``OUTPUT_VARIABLE <var>``
Store the output from the build process in the given variable.
``<LANG>_STANDARD <std>``
Specify the :prop_tgt:`C_STANDARD`, :prop_tgt:`CXX_STANDARD`,
:prop_tgt:`OBJC_STANDARD`, :prop_tgt:`OBJCXX_STANDARD`,
or :prop_tgt:`CUDA_STANDARD` target property of the generated project.
``<LANG>_STANDARD_REQUIRED <bool>``
Specify the :prop_tgt:`C_STANDARD_REQUIRED`,
:prop_tgt:`CXX_STANDARD_REQUIRED`, :prop_tgt:`OBJC_STANDARD_REQUIRED`,
:prop_tgt:`OBJCXX_STANDARD_REQUIRED`,or :prop_tgt:`CUDA_STANDARD_REQUIRED`
target property of the generated project.
``<LANG>_EXTENSIONS <bool>``
Specify the :prop_tgt:`C_EXTENSIONS`, :prop_tgt:`CXX_EXTENSIONS`,
:prop_tgt:`OBJC_EXTENSIONS`, :prop_tgt:`OBJCXX_EXTENSIONS`,
or :prop_tgt:`CUDA_EXTENSIONS` target property of the generated project.
In this version all files in ``<bindir>/CMakeFiles/CMakeTmp`` will be
cleaned automatically. For debugging, ``--debug-trycompile`` can be
passed to ``cmake`` to avoid this clean. However, multiple sequential
``try_compile`` operations reuse this single output directory. If you use
``--debug-trycompile``, you can only debug one ``try_compile`` call at a time.
The recommended procedure is to protect all ``try_compile`` calls in your
project by ``if(NOT DEFINED <resultVar>)`` logic, configure with cmake
all the way through once, then delete the cache entry associated with
the try_compile call of interest, and then re-run cmake again with
``--debug-trycompile``.
Other Behavior Settings
^^^^^^^^^^^^^^^^^^^^^^^
If set, the following variables are passed in to the generated
try_compile CMakeLists.txt to initialize compile target properties with
default values:
* :variable:`CMAKE_CUDA_RUNTIME_LIBRARY`
* :variable:`CMAKE_ENABLE_EXPORTS`
* :variable:`CMAKE_LINK_SEARCH_START_STATIC`
* :variable:`CMAKE_LINK_SEARCH_END_STATIC`
* :variable:`CMAKE_MSVC_RUNTIME_LIBRARY`
* :variable:`CMAKE_POSITION_INDEPENDENT_CODE`
If :policy:`CMP0056` is set to ``NEW``, then
:variable:`CMAKE_EXE_LINKER_FLAGS` is passed in as well.
If :policy:`CMP0083` is set to ``NEW``, then in order to obtain correct
behavior at link time, the ``check_pie_supported()`` command from the
:module:`CheckPIESupported` module must be called before using the
:command:`try_compile` command.
The current settings of :policy:`CMP0065` and :policy:`CMP0083` are propagated
through to the generated test project.
Set the :variable:`CMAKE_TRY_COMPILE_CONFIGURATION` variable to choose
a build configuration.
Set the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable to specify
the type of target used for the source file signature.
Set the :variable:`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable to specify
variables that must be propagated into the test project. This variable is
meant for use only in toolchain files and is only honored by the
``try_compile()`` command for the source files form, not when given a whole
project.
If :policy:`CMP0067` is set to ``NEW``, or any of the ``<LANG>_STANDARD``,
``<LANG>_STANDARD_REQUIRED``, or ``<LANG>_EXTENSIONS`` options are used,
then the language standard variables are honored:
* :variable:`CMAKE_C_STANDARD`
* :variable:`CMAKE_C_STANDARD_REQUIRED`
* :variable:`CMAKE_C_EXTENSIONS`
* :variable:`CMAKE_CXX_STANDARD`
* :variable:`CMAKE_CXX_STANDARD_REQUIRED`
* :variable:`CMAKE_CXX_EXTENSIONS`
* :variable:`CMAKE_OBJC_STANDARD`
* :variable:`CMAKE_OBJC_STANDARD_REQUIRED`
* :variable:`CMAKE_OBJC_EXTENSIONS`
* :variable:`CMAKE_OBJCXX_STANDARD`
* :variable:`CMAKE_OBJCXX_STANDARD_REQUIRED`
* :variable:`CMAKE_OBJCXX_EXTENSIONS`
* :variable:`CMAKE_CUDA_STANDARD`
* :variable:`CMAKE_CUDA_STANDARD_REQUIRED`
* :variable:`CMAKE_CUDA_EXTENSIONS`
Their values are used to set the corresponding target properties in
the generated project (unless overridden by an explicit option).
For the :generator:`Green Hills MULTI` generator the GHS toolset and target
system customization cache variables are also propagated into the test project.

103
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/try_run.rst
View File

@ -1,103 +0,0 @@
try_run
-------
.. only:: html
.. contents::
Try compiling and then running some code.
Try Compiling and Running Source Files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
try_run(<runResultVar> <compileResultVar>
<bindir> <srcfile> [CMAKE_FLAGS <flags>...]
[COMPILE_DEFINITIONS <defs>...]
[LINK_OPTIONS <options>...]
[LINK_LIBRARIES <libs>...]
[COMPILE_OUTPUT_VARIABLE <var>]
[RUN_OUTPUT_VARIABLE <var>]
[OUTPUT_VARIABLE <var>]
[ARGS <args>...])
Try compiling a ``<srcfile>``. Returns ``TRUE`` or ``FALSE`` for success
or failure in ``<compileResultVar>``. If the compile succeeded, runs the
executable and returns its exit code in ``<runResultVar>``. If the
executable was built, but failed to run, then ``<runResultVar>`` will be
set to ``FAILED_TO_RUN``. See the :command:`try_compile` command for
information on how the test project is constructed to build the source file.
The options are:
``CMAKE_FLAGS <flags>...``
Specify flags of the form ``-DVAR:TYPE=VALUE`` to be passed to
the ``cmake`` command-line used to drive the test build.
The example in :command:`try_compile` shows how values for variables
``INCLUDE_DIRECTORIES``, ``LINK_DIRECTORIES``, and ``LINK_LIBRARIES``
are used.
``COMPILE_DEFINITIONS <defs>...``
Specify ``-Ddefinition`` arguments to pass to :command:`add_definitions`
in the generated test project.
``COMPILE_OUTPUT_VARIABLE <var>``
Report the compile step build output in a given variable.
``LINK_LIBRARIES <libs>...``
Specify libraries to be linked in the generated project.
The list of libraries may refer to system libraries and to
:ref:`Imported Targets <Imported Targets>` from the calling project.
If this option is specified, any ``-DLINK_LIBRARIES=...`` value
given to the ``CMAKE_FLAGS`` option will be ignored.
``LINK_OPTIONS <options>...``
Specify link step options to pass to :command:`target_link_options` in the
generated project.
``OUTPUT_VARIABLE <var>``
Report the compile build output and the output from running the executable
in the given variable. This option exists for legacy reasons. Prefer
``COMPILE_OUTPUT_VARIABLE`` and ``RUN_OUTPUT_VARIABLE`` instead.
``RUN_OUTPUT_VARIABLE <var>``
Report the output from running the executable in a given variable.
Other Behavior Settings
^^^^^^^^^^^^^^^^^^^^^^^
Set the :variable:`CMAKE_TRY_COMPILE_CONFIGURATION` variable to choose
a build configuration.
Behavior when Cross Compiling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When cross compiling, the executable compiled in the first step
usually cannot be run on the build host. The ``try_run`` command checks
the :variable:`CMAKE_CROSSCOMPILING` variable to detect whether CMake is in
cross-compiling mode. If that is the case, it will still try to compile
the executable, but it will not try to run the executable unless the
:variable:`CMAKE_CROSSCOMPILING_EMULATOR` variable is set. Instead it
will create cache variables which must be filled by the user or by
presetting them in some CMake script file to the values the executable
would have produced if it had been run on its actual target platform.
These cache entries are:
``<runResultVar>``
Exit code if the executable were to be run on the target platform.
``<runResultVar>__TRYRUN_OUTPUT``
Output from stdout and stderr if the executable were to be run on
the target platform. This is created only if the
``RUN_OUTPUT_VARIABLE`` or ``OUTPUT_VARIABLE`` option was used.
In order to make cross compiling your project easier, use ``try_run``
only if really required. If you use ``try_run``, use the
``RUN_OUTPUT_VARIABLE`` or ``OUTPUT_VARIABLE`` options only if really
required. Using them will require that when cross-compiling, the cache
variables will have to be set manually to the output of the executable.
You can also "guard" the calls to ``try_run`` with an :command:`if`
block checking the :variable:`CMAKE_CROSSCOMPILING` variable and
provide an easy-to-preset alternative for this case.

15
6.5.1/_tools/cmake/share/cmake-3.18/Help/command/variable_watch.rst
View File

@ -1,15 +0,0 @@
variable_watch
--------------
Watch the CMake variable for change.
.. code-block:: cmake
variable_watch(<variable> [<command>])
If the specified ``<variable>`` changes, a message will be printed
to inform about the change.
Additionally, if ``<command>`` is given, this command will be executed.
The command will receive the following arguments:
``COMMAND(<variable> <access> <value> <current_list_file> <stack>)``

347
6.5.1/_tools/cmake/share/cmake-3.18/Help/cpack_gen/ifw.rst
View File

@ -1,347 +0,0 @@
CPack IFW Generator
-------------------
Configure and run the Qt Installer Framework to generate a Qt installer.
.. only:: html
.. contents::
Overview
^^^^^^^^
This :manual:`cpack generator <cpack-generators(7)>` generates
configuration and meta information for the `Qt Installer Framework
<http://doc.qt.io/qtinstallerframework/index.html>`_ (QtIFW),
and runs QtIFW tools to generate a Qt installer.
QtIFW provides tools and utilities to create installers for
the platforms supported by `Qt <https://www.qt.io>`_: Linux,
Microsoft Windows, and macOS.
To make use of this generator, QtIFW needs to be installed.
The :module:`CPackIFW` module looks for the location of the
QtIFW command-line utilities, and defines several commands to
control the behavior of this generator.
Variables
^^^^^^^^^
You can use the following variables to change behavior of CPack ``IFW``
generator.
Debug
"""""
.. variable:: CPACK_IFW_VERBOSE
Set to ``ON`` to enable addition debug output.
By default is ``OFF``.
Package
"""""""
.. variable:: CPACK_IFW_PACKAGE_TITLE
Name of the installer as displayed on the title bar.
By default used :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY`.
.. variable:: CPACK_IFW_PACKAGE_PUBLISHER
Publisher of the software (as shown in the Windows Control Panel).
By default used :variable:`CPACK_PACKAGE_VENDOR`.
.. variable:: CPACK_IFW_PRODUCT_URL
URL to a page that contains product information on your web site.
.. variable:: CPACK_IFW_PACKAGE_ICON
Filename for a custom installer icon. The actual file is '.icns' (macOS),
'.ico' (Windows). No functionality on Unix.
.. variable:: CPACK_IFW_PACKAGE_WINDOW_ICON
Filename for a custom window icon in PNG format for the Installer
application.
.. variable:: CPACK_IFW_PACKAGE_LOGO
Filename for a logo is used as QWizard::LogoPixmap.
.. variable:: CPACK_IFW_PACKAGE_WATERMARK
Filename for a watermark is used as QWizard::WatermarkPixmap.
.. variable:: CPACK_IFW_PACKAGE_BANNER
Filename for a banner is used as QWizard::BannerPixmap.
.. variable:: CPACK_IFW_PACKAGE_BACKGROUND
Filename for an image used as QWizard::BackgroundPixmap (only used by MacStyle).
.. variable:: CPACK_IFW_PACKAGE_WIZARD_STYLE
Wizard style to be used ("Modern", "Mac", "Aero" or "Classic").
.. variable:: CPACK_IFW_PACKAGE_STYLE_SHEET
Filename for a stylesheet.
.. variable:: CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH
Default width of the wizard in pixels. Setting a banner image will override this.
.. variable:: CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT
Default height of the wizard in pixels. Setting a watermark image will override this.
.. variable:: CPACK_IFW_PACKAGE_TITLE_COLOR
Color of the titles and subtitles (takes an HTML color code, such as "#88FF33").
.. variable:: CPACK_IFW_PACKAGE_START_MENU_DIRECTORY
Name of the default program group for the product in the Windows Start menu.
By default used :variable:`CPACK_IFW_PACKAGE_NAME`.
.. variable:: CPACK_IFW_TARGET_DIRECTORY
Default target directory for installation.
By default used
"@ApplicationsDir@/:variable:`CPACK_PACKAGE_INSTALL_DIRECTORY`"
(variables embedded in '@' are expanded by the
`QtIFW scripting engine <https://doc.qt.io/qtinstallerframework/scripting.html>`_).
You can use predefined variables.
.. variable:: CPACK_IFW_ADMIN_TARGET_DIRECTORY
Default target directory for installation with administrator rights.
You can use predefined variables.
.. variable:: CPACK_IFW_PACKAGE_GROUP
The group, which will be used to configure the root package
.. variable:: CPACK_IFW_PACKAGE_NAME
The root package name, which will be used if configuration group is not
specified
.. variable:: CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME
Filename of the generated maintenance tool.
The platform-specific executable file extension is appended.
By default used QtIFW defaults (``maintenancetool``).
.. variable:: CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR
Set to ``OFF`` if the target directory should not be deleted when uninstalling.
Is ``ON`` by default
.. variable:: CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE
Filename for the configuration of the generated maintenance tool.
By default used QtIFW defaults (``maintenancetool.ini``).
.. variable:: CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS
Set to ``ON`` if the installation path can contain non-ASCII characters.
Is ``ON`` for QtIFW less 2.0 tools.
.. variable:: CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH
Set to ``OFF`` if the installation path cannot contain space characters.
Is ``ON`` for QtIFW less 2.0 tools.
.. variable:: CPACK_IFW_PACKAGE_CONTROL_SCRIPT
Filename for a custom installer control script.
.. variable:: CPACK_IFW_PACKAGE_RESOURCES
List of additional resources ('.qrc' files) to include in the installer
binary.
You can use :command:`cpack_ifw_add_package_resources` command to resolve
relative paths.
.. variable:: CPACK_IFW_PACKAGE_FILE_EXTENSION
The target binary extension.
On Linux, the name of the target binary is automatically extended with
'.run', if you do not specify the extension.
On Windows, the target is created as an application with the extension
'.exe', which is automatically added, if not supplied.
On Mac, the target is created as an DMG disk image with the extension
'.dmg', which is automatically added, if not supplied.
.. variable:: CPACK_IFW_REPOSITORIES_ALL
The list of remote repositories.
The default value of this variable is computed by CPack and contains
all repositories added with command :command:`cpack_ifw_add_repository`
or updated with command :command:`cpack_ifw_update_repository`.
.. variable:: CPACK_IFW_DOWNLOAD_ALL
If this is ``ON`` all components will be downloaded.
By default is ``OFF`` or used value
from ``CPACK_DOWNLOAD_ALL`` if set
Components
""""""""""
.. variable:: CPACK_IFW_RESOLVE_DUPLICATE_NAMES
Resolve duplicate names when installing components with groups.
.. variable:: CPACK_IFW_PACKAGES_DIRECTORIES
Additional prepared packages dirs that will be used to resolve
dependent components.
.. variable:: CPACK_IFW_REPOSITORIES_DIRECTORIES
Additional prepared repository dirs that will be used to resolve and
repack dependent components. This feature available only
since QtIFW 3.1.
QtIFW Tools
"""""""""""
.. variable:: CPACK_IFW_FRAMEWORK_VERSION
The version of used QtIFW tools.
The following variables provide the locations of the QtIFW
command-line tools as discovered by the module :module:`CPackIFW`.
These variables are cached, and may be configured if needed.
.. variable:: CPACK_IFW_BINARYCREATOR_EXECUTABLE
The path to ``binarycreator``.
.. variable:: CPACK_IFW_REPOGEN_EXECUTABLE
The path to ``repogen``.
.. variable:: CPACK_IFW_INSTALLERBASE_EXECUTABLE
The path to ``installerbase``.
.. variable:: CPACK_IFW_DEVTOOL_EXECUTABLE
The path to ``devtool``.
Hints for Finding QtIFW
"""""""""""""""""""""""
Generally, the CPack ``IFW`` generator automatically finds QtIFW tools,
but if you don't use a default path for installation of the QtIFW tools,
the path may be specified in either a CMake or an environment variable:
.. variable:: CPACK_IFW_ROOT
An CMake variable which specifies the location of the QtIFW tool suite.
The variable will be cached in the ``CPackConfig.cmake`` file and used at
CPack runtime.
.. variable:: QTIFWDIR
An environment variable which specifies the location of the QtIFW tool
suite.
.. note::
The specified path should not contain "bin" at the end
(for example: "D:\\DevTools\\QtIFW2.0.5").
The :variable:`CPACK_IFW_ROOT` variable has a higher priority and overrides
the value of the :variable:`QTIFWDIR` variable.
Other Settings
^^^^^^^^^^^^^^
Online installer
""""""""""""""""
By default, this generator generates an *offline installer*. This means that
that all packaged files are fully contained in the installer executable.
In contrast, an *online installer* will download some or all components from
a remote server.
The ``DOWNLOADED`` option in the :command:`cpack_add_component` command
specifies that a component is to be downloaded. Alternatively, the ``ALL``
option in the :command:`cpack_configure_downloads` command specifies that
`all` components are to be be downloaded.
The :command:`cpack_ifw_add_repository` command and the
:variable:`CPACK_IFW_DOWNLOAD_ALL` variable allow for more specific
configuration.
When there are online components, CPack will write them to archive files.
The help page of the :module:`CPackComponent` module, especially the section
on the :command:`cpack_configure_downloads` function, explains how to make
these files accessible from a download URL.
Internationalization
""""""""""""""""""""
Some variables and command arguments support internationalization via
CMake script. This is an optional feature.
Installers created by QtIFW tools have built-in support for
internationalization and many phrases are localized to many languages,
but this does not apply to the description of the your components and groups
that will be distributed.
Localization of the description of your components and groups is useful for
users of your installers.
A localized variable or argument can contain a single default value, and a
set of pairs the name of the locale and the localized value.
For example:
.. code-block:: cmake
set(LOCALIZABLE_VARIABLE "Default value"
en "English value"
en_US "American value"
en_GB "Great Britain value"
)
See Also
^^^^^^^^
Qt Installer Framework Manual:
* Index page:
http://doc.qt.io/qtinstallerframework/index.html
* Component Scripting:
http://doc.qt.io/qtinstallerframework/scripting.html
* Predefined Variables:
http://doc.qt.io/qtinstallerframework/scripting.html#predefined-variables
* Promoting Updates:
http://doc.qt.io/qtinstallerframework/ifw-updates.html
Download Qt Installer Framework for your platform from Qt site:
http://download.qt.io/official_releases/qt-installer-framework

79
6.5.1/_tools/cmake/share/cmake-3.18/Help/cpack_gen/packagemaker.rst
View File

@ -1,79 +0,0 @@
CPack PackageMaker Generator
----------------------------
PackageMaker CPack generator (macOS).
.. deprecated:: 3.17
Xcode no longer distributes the PackageMaker tools.
This CPack generator will be removed in a future version of CPack.
Variables specific to CPack PackageMaker generator
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following variable is specific to installers built on Mac
macOS using PackageMaker:
.. variable:: CPACK_OSX_PACKAGE_VERSION
The version of macOS that the resulting PackageMaker archive should be
compatible with. Different versions of macOS support different
features. For example, CPack can only build component-based installers for
macOS 10.4 or newer, and can only build installers that download
components on-the-fly for macOS 10.5 or newer. If left blank, this value
will be set to the minimum version of macOS that supports the requested
features. Set this variable to some value (e.g., 10.4) only if you want to
guarantee that your installer will work on that version of macOS, and
don't mind missing extra features available in the installer shipping with
later versions of macOS.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND
Adds a background to Distribtion XML if specified. The value contains the
path to image in ``Resources`` directory.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_ALIGNMENT
Adds an ``alignment`` attribute to the background in Distribution XML.
Refer to Apple documentation for valid values.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_SCALING
Adds a ``scaling`` attribute to the background in Distribution XML.
Refer to Apple documentation for valid values.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_MIME_TYPE
Adds a ``mime-type`` attribute to the background in Distribution XML.
The option contains MIME type of an image.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_UTI
Adds an ``uti`` attribute to the background in Distribution XML.
The option contains UTI type of an image.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_DARKAQUA
Adds a background for the Dark Aqua theme to Distribution XML if
specified. The value contains the path to image in ``Resources``
directory.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_DARKAQUA_ALIGNMENT
Does the same as :variable:`CPACK_PACKAGEMAKER_BACKGROUND_ALIGNMENT` option,
but for the dark theme.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_DARKAQUA_SCALING
Does the same as :variable:`CPACK_PACKAGEMAKER_BACKGROUND_SCALING` option,
but for the dark theme.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_DARKAQUA_MIME_TYPE
Does the same as :variable:`CPACK_PACKAGEMAKER_BACKGROUND_MIME_TYPE` option,
but for the dark theme.
.. variable:: CPACK_PACKAGEMAKER_BACKGROUND_DARKAQUA_UTI
Does the same as :variable:`CPACK_PACKAGEMAKER_BACKGROUND_UTI` option,
but for the dark theme.

118
6.5.1/_tools/cmake/share/cmake-3.18/Help/cpack_gen/productbuild.rst
View File

@ -1,118 +0,0 @@
CPack productbuild Generator
----------------------------
productbuild CPack generator (macOS).
Variables specific to CPack productbuild generator
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following variable is specific to installers built on Mac
macOS using ProductBuild:
.. variable:: CPACK_COMMAND_PRODUCTBUILD
Path to the ``productbuild(1)`` command used to generate a product archive for
the macOS Installer or Mac App Store. This variable can be used to override
the automatically detected command (or specify its location if the
auto-detection fails to find it).
.. variable:: CPACK_PRODUCTBUILD_IDENTITY_NAME
Adds a digital signature to the resulting package.
.. variable:: CPACK_PRODUCTBUILD_KEYCHAIN_PATH
Specify a specific keychain to search for the signing identity.
.. variable:: CPACK_COMMAND_PKGBUILD
Path to the ``pkgbuild(1)`` command used to generate an macOS component package
on macOS. This variable can be used to override the automatically detected
command (or specify its location if the auto-detection fails to find it).
.. variable:: CPACK_PKGBUILD_IDENTITY_NAME
Adds a digital signature to the resulting package.
.. variable:: CPACK_PKGBUILD_KEYCHAIN_PATH
Specify a specific keychain to search for the signing identity.
.. variable:: CPACK_PREFLIGHT_<COMP>_SCRIPT
Full path to a file that will be used as the ``preinstall`` script for the
named ``<COMP>`` component's package, where ``<COMP>`` is the uppercased
component name. No ``preinstall`` script is added if this variable is not
defined for a given component.
.. variable:: CPACK_POSTFLIGHT_<COMP>_SCRIPT
Full path to a file that will be used as the ``postinstall`` script for the
named ``<COMP>`` component's package, where ``<COMP>`` is the uppercased
component name. No ``postinstall`` script is added if this variable is not
defined for a given component.
.. variable:: CPACK_PRODUCTBUILD_RESOURCES_DIR
If specified the productbuild generator copies files from this directory
(including subdirectories) to the ``Resources`` directory. This is done
before the :variable:`CPACK_RESOURCE_FILE_WELCOME`,
:variable:`CPACK_RESOURCE_FILE_README`, and
:variable:`CPACK_RESOURCE_FILE_LICENSE` files are copied.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND
Adds a background to Distribtion XML if specified. The value contains the
path to image in ``Resources`` directory.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_ALIGNMENT
Adds an ``alignment`` attribute to the background in Distribution XML.
Refer to Apple documentation for valid values.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_SCALING
Adds a ``scaling`` attribute to the background in Distribution XML.
Refer to Apple documentation for valid values.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_MIME_TYPE
Adds a ``mime-type`` attribute to the background in Distribution XML.
The option contains MIME type of an image.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_UTI
Adds an ``uti`` attribute to the background in Distribution XML.
The option contains UTI type of an image.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA
Adds a background for the Dark Aqua theme to Distribution XML if
specified. The value contains the path to image in ``Resources``
directory.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_ALIGNMENT
Does the same as :variable:`CPACK_PRODUCTBUILD_BACKGROUND_ALIGNMENT` option,
but for the dark theme.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_SCALING
Does the same as :variable:`CPACK_PRODUCTBUILD_BACKGROUND_SCALING` option,
but for the dark theme.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_MIME_TYPE
Does the same as :variable:`CPACK_PRODUCTBUILD_BACKGROUND_MIME_TYPE` option,
but for the dark theme.
.. variable:: CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_UTI
Does the same as :variable:`CPACK_PRODUCTBUILD_BACKGROUND_UTI` option,
but for the dark theme.

15
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/ASM_DIALECTFLAGS.rst
View File

@ -1,15 +0,0 @@
ASM<DIALECT>FLAGS
-----------------
.. include:: ENV_VAR.txt
Default compilation flags to be used when compiling a specific dialect of an
assembly language. ``ASM<DIALECT>FLAGS`` can be ``ASMFLAGS``, ``ASM_NASMFLAGS``,
``ASM_MASMFLAGS`` or ``ASM-ATTFLAGS``. Will only be used by CMake on the
first configuration to determine ``ASM_<DIALECT>`` default compilation
flags, after which the value for ``ASM<DIALECT>FLAGS`` is stored in the cache
as ``CMAKE_ASM<DIALECT>_FLAGS <CMAKE_<LANG>_FLAGS>``. For any configuration
run (including the first), the environment variable will be ignored, if the
``CMAKE_ASM<DIALECT>_FLAGS <CMAKE_<LANG>_FLAGS>`` variable is defined.
See also :variable:`CMAKE_ASM<DIALECT>_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/CFLAGS.rst
View File

@ -1,13 +0,0 @@
CFLAGS
------
.. include:: ENV_VAR.txt
Default compilation flags to be used when compiling ``C`` files. Will only be
used by CMake on the first configuration to determine ``CC`` default compilation
flags, after which the value for ``CFLAGS`` is stored in the cache
as :variable:`CMAKE_C_FLAGS <CMAKE_<LANG>_FLAGS>`. For any configuration run
(including the first), the environment variable will be ignored if the
:variable:`CMAKE_C_FLAGS <CMAKE_<LANG>_FLAGS>` variable is defined.
See also :variable:`CMAKE_C_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/CSFLAGS.rst
View File

@ -1,13 +0,0 @@
CSFLAGS
-------
.. include:: ENV_VAR.txt
Preferred executable for compiling ``CSharp`` language files. Will only be
used by CMake on the first configuration to determine ``CSharp`` default
compilation flags, after which the value for ``CSFLAGS`` is stored in the cache
as :variable:`CMAKE_CSharp_FLAGS <CMAKE_<LANG>_FLAGS>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_CSharp_FLAGS <CMAKE_<LANG>_FLAGS>` variable is defined.
See also :variable:`CMAKE_CSharp_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/CUDAFLAGS.rst
View File

@ -1,13 +0,0 @@
CUDAFLAGS
---------
.. include:: ENV_VAR.txt
Default compilation flags to be used when compiling ``CUDA`` files. Will only be
used by CMake on the first configuration to determine ``CUDA`` default
compilation flags, after which the value for ``CUDAFLAGS`` is stored in the
cache as :variable:`CMAKE_CUDA_FLAGS <CMAKE_<LANG>_FLAGS>`. For any configuration
run (including the first), the environment variable will be ignored if
the :variable:`CMAKE_CUDA_FLAGS <CMAKE_<LANG>_FLAGS>` variable is defined.
See also :variable:`CMAKE_CUDA_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

15
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/CUDAHOSTCXX.rst
View File

@ -1,15 +0,0 @@
CUDAHOSTCXX
-----------
.. include:: ENV_VAR.txt
Preferred executable for compiling host code when compiling ``CUDA``
language files. Will only be used by CMake on the first configuration to
determine ``CUDA`` host compiler, after which the value for ``CUDAHOSTCXX`` is
stored in the cache as :variable:`CMAKE_CUDA_HOST_COMPILER`. For any
configuration run (including the first), the environment variable will be
ignored if the :variable:`CMAKE_CUDA_HOST_COMPILER` variable is defined.
This environment variable is primarily meant for use with projects that
enable ``CUDA`` as a first-class language. The :module:`FindCUDA`
module will also use it to initialize its ``CUDA_HOST_COMPILER`` setting.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/CXXFLAGS.rst
View File

@ -1,13 +0,0 @@
CXXFLAGS
--------
.. include:: ENV_VAR.txt
Default compilation flags to be used when compiling ``CXX`` (C++) files. Will
only be used by CMake on the first configuration to determine ``CXX`` default
compilation flags, after which the value for ``CXXFLAGS`` is stored in the cache
as :variable:`CMAKE_CXX_FLAGS <CMAKE_<LANG>_FLAGS>`. For any configuration run (
including the first), the environment variable will be ignored if
the :variable:`CMAKE_CXX_FLAGS <CMAKE_<LANG>_FLAGS>` variable is defined.
See also :variable:`CMAKE_CXX_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

21
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/DESTDIR.rst
View File

@ -1,21 +0,0 @@
DESTDIR
-------
.. include:: ENV_VAR.txt
On UNIX one can use the ``DESTDIR`` mechanism in order to relocate the
whole installation. ``DESTDIR`` means DESTination DIRectory. It is
commonly used by makefile users in order to install software at
non-default location. It is usually invoked like this:
::
make DESTDIR=/home/john install
which will install the concerned software using the installation
prefix, e.g. ``/usr/local`` prepended with the ``DESTDIR`` value which
finally gives ``/home/john/usr/local``.
WARNING: ``DESTDIR`` may not be used on Windows because installation
prefix usually contains a drive letter like in ``C:/Program Files``
which cannot be prepended with some other prefix.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/FFLAGS.rst
View File

@ -1,13 +0,0 @@
FFLAGS
------
.. include:: ENV_VAR.txt
Default compilation flags to be used when compiling ``Fortran`` files. Will only
be used by CMake on the first configuration to determine ``Fortran`` default
compilation flags, after which the value for ``FFLAGS`` is stored in the cache
as :variable:`CMAKE_Fortran_FLAGS <CMAKE_<LANG>_FLAGS>`. For any configuration
run (including the first), the environment variable will be ignored if
the :variable:`CMAKE_Fortran_FLAGS <CMAKE_<LANG>_FLAGS>` variable is defined.
See also :variable:`CMAKE_Fortran_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

17
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/PackageName_ROOT.rst
View File

@ -1,17 +0,0 @@
<PackageName>_ROOT
------------------
.. include:: ENV_VAR.txt
Calls to :command:`find_package(<PackageName>)` will search in prefixes
specified by the ``<PackageName>_ROOT`` environment variable, where
``<PackageName>`` is the name given to the :command:`find_package` call
and ``_ROOT`` is literal. For example, ``find_package(Foo)`` will search
prefixes specified in the ``Foo_ROOT`` environment variable (if set).
See policy :policy:`CMP0074`.
This variable may hold a single prefix or a list of prefixes separated
by ``:`` on UNIX or ``;`` on Windows (the same as the ``PATH`` environment
variable convention on those platforms).
See also the :variable:`<PackageName>_ROOT` CMake variable.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/envvar/RCFLAGS.rst
View File

@ -1,13 +0,0 @@
RCFLAGS
-------
.. include:: ENV_VAR.txt
Default compilation flags to be used when compiling ``resource`` files. Will
only be used by CMake on the first configuration to determine ``resource``
default compilation flags, after which the value for ``RCFLAGS`` is stored in
the cache as :variable:`CMAKE_RC_FLAGS <CMAKE_<LANG>_FLAGS>`. For any
configuration run (including the first), the environment variable will be ignored
if the :variable:`CMAKE_RC_FLAGS <CMAKE_<LANG>_FLAGS>` variable is defined.
See also :variable:`CMAKE_RC_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.

69
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Green Hills MULTI.rst
View File

@ -1,69 +0,0 @@
Green Hills MULTI
-----------------
Generates Green Hills MULTI project files (experimental, work-in-progress).
The buildsystem has predetermined build-configuration settings that can be controlled
via the :variable:`CMAKE_BUILD_TYPE` variable.
Customizations that are used to pick toolset and target system:
The ``-A <arch>`` can be supplied for setting the target architecture.
``<arch>`` usually is one of ``arm``, ``ppc``, ``86``, etcetera.
If the target architecture is not specified then
the default architecture of ``arm`` will be used.
The ``-T <toolset>`` option can be used to set the directory location of the toolset.
Both absolute and relative paths are valid. Relative paths use ``GHS_TOOLSET_ROOT``
as the root. If the toolset is not specified then the latest toolset found in
``GHS_TOOLSET_ROOT`` will be used.
Cache variables that are used for toolset and target system customization:
* ``GHS_TARGET_PLATFORM``
| Defaults to ``integrity``.
| Usual values are ``integrity``, ``threadx``, ``uvelosity``, ``velosity``,
``vxworks``, ``standalone``.
* ``GHS_PRIMARY_TARGET``
| Sets ``primaryTarget`` entry in project file.
| Defaults to ``<arch>_<GHS_TARGET_PLATFORM>.tgt``.
* ``GHS_TOOLSET_ROOT``
| Root path for ``toolset`` searches.
| Defaults to ``C:/ghs`` in Windows or ``/usr/ghs`` in Linux.
* ``GHS_OS_ROOT``
| Root path for RTOS searches.
| Defaults to ``C:/ghs`` in Windows or ``/usr/ghs`` in Linux.
* ``GHS_OS_DIR`` and ``GHS_OS_DIR_OPTION``
| Sets ``-os_dir`` entry in project file.
| Defaults to latest platform OS installation at ``GHS_OS_ROOT``. Set this value if
a specific RTOS is to be used.
| ``GHS_OS_DIR_OPTION`` default value is ``-os_dir``.
* ``GHS_BSP_NAME``
| Sets ``-bsp`` entry in project file.
| Defaults to ``sim<arch>`` for ``integrity`` platforms.
Customizations are available through the following cache variables:
* ``GHS_CUSTOMIZATION``
* ``GHS_GPJ_MACROS``
The following properties are available:
* :prop_tgt:`GHS_INTEGRITY_APP`
* :prop_tgt:`GHS_NO_SOURCE_GROUP_FILE`
.. note::
This generator is deemed experimental as of CMake |release|
and is still a work in progress. Future versions of CMake
may make breaking changes as the generator matures.

4
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/NMake Makefiles JOM.rst
View File

@ -1,4 +0,0 @@
NMake Makefiles JOM
-------------------
Generates JOM makefiles.

87
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Ninja Multi-Config.rst
View File

@ -1,87 +0,0 @@
Ninja Multi-Config
------------------
Generates multiple ``build-<Config>.ninja`` files.
This generator is very much like the :generator:`Ninja` generator, but with
some key differences. Only these differences will be discussed in this
document.
Unlike the :generator:`Ninja` generator, ``Ninja Multi-Config`` generates
multiple configurations at once with :variable:`CMAKE_CONFIGURATION_TYPES`
instead of only one configuration with :variable:`CMAKE_BUILD_TYPE`. One
``build-<Config>.ninja`` file will be generated for each of these
configurations (with ``<Config>`` being the configuration name.) These files
are intended to be run with ``ninja -f build-<Config>.ninja``. A
``build.ninja`` file is also generated, using the configuration from either
:variable:`CMAKE_DEFAULT_BUILD_TYPE` or the first item from
:variable:`CMAKE_CONFIGURATION_TYPES`.
``cmake --build . --config <Config>`` will always use ``build-<Config>.ninja``
to build. If no ``--config`` argument is specified, ``cmake --build .`` will
default to ``build-Debug.ninja``, unless a ``build.ninja`` is generated (see
below), in which case that will be used instead.
Each ``build-<Config>.ninja`` file contains ``<target>`` targets as well as
``<target>:<Config>`` targets, where ``<Config>`` is the same as the
configuration specified in ``build-<Config>.ninja`` Additionally, if
cross-config mode is enabled, ``build-<Config>.ninja`` may contain
``<target>:<OtherConfig>`` targets, where ``<OtherConfig>`` is a cross-config,
as well as ``<target>:all``, which builds the target in all cross-configs. See
below for how to enable cross-config mode.
The ``Ninja Multi-Config`` generator recognizes the following variables:
:variable:`CMAKE_CONFIGURATION_TYPES`
Specifies the total set of configurations to build.
:variable:`CMAKE_CROSS_CONFIGS`
Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of
configurations available from all ``build-<Config>.ninja`` files.
:variable:`CMAKE_DEFAULT_BUILD_TYPE`
Specifies the configuration to use by default in a ``build.ninja`` file.
:variable:`CMAKE_DEFAULT_CONFIGS`
Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of
configurations to build for a target in ``build.ninja``
if no ``:<Config>`` suffix is specified.
Consider the following example:
.. code-block:: cmake
cmake_minimum_required(VERSION 3.16)
project(MultiConfigNinja C)
add_executable(generator generator.c)
add_custom_command(OUTPUT generated.c COMMAND generator generated.c)
add_library(generated ${CMAKE_BINARY_DIR}/generated.c)
Now assume you configure the project with ``Ninja Multi-Config`` and run one of
the following commands:
.. code-block:: shell
ninja -f build-Debug.ninja generated
# OR
cmake --build . --config Debug --target generated
This would build the ``Debug`` configuration of ``generator``, which would be
used to generate ``generated.c``, which would be used to build the ``Debug``
configuration of ``generated``.
But if :variable:`CMAKE_CROSS_CONFIGS` is set to ``all``, and you run the
following instead:
.. code-block:: shell
ninja -f build-Release.ninja generated:Debug
# OR
cmake --build . --config Release --target generated:Debug
This would build the ``Release`` configuration of ``generator``, which would be
used to generate ``generated.c``, which would be used to build the ``Debug``
configuration of ``generated``. This is useful for running a release-optimized
version of a generator utility while still building the debug version of the
targets built with the generated code.

42
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Ninja.rst
View File

@ -1,42 +0,0 @@
Ninja
-----
Generates ``build.ninja`` files.
A ``build.ninja`` file is generated into the build tree. Use the ninja
program to build the project through the ``all`` target and install the
project through the ``install`` (or ``install/strip``) target.
For each subdirectory ``sub/dir`` of the project, additional targets
are generated:
``sub/dir/all``
Depends on all targets required by the subdirectory.
``sub/dir/install``
Runs the install step in the subdirectory, if any.
``sub/dir/install/strip``
Runs the install step in the subdirectory followed by a ``CMAKE_STRIP`` command,
if any.
The ``CMAKE_STRIP`` variable will contain the platform's ``strip`` utility, which
removes symbols information from generated binaries.
``sub/dir/test``
Runs the test step in the subdirectory, if any.
``sub/dir/package``
Runs the package step in the subdirectory, if any.
Fortran Support
^^^^^^^^^^^^^^^
The ``Ninja`` generator conditionally supports Fortran when the ``ninja``
tool is at least version 1.10 (which has the required features).
See Also
^^^^^^^^
The :generator:`Ninja Multi-Config` generator is similar to the ``Ninja``
generator, but generates multiple configurations at once.

43
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Visual Studio 10 2010.rst
View File

@ -1,43 +0,0 @@
Visual Studio 10 2010
---------------------
Generates Visual Studio 10 (VS 2010) project files.
For compatibility with CMake versions prior to 3.0, one may specify this
generator using the name ``Visual Studio 10`` without the year component.
Project Types
^^^^^^^^^^^^^
Only Visual C++ and C# projects may be generated. Other types of
projects (Database, Website, etc.) are not supported.
Platform Selection
^^^^^^^^^^^^^^^^^^
The default target platform name (architecture) is ``Win32``.
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :manual:`cmake(1)` ``-A`` option, to specify a target platform
name (architecture). For example:
* ``cmake -G "Visual Studio 10 2010" -A Win32``
* ``cmake -G "Visual Studio 10 2010" -A x64``
* ``cmake -G "Visual Studio 10 2010" -A Itanium``
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
``Visual Studio 10 2010 Win64``
Specify target platform ``x64``.
``Visual Studio 10 2010 IA64``
Specify target platform ``Itanium``.
Toolset Selection
^^^^^^^^^^^^^^^^^
The ``v100`` toolset that comes with Visual Studio 10 2010 is selected by
default. The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :manual:`cmake(1)` ``-T`` option, to specify another toolset.

48
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Visual Studio 11 2012.rst
View File

@ -1,48 +0,0 @@
Visual Studio 11 2012
---------------------
Generates Visual Studio 11 (VS 2012) project files.
For compatibility with CMake versions prior to 3.0, one may specify this
generator using the name "Visual Studio 11" without the year component.
Project Types
^^^^^^^^^^^^^
Only Visual C++ and C# projects may be generated. Other types of
projects (JavaScript, Database, Website, etc.) are not supported.
Platform Selection
^^^^^^^^^^^^^^^^^^
The default target platform name (architecture) is ``Win32``.
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :manual:`cmake(1)` ``-A`` option, to specify a target platform
name (architecture). For example:
* ``cmake -G "Visual Studio 11 2012" -A Win32``
* ``cmake -G "Visual Studio 11 2012" -A x64``
* ``cmake -G "Visual Studio 11 2012" -A ARM``
* ``cmake -G "Visual Studio 11 2012" -A <WinCE-SDK>``
(Specify a target platform matching a Windows CE SDK name.)
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
``Visual Studio 11 2012 Win64``
Specify target platform ``x64``.
``Visual Studio 11 2012 ARM``
Specify target platform ``ARM``.
``Visual Studio 11 2012 <WinCE-SDK>``
Specify target platform matching a Windows CE SDK name.
Toolset Selection
^^^^^^^^^^^^^^^^^
The ``v110`` toolset that comes with Visual Studio 11 2012 is selected by
default. The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :manual:`cmake(1)` ``-T`` option, to specify another toolset.

45
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Visual Studio 14 2015.rst
View File

@ -1,45 +0,0 @@
Visual Studio 14 2015
---------------------
Generates Visual Studio 14 (VS 2015) project files.
Project Types
^^^^^^^^^^^^^
Only Visual C++ and C# projects may be generated. Other types of
projects (JavaScript, Powershell, Python, etc.) are not supported.
Platform Selection
^^^^^^^^^^^^^^^^^^
The default target platform name (architecture) is ``Win32``.
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :manual:`cmake(1)` ``-A`` option, to specify a target platform
name (architecture). For example:
* ``cmake -G "Visual Studio 14 2015" -A Win32``
* ``cmake -G "Visual Studio 14 2015" -A x64``
* ``cmake -G "Visual Studio 14 2015" -A ARM``
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
``Visual Studio 14 2015 Win64``
Specify target platform ``x64``.
``Visual Studio 14 2015 ARM``
Specify target platform ``ARM``.
Toolset Selection
^^^^^^^^^^^^^^^^^
The ``v140`` toolset that comes with Visual Studio 14 2015 is selected by
default. The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :manual:`cmake(1)` ``-T`` option, to specify another toolset.
.. |VS_TOOLSET_HOST_ARCH_DEFAULT| replace::
By default this generator uses the 32-bit variant even on a 64-bit host.
.. include:: VS_TOOLSET_HOST_ARCH.txt

32
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Visual Studio 9 2008.rst
View File

@ -1,32 +0,0 @@
Visual Studio 9 2008
--------------------
Generates Visual Studio 9 2008 project files.
Platform Selection
^^^^^^^^^^^^^^^^^^
The default target platform name (architecture) is ``Win32``.
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :manual:`cmake(1)` ``-A`` option, to specify a target platform
name (architecture). For example:
* ``cmake -G "Visual Studio 9 2008" -A Win32``
* ``cmake -G "Visual Studio 9 2008" -A x64``
* ``cmake -G "Visual Studio 9 2008" -A Itanium``
* ``cmake -G "Visual Studio 9 2008" -A <WinCE-SDK>``
(Specify a target platform matching a Windows CE SDK name.)
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
``Visual Studio 9 2008 Win64``
Specify target platform ``x64``.
``Visual Studio 9 2008 IA64``
Specify target platform ``Itanium``.
``Visual Studio 9 2008 <WinCE-SDK>``
Specify target platform matching a Windows CE SDK name.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/generator/Xcode.rst
View File

@ -1,13 +0,0 @@
Xcode
-----
Generate Xcode project files.
This supports Xcode 5.0 and above.
Toolset Selection
^^^^^^^^^^^^^^^^^
By default Xcode is allowed to select its own default toolchain.
The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :manual:`cmake(1)` ``-T`` option, to specify another toolset.

BIN
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/VS-Choose-Arch.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

791
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-generator-expressions.7.rst
View File

@ -1,791 +0,0 @@
.. cmake-manual-description: CMake Generator Expressions
cmake-generator-expressions(7)
******************************
.. only:: html
.. contents::
Introduction
============
Generator expressions are evaluated during build system generation to produce
information specific to each build configuration.
Generator expressions are allowed in the context of many target properties,
such as :prop_tgt:`LINK_LIBRARIES`, :prop_tgt:`INCLUDE_DIRECTORIES`,
:prop_tgt:`COMPILE_DEFINITIONS` and others. They may also be used when using
commands to populate those properties, such as :command:`target_link_libraries`,
:command:`target_include_directories`, :command:`target_compile_definitions`
and others.
They enable conditional linking, conditional definitions used when compiling,
conditional include directories, and more. The conditions may be based on
the build configuration, target properties, platform information or any other
queryable information.
Generator expressions have the form ``$<...>``. To avoid confusion, this page
deviates from most of the CMake documentation in that it omits angular brackets
``<...>`` around placeholders like ``condition``, ``string``, ``target``,
among others.
Generator expressions can be nested, as shown in most of the examples below.
.. _`Boolean Generator Expressions`:
Boolean Generator Expressions
=============================
Boolean expressions evaluate to either ``0`` or ``1``.
They are typically used to construct the condition in a :ref:`conditional
generator expression<Conditional Generator Expressions>`.
Available boolean expressions are:
Logical Operators
-----------------
``$<BOOL:string>``
Converts ``string`` to ``0`` or ``1``. Evaluates to ``0`` if any of the
following is true:
* ``string`` is empty,
* ``string`` is a case-insensitive equal of
``0``, ``FALSE``, ``OFF``, ``N``, ``NO``, ``IGNORE``, or ``NOTFOUND``, or
* ``string`` ends in the suffix ``-NOTFOUND`` (case-sensitive).
Otherwise evaluates to ``1``.
``$<AND:conditions>``
where ``conditions`` is a comma-separated list of boolean expressions.
Evaluates to ``1`` if all conditions are ``1``.
Otherwise evaluates to ``0``.
``$<OR:conditions>``
where ``conditions`` is a comma-separated list of boolean expressions.
Evaluates to ``1`` if at least one of the conditions is ``1``.
Otherwise evaluates to ``0``.
``$<NOT:condition>``
``0`` if ``condition`` is ``1``, else ``1``.
String Comparisons
------------------
``$<STREQUAL:string1,string2>``
``1`` if ``string1`` and ``string2`` are equal, else ``0``.
The comparison is case-sensitive. For a case-insensitive comparison,
combine with a :ref:`string transforming generator expression
<String Transforming Generator Expressions>`,
.. code-block:: cmake
$<STREQUAL:$<UPPER_CASE:${foo}>,"BAR"> # "1" if ${foo} is any of "BAR", "Bar", "bar", ...
``$<EQUAL:value1,value2>``
``1`` if ``value1`` and ``value2`` are numerically equal, else ``0``.
``$<IN_LIST:string,list>``
``1`` if ``string`` is member of the semicolon-separated ``list``, else ``0``.
Uses case-sensitive comparisons.
``$<VERSION_LESS:v1,v2>``
``1`` if ``v1`` is a version less than ``v2``, else ``0``.
``$<VERSION_GREATER:v1,v2>``
``1`` if ``v1`` is a version greater than ``v2``, else ``0``.
``$<VERSION_EQUAL:v1,v2>``
``1`` if ``v1`` is the same version as ``v2``, else ``0``.
``$<VERSION_LESS_EQUAL:v1,v2>``
``1`` if ``v1`` is a version less than or equal to ``v2``, else ``0``.
``$<VERSION_GREATER_EQUAL:v1,v2>``
``1`` if ``v1`` is a version greater than or equal to ``v2``, else ``0``.
Variable Queries
----------------
``$<TARGET_EXISTS:target>``
``1`` if ``target`` exists, else ``0``.
``$<CONFIG:cfg>``
``1`` if config is ``cfg``, else ``0``. This is a case-insensitive comparison.
The mapping in :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` is also considered by
this expression when it is evaluated on a property on an :prop_tgt:`IMPORTED`
target.
``$<PLATFORM_ID:platform_ids>``
where ``platform_ids`` is a comma-separated list.
``1`` if the CMake's platform id matches any one of the entries in
``platform_ids``, otherwise ``0``.
See also the :variable:`CMAKE_SYSTEM_NAME` variable.
``$<C_COMPILER_ID:compiler_ids>``
where ``compiler_ids`` is a comma-separated list.
``1`` if the CMake's compiler id of the C compiler matches any one
of the entries in ``compiler_ids``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<CXX_COMPILER_ID:compiler_ids>``
where ``compiler_ids`` is a comma-separated list.
``1`` if the CMake's compiler id of the CXX compiler matches any one
of the entries in ``compiler_ids``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<CUDA_COMPILER_ID:compiler_ids>``
where ``compiler_ids`` is a comma-separated list.
``1`` if the CMake's compiler id of the CUDA compiler matches any one
of the entries in ``compiler_ids``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<OBJC_COMPILER_ID:compiler_ids>``
where ``compiler_ids`` is a comma-separated list.
``1`` if the CMake's compiler id of the Objective-C compiler matches any one
of the entries in ``compiler_ids``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<OBJCXX_COMPILER_ID:compiler_ids>``
where ``compiler_ids`` is a comma-separated list.
``1`` if the CMake's compiler id of the Objective-C++ compiler matches any one
of the entries in ``compiler_ids``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<Fortran_COMPILER_ID:compiler_ids>``
where ``compiler_ids`` is a comma-separated list.
``1`` if the CMake's compiler id of the Fortran compiler matches any one
of the entries in ``compiler_ids``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<C_COMPILER_VERSION:version>``
``1`` if the version of the C compiler matches ``version``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<CXX_COMPILER_VERSION:version>``
``1`` if the version of the CXX compiler matches ``version``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<CUDA_COMPILER_VERSION:version>``
``1`` if the version of the CXX compiler matches ``version``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<OBJC_COMPILER_VERSION:version>``
``1`` if the version of the OBJC compiler matches ``version``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<OBJCXX_COMPILER_VERSION:version>``
``1`` if the version of the OBJCXX compiler matches ``version``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<Fortran_COMPILER_VERSION:version>``
``1`` if the version of the Fortran compiler matches ``version``, otherwise ``0``.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<TARGET_POLICY:policy>``
``1`` if the ``policy`` was NEW when the 'head' target was created,
else ``0``. If the ``policy`` was not set, the warning message for the policy
will be emitted. This generator expression only works for a subset of
policies.
``$<COMPILE_FEATURES:features>``
where ``features`` is a comma-spearated list.
Evaluates to ``1`` if all of the ``features`` are available for the 'head'
target, and ``0`` otherwise. If this expression is used while evaluating
the link implementation of a target and if any dependency transitively
increases the required :prop_tgt:`C_STANDARD` or :prop_tgt:`CXX_STANDARD`
for the 'head' target, an error is reported. See the
:manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.
.. _`Boolean COMPILE_LANGUAGE Generator Expression`:
``$<COMPILE_LANG_AND_ID:language,compiler_ids>``
``1`` when the language used for compilation unit matches ``language`` and
the CMake's compiler id of the language compiler matches any one of the
entries in ``compiler_ids``, otherwise ``0``. This expression is a short form
for the combination of ``$<COMPILE_LANGUAGE:language>`` and
``$<LANG_COMPILER_ID:compiler_ids>``. This expression may be used to specify
compile options, compile definitions, and include directories for source files of a
particular language and compiler combination in a target. For example:
.. code-block:: cmake
add_executable(myapp main.cpp foo.c bar.cpp zot.cu)
target_compile_definitions(myapp
PRIVATE $<$<COMPILE_LANG_AND_ID:CXX,AppleClang,Clang>:COMPILING_CXX_WITH_CLANG>
$<$<COMPILE_LANG_AND_ID:CXX,Intel>:COMPILING_CXX_WITH_INTEL>
$<$<COMPILE_LANG_AND_ID:C,Clang>:COMPILING_C_WITH_CLANG>
)
This specifies the use of different compile definitions based on both
the compiler id and compilation language. This example will have a
``COMPILING_CXX_WITH_CLANG`` compile definition when Clang is the CXX
compiler, and ``COMPILING_CXX_WITH_INTEL`` when Intel is the CXX compiler.
Likewise when the C compiler is Clang it will only see the ``COMPILING_C_WITH_CLANG``
definition.
Without the ``COMPILE_LANG_AND_ID`` generator expression the same logic
would be expressed as:
.. code-block:: cmake
target_compile_definitions(myapp
PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:AppleClang,Clang>>:COMPILING_CXX_WITH_CLANG>
$<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Intel>>:COMPILING_CXX_WITH_INTEL>
$<$<AND:$<COMPILE_LANGUAGE:C>,$<C_COMPILER_ID:Clang>>:COMPILING_C_WITH_CLANG>
)
``$<COMPILE_LANGUAGE:languages>``
``1`` when the language used for compilation unit matches any of the entries
in ``languages``, otherwise ``0``. This expression may be used to specify
compile options, compile definitions, and include directories for source files of a
particular language in a target. For example:
.. code-block:: cmake
add_executable(myapp main.cpp foo.c bar.cpp zot.cu)
target_compile_options(myapp
PRIVATE $<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions>
)
target_compile_definitions(myapp
PRIVATE $<$<COMPILE_LANGUAGE:CXX>:COMPILING_CXX>
$<$<COMPILE_LANGUAGE:CUDA>:COMPILING_CUDA>
)
target_include_directories(myapp
PRIVATE $<$<COMPILE_LANGUAGE:CXX,CUDA>:/opt/foo/headers>
)
This specifies the use of the ``-fno-exceptions`` compile option,
``COMPILING_CXX`` compile definition, and ``cxx_headers`` include
directory for C++ only (compiler id checks elided). It also specifies
a ``COMPILING_CUDA`` compile definition for CUDA.
Note that with :ref:`Visual Studio Generators` and :generator:`Xcode` there
is no way to represent target-wide compile definitions or include directories
separately for ``C`` and ``CXX`` languages.
Also, with :ref:`Visual Studio Generators` there is no way to represent
target-wide flags separately for ``C`` and ``CXX`` languages. Under these
generators, expressions for both C and C++ sources will be evaluated
using ``CXX`` if there are any C++ sources and otherwise using ``C``.
A workaround is to create separate libraries for each source file language
instead:
.. code-block:: cmake
add_library(myapp_c foo.c)
add_library(myapp_cxx bar.cpp)
target_compile_options(myapp_cxx PUBLIC -fno-exceptions)
add_executable(myapp main.cpp)
target_link_libraries(myapp myapp_c myapp_cxx)
.. _`Boolean LINK_LANGUAGE Generator Expression`:
``$<LINK_LANG_AND_ID:language,compiler_ids>``
``1`` when the language used for link step matches ``language`` and the
CMake's compiler id of the language linker matches any one of the entries
in ``compiler_ids``, otherwise ``0``. This expression is a short form for the
combination of ``$<LINK_LANGUAGE:language>`` and
``$<LANG_COMPILER_ID:compiler_ids>``. This expression may be used to specify
link libraries, link options, link directories and link dependencies of a
particular language and linker combination in a target. For example:
.. code-block:: cmake
add_library(libC_Clang ...)
add_library(libCXX_Clang ...)
add_library(libC_Intel ...)
add_library(libCXX_Intel ...)
add_executable(myapp main.c)
if (CXX_CONFIG)
target_sources(myapp PRIVATE file.cxx)
endif()
target_link_libraries(myapp
PRIVATE $<$<LINK_LANG_AND_ID:CXX,Clang,AppleClang>:libCXX_Clang>
$<$<LINK_LANG_AND_ID:C,Clang,AppleClang>:libC_Clang>
$<$<LINK_LANG_AND_ID:CXX,Intel>:libCXX_Intel>
$<$<LINK_LANG_AND_ID:C,Intel>:libC_Intel>)
This specifies the use of different link libraries based on both the
compiler id and link language. This example will have target ``libCXX_Clang``
as link dependency when ``Clang`` or ``AppleClang`` is the ``CXX``
linker, and ``libCXX_Intel`` when ``Intel`` is the ``CXX`` linker.
Likewise when the ``C`` linker is ``Clang`` or ``AppleClang``, target
``libC_Clang`` will be added as link dependency and ``libC_Intel`` when
``Intel`` is the ``C`` linker.
See :ref:`the note related to
<Constraints LINK_LANGUAGE Generator Expression>`
``$<LINK_LANGUAGE:language>`` for constraints about the usage of this
generator expression.
``$<LINK_LANGUAGE:languages>``
``1`` when the language used for link step matches any of the entries
in ``languages``, otherwise ``0``. This expression may be used to specify
link libraries, link options, link directories and link dependencies of a
particular language in a target. For example:
.. code-block:: cmake
add_library(api_C ...)
add_library(api_CXX ...)
add_library(api INTERFACE)
target_link_options(api INTERFACE $<$<LINK_LANGUAGE:C>:-opt_c>
$<$<LINK_LANGUAGE:CXX>:-opt_cxx>)
target_link_libraries(api INTERFACE $<$<LINK_LANGUAGE:C>:api_C>
$<$<LINK_LANGUAGE:CXX>:api_CXX>)
add_executable(myapp1 main.c)
target_link_options(myapp1 PRIVATE api)
add_executable(myapp2 main.cpp)
target_link_options(myapp2 PRIVATE api)
This specifies to use the ``api`` target for linking targets ``myapp1`` and
``myapp2``. In practice, ``myapp1`` will link with target ``api_C`` and
option ``-opt_c`` because it will use ``C`` as link language. And ``myapp2``
will link with ``api_CXX`` and option ``-opt_cxx`` because ``CXX`` will be
the link language.
.. _`Constraints LINK_LANGUAGE Generator Expression`:
.. note::
To determine the link language of a target, it is required to collect,
transitively, all the targets which will be linked to it. So, for link
libraries properties, a double evaluation will be done. During the first
evaluation, ``$<LINK_LANGUAGE:..>`` expressions will always return ``0``.
The link language computed after this first pass will be used to do the
second pass. To avoid inconsistency, it is required that the second pass
do not change the link language. Moreover, to avoid unexpected
side-effects, it is required to specify complete entities as part of the
``$<LINK_LANGUAGE:..>`` expression. For example:
.. code-block:: cmake
add_library(lib STATIC file.cxx)
add_library(libother STATIC file.c)
# bad usage
add_executable(myapp1 main.c)
target_link_libraries(myapp1 PRIVATE lib$<$<LINK_LANGUAGE:C>:other>)
# correct usage
add_executable(myapp2 main.c)
target_link_libraries(myapp2 PRIVATE $<$<LINK_LANGUAGE:C>:libother>)
In this example, for ``myapp1``, the first pass will, unexpectedly,
determine that the link language is ``CXX`` because the evaluation of the
generator expression will be an empty string so ``myapp1`` will depends on
target ``lib`` which is ``C++``. On the contrary, for ``myapp2``, the first
evaluation will give ``C`` as link language, so the second pass will
correctly add target ``libother`` as link dependency.
``$<DEVICE_LINK:list>``
Returns the list if it is the device link step, an empty list otherwise.
The device link step is controlled by :prop_tgt:`CUDA_SEPARABLE_COMPILATION`
and :prop_tgt:`CUDA_RESOLVE_DEVICE_SYMBOLS` properties and
policy :policy:`CMP0105`. This expression can only be used to specify link
options.
``$<HOST_LINK:list>``
Returns the list if it is the normal link step, an empty list otherwise.
This expression is mainly useful when a device link step is also involved
(see ``$<DEVICE_LINK:list>`` generator expression). This expression can only
be used to specify link options.
String-Valued Generator Expressions
===================================
These expressions expand to some string.
For example,
.. code-block:: cmake
include_directories(/usr/include/$<CXX_COMPILER_ID>/)
expands to ``/usr/include/GNU/`` or ``/usr/include/Clang/`` etc, depending on
the compiler identifier.
String-valued expressions may also be combined with other expressions.
Here an example for a string-valued expression within a boolean expressions
within a conditional expression:
.. code-block:: cmake
$<$<VERSION_LESS:$<CXX_COMPILER_VERSION>,4.2.0>:OLD_COMPILER>
expands to ``OLD_COMPILER`` if the
:variable:`CMAKE_CXX_COMPILER_VERSION <CMAKE_<LANG>_COMPILER_VERSION>` is less
than 4.2.0.
And here two nested string-valued expressions:
.. code-block:: cmake
-I$<JOIN:$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>, -I>
generates a string of the entries in the :prop_tgt:`INCLUDE_DIRECTORIES` target
property with each entry preceded by ``-I``.
Expanding on the previous example, if one first wants to check if the
``INCLUDE_DIRECTORIES`` property is non-empty, then it is advisable to
introduce a helper variable to keep the code readable:
.. code-block:: cmake
set(prop "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>") # helper variable
$<$<BOOL:${prop}>:-I$<JOIN:${prop}, -I>>
The following string-valued generator expressions are available:
Escaped Characters
------------------
String literals to escape the special meaning a character would otherwise have:
``$<ANGLE-R>``
A literal ``>``. Used for example to compare strings that contain a ``>``.
``$<COMMA>``
A literal ``,``. Used for example to compare strings which contain a ``,``.
``$<SEMICOLON>``
A literal ``;``. Used to prevent list expansion on an argument with ``;``.
.. _`Conditional Generator Expressions`:
Conditional Expressions
-----------------------
Conditional generator expressions depend on a boolean condition
that must be ``0`` or ``1``.
``$<condition:true_string>``
Evaluates to ``true_string`` if ``condition`` is ``1``.
Otherwise evaluates to the empty string.
``$<IF:condition,true_string,false_string>``
Evaluates to ``true_string`` if ``condition`` is ``1``.
Otherwise evaluates to ``false_string``.
Typically, the ``condition`` is a :ref:`boolean generator expression
<Boolean Generator Expressions>`. For instance,
.. code-block:: cmake
$<$<CONFIG:Debug>:DEBUG_MODE>
expands to ``DEBUG_MODE`` when the ``Debug`` configuration is used, and
otherwise expands to the empty string.
.. _`String Transforming Generator Expressions`:
String Transformations
----------------------
``$<JOIN:list,string>``
Joins the list with the content of ``string``.
``$<REMOVE_DUPLICATES:list>``
Removes duplicated items in the given ``list``.
``$<FILTER:list,INCLUDE|EXCLUDE,regex>``
Includes or removes items from ``list`` that match the regular expression ``regex``.
``$<LOWER_CASE:string>``
Content of ``string`` converted to lower case.
``$<UPPER_CASE:string>``
Content of ``string`` converted to upper case.
``$<GENEX_EVAL:expr>``
Content of ``expr`` evaluated as a generator expression in the current
context. This enables consumption of generator expressions whose
evaluation results itself in generator expressions.
``$<TARGET_GENEX_EVAL:tgt,expr>``
Content of ``expr`` evaluated as a generator expression in the context of
``tgt`` target. This enables consumption of custom target properties that
themselves contain generator expressions.
Having the capability to evaluate generator expressions is very useful when
you want to manage custom properties supporting generator expressions.
For example:
.. code-block:: cmake
add_library(foo ...)
set_property(TARGET foo PROPERTY
CUSTOM_KEYS $<$<CONFIG:DEBUG>:FOO_EXTRA_THINGS>
)
add_custom_target(printFooKeys
COMMAND ${CMAKE_COMMAND} -E echo $<TARGET_PROPERTY:foo,CUSTOM_KEYS>
)
This naive implementation of the ``printFooKeys`` custom command is wrong
because ``CUSTOM_KEYS`` target property is not evaluated and the content
is passed as is (i.e. ``$<$<CONFIG:DEBUG>:FOO_EXTRA_THINGS>``).
To have the expected result (i.e. ``FOO_EXTRA_THINGS`` if config is
``Debug``), it is required to evaluate the output of
``$<TARGET_PROPERTY:foo,CUSTOM_KEYS>``:
.. code-block:: cmake
add_custom_target(printFooKeys
COMMAND ${CMAKE_COMMAND} -E
echo $<TARGET_GENEX_EVAL:foo,$<TARGET_PROPERTY:foo,CUSTOM_KEYS>>
)
Variable Queries
----------------
``$<CONFIG>``
Configuration name.
``$<CONFIGURATION>``
Configuration name. Deprecated since CMake 3.0. Use ``CONFIG`` instead.
``$<PLATFORM_ID>``
The current system's CMake platform id.
See also the :variable:`CMAKE_SYSTEM_NAME` variable.
``$<C_COMPILER_ID>``
The CMake's compiler id of the C compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<CXX_COMPILER_ID>``
The CMake's compiler id of the CXX compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<CUDA_COMPILER_ID>``
The CMake's compiler id of the CUDA compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<OBJC_COMPILER_ID>``
The CMake's compiler id of the OBJC compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<OBJCXX_COMPILER_ID>``
The CMake's compiler id of the OBJCXX compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<Fortran_COMPILER_ID>``
The CMake's compiler id of the Fortran compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_ID` variable.
``$<C_COMPILER_VERSION>``
The version of the C compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<CXX_COMPILER_VERSION>``
The version of the CXX compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<CUDA_COMPILER_VERSION>``
The version of the CUDA compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<OBJC_COMPILER_VERSION>``
The version of the OBJC compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<OBJCXX_COMPILER_VERSION>``
The version of the OBJCXX compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<Fortran_COMPILER_VERSION>``
The version of the Fortran compiler used.
See also the :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable.
``$<COMPILE_LANGUAGE>``
The compile language of source files when evaluating compile options.
See :ref:`the related boolean expression
<Boolean COMPILE_LANGUAGE Generator Expression>`
``$<COMPILE_LANGUAGE:language>``
for notes about the portability of this generator expression.
``$<LINK_LANGUAGE>``
The link language of target when evaluating link options.
See :ref:`the related boolean expression
<Boolean LINK_LANGUAGE Generator Expression>` ``$<LINK_LANGUAGE:language>``
for notes about the portability of this generator expression.
.. note::
This generator expression is not supported by the link libraries
properties to avoid side-effects due to the double evaluation of
these properties.
Target-Dependent Queries
------------------------
These queries refer to a target ``tgt``. This can be any runtime artifact,
namely:
* an executable target created by :command:`add_executable`
* a shared library target (``.so``, ``.dll`` but not their ``.lib`` import library)
created by :command:`add_library`
* a static library target created by :command:`add_library`
In the following, "the ``tgt`` filename" means the name of the ``tgt``
binary file. This has to be distinguished from "the target name",
which is just the string ``tgt``.
``$<TARGET_NAME_IF_EXISTS:tgt>``
The target name ``tgt`` if the target exists, an empty string otherwise.
``$<TARGET_FILE:tgt>``
Full path to the ``tgt`` binary file.
``$<TARGET_FILE_BASE_NAME:tgt>``
Base name of ``tgt``, i.e. ``$<TARGET_FILE_NAME:tgt>`` without prefix and
suffix.
For example, if the ``tgt`` filename is ``libbase.so``, the base name is ``base``.
See also the :prop_tgt:`OUTPUT_NAME`, :prop_tgt:`ARCHIVE_OUTPUT_NAME`,
:prop_tgt:`LIBRARY_OUTPUT_NAME` and :prop_tgt:`RUNTIME_OUTPUT_NAME`
target properties and their configuration specific variants
:prop_tgt:`OUTPUT_NAME_<CONFIG>`, :prop_tgt:`ARCHIVE_OUTPUT_NAME_<CONFIG>`,
:prop_tgt:`LIBRARY_OUTPUT_NAME_<CONFIG>` and
:prop_tgt:`RUNTIME_OUTPUT_NAME_<CONFIG>`.
The :prop_tgt:`<CONFIG>_POSTFIX` and :prop_tgt:`DEBUG_POSTFIX` target
properties can also be considered.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_FILE_PREFIX:tgt>``
Prefix of the ``tgt`` filename (such as ``lib``).
See also the :prop_tgt:`PREFIX` target property.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_FILE_SUFFIX:tgt>``
Suffix of the ``tgt`` filename (extension such as ``.so`` or ``.exe``).
See also the :prop_tgt:`SUFFIX` target property.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_FILE_NAME:tgt>``
The ``tgt`` filename.
``$<TARGET_FILE_DIR:tgt>``
Directory of the ``tgt`` binary file.
``$<TARGET_LINKER_FILE:tgt>``
File used when linking to the ``tgt`` target. This will usually
be the library that ``tgt`` represents (``.a``, ``.lib``, ``.so``),
but for a shared library on DLL platforms, it would be the ``.lib``
import library associated with the DLL.
``$<TARGET_LINKER_FILE_BASE_NAME:tgt>``
Base name of file used to link the target ``tgt``, i.e.
``$<TARGET_LINKER_FILE_NAME:tgt>`` without prefix and suffix. For example,
if target file name is ``libbase.a``, the base name is ``base``.
See also the :prop_tgt:`OUTPUT_NAME`, :prop_tgt:`ARCHIVE_OUTPUT_NAME`,
and :prop_tgt:`LIBRARY_OUTPUT_NAME` target properties and their configuration
specific variants :prop_tgt:`OUTPUT_NAME_<CONFIG>`,
:prop_tgt:`ARCHIVE_OUTPUT_NAME_<CONFIG>` and
:prop_tgt:`LIBRARY_OUTPUT_NAME_<CONFIG>`.
The :prop_tgt:`<CONFIG>_POSTFIX` and :prop_tgt:`DEBUG_POSTFIX` target
properties can also be considered.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_LINKER_FILE_PREFIX:tgt>``
Prefix of file used to link target ``tgt``.
See also the :prop_tgt:`PREFIX` and :prop_tgt:`IMPORT_PREFIX` target
properties.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_LINKER_FILE_SUFFIX:tgt>``
Suffix of file used to link where ``tgt`` is the name of a target.
The suffix corresponds to the file extension (such as ".so" or ".lib").
See also the :prop_tgt:`SUFFIX` and :prop_tgt:`IMPORT_SUFFIX` target
properties.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_LINKER_FILE_NAME:tgt>``
Name of file used to link target ``tgt``.
``$<TARGET_LINKER_FILE_DIR:tgt>``
Directory of file used to link target ``tgt``.
``$<TARGET_SONAME_FILE:tgt>``
File with soname (``.so.3``) where ``tgt`` is the name of a target.
``$<TARGET_SONAME_FILE_NAME:tgt>``
Name of file with soname (``.so.3``).
``$<TARGET_SONAME_FILE_DIR:tgt>``
Directory of with soname (``.so.3``).
``$<TARGET_PDB_FILE:tgt>``
Full path to the linker generated program database file (.pdb)
where ``tgt`` is the name of a target.
See also the :prop_tgt:`PDB_NAME` and :prop_tgt:`PDB_OUTPUT_DIRECTORY`
target properties and their configuration specific variants
:prop_tgt:`PDB_NAME_<CONFIG>` and :prop_tgt:`PDB_OUTPUT_DIRECTORY_<CONFIG>`.
``$<TARGET_PDB_FILE_BASE_NAME:tgt>``
Base name of the linker generated program database file (.pdb)
where ``tgt`` is the name of a target.
The base name corresponds to the target PDB file name (see
``$<TARGET_PDB_FILE_NAME:tgt>``) without prefix and suffix. For example,
if target file name is ``base.pdb``, the base name is ``base``.
See also the :prop_tgt:`PDB_NAME` target property and its configuration
specific variant :prop_tgt:`PDB_NAME_<CONFIG>`.
The :prop_tgt:`<CONFIG>_POSTFIX` and :prop_tgt:`DEBUG_POSTFIX` target
properties can also be considered.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_PDB_FILE_NAME:tgt>``
Name of the linker generated program database file (.pdb).
``$<TARGET_PDB_FILE_DIR:tgt>``
Directory of the linker generated program database file (.pdb).
``$<TARGET_BUNDLE_DIR:tgt>``
Full path to the bundle directory (``my.app``, ``my.framework``, or
``my.bundle``) where ``tgt`` is the name of a target.
``$<TARGET_BUNDLE_CONTENT_DIR:tgt>``
Full path to the bundle content directory where ``tgt`` is the name of a
target. For the macOS SDK it leads to ``my.app/Contents``, ``my.framework``,
or ``my.bundle/Contents``. For all other SDKs (e.g. iOS) it leads to
``my.app``, ``my.framework``, or ``my.bundle`` due to the flat bundle
structure.
``$<TARGET_PROPERTY:tgt,prop>``
Value of the property ``prop`` on the target ``tgt``.
Note that ``tgt`` is not added as a dependency of the target this
expression is evaluated on.
``$<TARGET_PROPERTY:prop>``
Value of the property ``prop`` on the target for which the expression
is being evaluated. Note that for generator expressions in
:ref:`Target Usage Requirements` this is the consuming target rather
than the target specifying the requirement.
``$<INSTALL_PREFIX>``
Content of the install prefix when the target is exported via
:command:`install(EXPORT)`, or when evaluated in
:prop_tgt:`INSTALL_NAME_DIR`, and empty otherwise.
Output-Related Expressions
--------------------------
``$<TARGET_NAME:...>``
Marks ``...`` as being the name of a target. This is required if exporting
targets to multiple dependent export sets. The ``...`` must be a literal
name of a target- it may not contain generator expressions.
``$<LINK_ONLY:...>``
Content of ``...`` except when evaluated in a link interface while
propagating :ref:`Target Usage Requirements`, in which case it is the
empty string.
Intended for use only in an :prop_tgt:`INTERFACE_LINK_LIBRARIES` target
property, perhaps via the :command:`target_link_libraries` command,
to specify private link dependencies without other usage requirements.
``$<INSTALL_INTERFACE:...>``
Content of ``...`` when the property is exported using :command:`install(EXPORT)`,
and empty otherwise.
``$<BUILD_INTERFACE:...>``
Content of ``...`` when the property is exported using :command:`export`, or
when the target is used by another target in the same buildsystem. Expands to
the empty string otherwise.
``$<MAKE_C_IDENTIFIER:...>``
Content of ``...`` converted to a C identifier. The conversion follows the
same behavior as :command:`string(MAKE_C_IDENTIFIER)`.
``$<TARGET_OBJECTS:objLib>``
List of objects resulting from build of ``objLib``.
``$<SHELL_PATH:...>``
Content of ``...`` converted to shell path style. For example, slashes are
converted to backslashes in Windows shells and drive letters are converted
to posix paths in MSYS shells. The ``...`` must be an absolute path.
The ``...`` may be a :ref:`semicolon-separated list <CMake Language Lists>`
of paths, in which case each path is converted individually and a result
list is generated using the shell path separator (``:`` on POSIX and
``;`` on Windows). Be sure to enclose the argument containing this genex
in double quotes in CMake source code so that ``;`` does not split arguments.
Debugging
=========
Since generator expressions are evaluated during generation of the buildsystem,
and not during processing of ``CMakeLists.txt`` files, it is not possible to
inspect their result with the :command:`message()` command.
One possible way to generate debug messages is to add a custom target,
.. code-block:: cmake
add_custom_target(genexdebug COMMAND ${CMAKE_COMMAND} -E echo "$<...>")
The shell command ``make genexdebug`` (invoked after execution of ``cmake``)
would then print the result of ``$<...>``.
Another way is to write debug messages to a file:
.. code-block:: cmake
file(GENERATE OUTPUT filename CONTENT "$<...>")

744
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-server.7.rst
View File

@ -1,744 +0,0 @@
.. cmake-manual-description: CMake Server
cmake-server(7)
***************
.. only:: html
.. contents::
.. deprecated:: 3.15
This will be removed from a future version of CMake.
Clients should use the :manual:`cmake-file-api(7)` instead.
Introduction
============
:manual:`cmake(1)` is capable of providing semantic information about
CMake code it executes to generate a buildsystem. If executed with
the ``-E server`` command line options, it starts in a long running mode
and allows a client to request the available information via a JSON protocol.
The protocol is designed to be useful to IDEs, refactoring tools, and
other tools which have a need to understand the buildsystem in entirety.
A single :manual:`cmake-buildsystem(7)` may describe buildsystem contents
and build properties which differ based on
:manual:`generation-time context <cmake-generator-expressions(7)>`
including:
* The Platform (eg, Windows, APPLE, Linux).
* The build configuration (eg, Debug, Release, Coverage).
* The Compiler (eg, MSVC, GCC, Clang) and compiler version.
* The language of the source files compiled.
* Available compile features (eg CXX variadic templates).
* CMake policies.
The protocol aims to provide information to tooling to satisfy several
needs:
#. Provide a complete and easily parsed source of all information relevant
to the tooling as it relates to the source code. There should be no need
for tooling to parse generated buildsystems to access include directories
or compile definitions for example.
#. Semantic information about the CMake buildsystem itself.
#. Provide a stable interface for reading the information in the CMake cache.
#. Information for determining when cmake needs to be re-run as a result of
file changes.
Operation
=========
Start :manual:`cmake(1)` in the server command mode, supplying the path to
the build directory to process::
cmake -E server (--debug|--pipe=<NAMED_PIPE>)
The server will communicate using stdin/stdout (with the ``--debug`` parameter)
or using a named pipe (with the ``--pipe=<NAMED_PIPE>`` parameter). Note
that "named pipe" refers to a local domain socket on Unix and to a named pipe
on Windows.
When connecting to the server (via named pipe or by starting it in ``--debug``
mode), the server will reply with a hello message::
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]
Messages sent to and from the process are wrapped in magic strings::
[== "CMake Server" ==[
{
... some JSON message ...
}
]== "CMake Server" ==]
The server is now ready to accept further requests via the named pipe
or stdin.
Debugging
=========
CMake server mode can be asked to provide statistics on execution times, etc.
or to dump a copy of the response into a file. This is done passing a "debug"
JSON object as a child of the request.
The debug object supports the "showStats" key, which takes a boolean and makes
the server mode return a "zzzDebug" object with stats as part of its response.
"dumpToFile" takes a string value and will cause the cmake server to copy
the response into the given filename.
This is a response from the cmake server with "showStats" set to true::
[== "CMake Server" ==[
{
"cookie":"",
"errorMessage":"Waiting for type \"handshake\".",
"inReplyTo":"unknown",
"type":"error",
"zzzDebug": {
"dumpFile":"/tmp/error.txt",
"jsonSerialization":0.011016,
"size":111,
"totalTime":0.025995
}
}
]== "CMake Server" ==]
The server has made a copy of this response into the file /tmp/error.txt and
took 0.011 seconds to turn the JSON response into a string, and it took 0.025
seconds to process the request in total. The reply has a size of 111 bytes.
Protocol API
============
General Message Layout
----------------------
All messages need to have a "type" value, which identifies the type of
message that is passed back or forth. E.g. the initial message sent by the
server is of type "hello". Messages without a type will generate an response
of type "error".
All requests sent to the server may contain a "cookie" value. This value
will he handed back unchanged in all responses triggered by the request.
All responses will contain a value "inReplyTo", which may be empty in
case of parse errors, but will contain the type of the request message
in all other cases.
Type "reply"
^^^^^^^^^^^^
This type is used by the server to reply to requests.
The message may -- depending on the type of the original request --
contain values.
Example::
[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]
Type "error"
^^^^^^^^^^^^
This type is used to return an error condition to the client. It will
contain an "errorMessage".
Example::
[== "CMake Server" ==[
{"cookie":"","errorMessage":"Protocol version not supported.","inReplyTo":"handshake","type":"error"}
]== "CMake Server" ==]
Type "progress"
^^^^^^^^^^^^^^^
When the server is busy for a long time, it is polite to send back replies of
type "progress" to the client. These will contain a "progressMessage" with a
string describing the action currently taking place as well as
"progressMinimum", "progressMaximum" and "progressCurrent" with integer values
describing the range of progress.
Messages of type "progress" will be followed by more "progress" messages or with
a message of type "reply" or "error" that complete the request.
"progress" messages may not be emitted after the "reply" or "error" message for
the request that triggered the responses was delivered.
Type "message"
^^^^^^^^^^^^^^
A message is triggered when the server processes a request and produces some
form of output that should be displayed to the user. A Message has a "message"
with the actual text to display as well as a "title" with a suggested dialog
box title.
Example::
[== "CMake Server" ==[
{"cookie":"","message":"Something happened.","title":"Title Text","inReplyTo":"handshake","type":"message"}
]== "CMake Server" ==]
Type "signal"
^^^^^^^^^^^^^
The server can send signals when it detects changes in the system state. Signals
are of type "signal", have an empty "cookie" and "inReplyTo" field and always
have a "name" set to show which signal was sent.
Specific Signals
----------------
The cmake server may sent signals with the following names:
"dirty" Signal
^^^^^^^^^^^^^^
The "dirty" signal is sent whenever the server determines that the configuration
of the project is no longer up-to-date. This happens when any of the files that have
an influence on the build system is changed.
The "dirty" signal may look like this::
[== "CMake Server" ==[
{
"cookie":"",
"inReplyTo":"",
"name":"dirty",
"type":"signal"}
]== "CMake Server" ==]
"fileChange" Signal
^^^^^^^^^^^^^^^^^^^
The "fileChange" signal is sent whenever a watched file is changed. It contains
the "path" that has changed and a list of "properties" with the kind of change
that was detected. Possible changes are "change" and "rename".
The "fileChange" signal looks like this::
[== "CMake Server" ==[
{
"cookie":"",
"inReplyTo":"",
"name":"fileChange",
"path":"/absolute/CMakeLists.txt",
"properties":["change"],
"type":"signal"}
]== "CMake Server" ==]
Specific Message Types
----------------------
Type "hello"
^^^^^^^^^^^^
The initial message send by the cmake server on startup is of type "hello".
This is the only message ever sent by the server that is not of type "reply",
"progress" or "error".
It will contain "supportedProtocolVersions" with an array of server protocol
versions supported by the cmake server. These are JSON objects with "major" and
"minor" keys containing non-negative integer values. Some versions may be marked
as experimental. These will contain the "isExperimental" key set to true. Enabling
these requires a special command line argument when starting the cmake server mode.
Within a "major" version all "minor" versions are fully backwards compatible.
New "minor" versions may introduce functionality in such a way that existing
clients of the same "major" version will continue to work, provided they
ignore keys in the output that they do not know about.
Example::
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":0,"minor":1}],"type":"hello"}
]== "CMake Server" ==]
Type "handshake"
^^^^^^^^^^^^^^^^
The first request that the client may send to the server is of type "handshake".
This request needs to pass one of the "supportedProtocolVersions" of the "hello"
type response received earlier back to the server in the "protocolVersion" field.
Giving the "major" version of the requested protocol version will make the server
use the latest minor version of that protocol. Use this if you do not explicitly
need to depend on a specific minor version.
Protocol version 1.0 requires the following attributes to be set:
* "sourceDirectory" with a path to the sources
* "buildDirectory" with a path to the build directory
* "generator" with the generator name
* "extraGenerator" (optional!) with the extra generator to be used
* "platform" with the generator platform (if supported by the generator)
* "toolset" with the generator toolset (if supported by the generator)
Protocol version 1.2 makes all but the build directory optional, provided
there is a valid cache in the build directory that contains all the other
information already.
Example::
[== "CMake Server" ==[
{"cookie":"zimtstern","type":"handshake","protocolVersion":{"major":0},
"sourceDirectory":"/home/code/cmake", "buildDirectory":"/tmp/testbuild",
"generator":"Ninja"}
]== "CMake Server" ==]
which will result in a response type "reply"::
[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]
indicating that the server is ready for action.
Type "globalSettings"
^^^^^^^^^^^^^^^^^^^^^
This request can be sent after the initial handshake. It will return a
JSON structure with information on cmake state.
Example::
[== "CMake Server" ==[
{"type":"globalSettings"}
]== "CMake Server" ==]
which will result in a response type "reply"::
[== "CMake Server" ==[
{
"buildDirectory": "/tmp/test-build",
"capabilities": {
"generators": [
{
"extraGenerators": [],
"name": "Watcom WMake",
"platformSupport": false,
"toolsetSupport": false
},
<...>
],
"serverMode": false,
"version": {
"isDirty": false,
"major": 3,
"minor": 6,
"patch": 20160830,
"string": "3.6.20160830-gd6abad",
"suffix": "gd6abad"
}
},
"checkSystemVars": false,
"cookie": "",
"extraGenerator": "",
"generator": "Ninja",
"debugOutput": false,
"inReplyTo": "globalSettings",
"sourceDirectory": "/home/code/cmake",
"trace": false,
"traceExpand": false,
"type": "reply",
"warnUninitialized": false,
"warnUnused": false,
"warnUnusedCli": true
}
]== "CMake Server" ==]
Type "setGlobalSettings"
^^^^^^^^^^^^^^^^^^^^^^^^
This request can be sent to change the global settings attributes. Unknown
attributes are going to be ignored. Read-only attributes reported by
"globalSettings" are all capabilities, buildDirectory, generator,
extraGenerator and sourceDirectory. Any attempt to set these will be ignored,
too.
All other settings will be changed.
The server will respond with an empty reply message or an error.
Example::
[== "CMake Server" ==[
{"type":"setGlobalSettings","debugOutput":true}
]== "CMake Server" ==]
CMake will reply to this with::
[== "CMake Server" ==[
{"inReplyTo":"setGlobalSettings","type":"reply"}
]== "CMake Server" ==]
Type "configure"
^^^^^^^^^^^^^^^^
This request will configure a project for build.
To configure a build directory already containing cmake files, it is enough to
set "buildDirectory" via "setGlobalSettings". To create a fresh build directory
you also need to set "currentGenerator" and "sourceDirectory" via "setGlobalSettings"
in addition to "buildDirectory".
You may a list of strings to "configure" via the "cacheArguments" key. These
strings will be interpreted similar to command line arguments related to
cache handling that are passed to the cmake command line client.
Example::
[== "CMake Server" ==[
{"type":"configure", "cacheArguments":["-Dsomething=else"]}
]== "CMake Server" ==]
CMake will reply like this (after reporting progress for some time)::
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","type":"reply"}
]== "CMake Server" ==]
Type "compute"
^^^^^^^^^^^^^^
This request will generate build system files in the build directory and
is only available after a project was successfully "configure"d.
Example::
[== "CMake Server" ==[
{"type":"compute"}
]== "CMake Server" ==]
CMake will reply (after reporting progress information)::
[== "CMake Server" ==[
{"cookie":"","inReplyTo":"compute","type":"reply"}
]== "CMake Server" ==]
Type "codemodel"
^^^^^^^^^^^^^^^^
The "codemodel" request can be used after a project was "compute"d successfully.
It will list the complete project structure as it is known to cmake.
The reply will contain a key "configurations", which will contain a list of
configuration objects. Configuration objects are used to destinquish between
different configurations the build directory might have enabled. While most
generators only support one configuration, others might support several.
Each configuration object can have the following keys:
"name"
contains the name of the configuration. The name may be empty.
"projects"
contains a list of project objects, one for each build project.
Project objects define one (sub-)project defined in the cmake build system.
Each project object can have the following keys:
"name"
contains the (sub-)projects name.
"minimumCMakeVersion"
contains the minimum cmake version allowed for this project, null if the
project doesn't specify one.
"hasInstallRule"
true if the project contains any install rules, false otherwise.
"sourceDirectory"
contains the current source directory
"buildDirectory"
contains the current build directory.
"targets"
contains a list of build system target objects.
Target objects define individual build targets for a certain configuration.
Each target object can have the following keys:
"name"
contains the name of the target.
"type"
defines the type of build of the target. Possible values are
"STATIC_LIBRARY", "MODULE_LIBRARY", "SHARED_LIBRARY", "OBJECT_LIBRARY",
"EXECUTABLE", "UTILITY" and "INTERFACE_LIBRARY".
"fullName"
contains the full name of the build result (incl. extensions, etc.).
"sourceDirectory"
contains the current source directory.
"buildDirectory"
contains the current build directory.
"isGeneratorProvided"
true if the target is auto-created by a generator, false otherwise
"hasInstallRule"
true if the target contains any install rules, false otherwise.
"installPaths"
full path to the destination directories defined by target install rules.
"artifacts"
with a list of build artifacts. The list is sorted with the most
important artifacts first (e.g. a .DLL file is listed before a
.PDB file on windows).
"linkerLanguage"
contains the language of the linker used to produce the artifact.
"linkLibraries"
with a list of libraries to link to. This value is encoded in the
system's native shell format.
"linkFlags"
with a list of flags to pass to the linker. This value is encoded in
the system's native shell format.
"linkLanguageFlags"
with the flags for a compiler using the linkerLanguage. This value is
encoded in the system's native shell format.
"frameworkPath"
with the framework path (on Apple computers). This value is encoded
in the system's native shell format.
"linkPath"
with the link path. This value is encoded in the system's native shell
format.
"sysroot"
with the sysroot path.
"fileGroups"
contains the source files making up the target.
FileGroups are used to group sources using similar settings together.
Each fileGroup object may contain the following keys:
"language"
contains the programming language used by all files in the group.
"compileFlags"
with a string containing all the flags passed to the compiler
when building any of the files in this group. This value is encoded in
the system's native shell format.
"includePath"
with a list of include paths. Each include path is an object
containing a "path" with the actual include path and "isSystem" with a bool
value informing whether this is a normal include or a system include. This
value is encoded in the system's native shell format.
"defines"
with a list of defines in the form "SOMEVALUE" or "SOMEVALUE=42". This
value is encoded in the system's native shell format.
"sources"
with a list of source files.
All file paths in the fileGroup are either absolute or relative to the
sourceDirectory of the target.
Example::
[== "CMake Server" ==[
{"type":"codemodel"}
]== "CMake Server" ==]
CMake will reply::
[== "CMake Server" ==[
{
"configurations": [
{
"name": "",
"projects": [
{
"buildDirectory": "/tmp/build/Source/CursesDialog/form",
"name": "CMAKE_FORM",
"sourceDirectory": "/home/code/src/cmake/Source/CursesDialog/form",
"targets": [
{
"artifacts": [ "/tmp/build/Source/CursesDialog/form/libcmForm.a" ],
"buildDirectory": "/tmp/build/Source/CursesDialog/form",
"fileGroups": [
{
"compileFlags": " -std=gnu11",
"defines": [ "CURL_STATICLIB", "LIBARCHIVE_STATIC" ],
"includePath": [ { "path": "/tmp/build/Utilities" }, <...> ],
"isGenerated": false,
"language": "C",
"sources": [ "fld_arg.c", <...> ]
}
],
"fullName": "libcmForm.a",
"linkerLanguage": "C",
"name": "cmForm",
"sourceDirectory": "/home/code/src/cmake/Source/CursesDialog/form",
"type": "STATIC_LIBRARY"
}
]
},
<...>
]
}
],
"cookie": "",
"inReplyTo": "codemodel",
"type": "reply"
}
]== "CMake Server" ==]
Type "ctestInfo"
^^^^^^^^^^^^^^^^
The "ctestInfo" request can be used after a project was "compute"d successfully.
It will list the complete project test structure as it is known to cmake.
The reply will contain a key "configurations", which will contain a list of
configuration objects. Configuration objects are used to destinquish between
different configurations the build directory might have enabled. While most
generators only support one configuration, others might support several.
Each configuration object can have the following keys:
"name"
contains the name of the configuration. The name may be empty.
"projects"
contains a list of project objects, one for each build project.
Project objects define one (sub-)project defined in the cmake build system.
Each project object can have the following keys:
"name"
contains the (sub-)projects name.
"ctestInfo"
contains a list of test objects.
Each test object can have the following keys:
"ctestName"
contains the name of the test.
"ctestCommand"
contains the test command.
"properties"
contains a list of test property objects.
Each test property object can have the following keys:
"key"
contains the test property key.
"value"
contains the test property value.
Type "cmakeInputs"
^^^^^^^^^^^^^^^^^^
The "cmakeInputs" requests will report files used by CMake as part
of the build system itself.
This request is only available after a project was successfully
"configure"d.
Example::
[== "CMake Server" ==[
{"type":"cmakeInputs"}
]== "CMake Server" ==]
CMake will reply with the following information::
[== "CMake Server" ==[
{"buildFiles":
[
{"isCMake":true,"isTemporary":false,"sources":["/usr/lib/cmake/...", ... ]},
{"isCMake":false,"isTemporary":false,"sources":["CMakeLists.txt", ...]},
{"isCMake":false,"isTemporary":true,"sources":["/tmp/build/CMakeFiles/...", ...]}
],
"cmakeRootDirectory":"/usr/lib/cmake",
"sourceDirectory":"/home/code/src/cmake",
"cookie":"",
"inReplyTo":"cmakeInputs",
"type":"reply"
}
]== "CMake Server" ==]
All file names are either relative to the top level source directory or
absolute.
The list of files which "isCMake" set to true are part of the cmake installation.
The list of files witch "isTemporary" set to true are part of the build directory
and will not survive the build directory getting cleaned out.
Type "cache"
^^^^^^^^^^^^
The "cache" request will list the cached configuration values.
Example::
[== "CMake Server" ==[
{"type":"cache"}
]== "CMake Server" ==]
CMake will respond with the following output::
[== "CMake Server" ==[
{
"cookie":"","inReplyTo":"cache","type":"reply",
"cache":
[
{
"key":"SOMEVALUE",
"properties":
{
"ADVANCED":"1",
"HELPSTRING":"This is not helpful"
}
"type":"STRING",
"value":"TEST"}
]
}
]== "CMake Server" ==]
The output can be limited to a list of keys by passing an array of key names
to the "keys" optional field of the "cache" request.
Type "fileSystemWatchers"
^^^^^^^^^^^^^^^^^^^^^^^^^
The server can watch the filesystem for changes. The "fileSystemWatchers"
command will report on the files and directories watched.
Example::
[== "CMake Server" ==[
{"type":"fileSystemWatchers"}
]== "CMake Server" ==]
CMake will respond with the following output::
[== "CMake Server" ==[
{
"cookie":"","inReplyTo":"fileSystemWatchers","type":"reply",
"watchedFiles": [ "/absolute/path" ],
"watchedDirectories": [ "/absolute" ]
}
]== "CMake Server" ==]

804
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake.1.rst
View File

@ -1,804 +0,0 @@
.. cmake-manual-description: CMake Command-Line Reference
cmake(1)
********
Synopsis
========
.. parsed-literal::
`Generate a Project Buildsystem`_
cmake [<options>] <path-to-source>
cmake [<options>] <path-to-existing-build>
cmake [<options>] -S <path-to-source> -B <path-to-build>
`Build a Project`_
cmake --build <dir> [<options>] [-- <build-tool-options>]
`Install a Project`_
cmake --install <dir> [<options>]
`Open a Project`_
cmake --open <dir>
`Run a Script`_
cmake [{-D <var>=<value>}...] -P <cmake-script-file>
`Run a Command-Line Tool`_
cmake -E <command> [<options>]
`Run the Find-Package Tool`_
cmake --find-package [<options>]
`View Help`_
cmake --help[-<topic>]
Description
===========
The **cmake** executable is the command-line interface of the cross-platform
buildsystem generator CMake. The above `Synopsis`_ lists various actions
the tool can perform as described in sections below.
To build a software project with CMake, `Generate a Project Buildsystem`_.
Optionally use **cmake** to `Build a Project`_, `Install a Project`_ or just
run the corresponding build tool (e.g. ``make``) directly. **cmake** can also
be used to `View Help`_.
The other actions are meant for use by software developers writing
scripts in the :manual:`CMake language <cmake-language(7)>` to support
their builds.
For graphical user interfaces that may be used in place of **cmake**,
see :manual:`ccmake <ccmake(1)>` and :manual:`cmake-gui <cmake-gui(1)>`.
For command-line interfaces to the CMake testing and packaging facilities,
see :manual:`ctest <ctest(1)>` and :manual:`cpack <cpack(1)>`.
For more information on CMake at large, `see also`_ the links at the end
of this manual.
Introduction to CMake Buildsystems
==================================
A *buildsystem* describes how to build a project's executables and libraries
from its source code using a *build tool* to automate the process. For
example, a buildsystem may be a ``Makefile`` for use with a command-line
``make`` tool or a project file for an Integrated Development Environment
(IDE). In order to avoid maintaining multiple such buildsystems, a project
may specify its buildsystem abstractly using files written in the
:manual:`CMake language <cmake-language(7)>`. From these files CMake
generates a preferred buildsystem locally for each user through a backend
called a *generator*.
To generate a buildsystem with CMake, the following must be selected:
Source Tree
The top-level directory containing source files provided by the project.
The project specifies its buildsystem using files as described in the
:manual:`cmake-language(7)` manual, starting with a top-level file named
``CMakeLists.txt``. These files specify build targets and their
dependencies as described in the :manual:`cmake-buildsystem(7)` manual.
Build Tree
The top-level directory in which buildsystem files and build output
artifacts (e.g. executables and libraries) are to be stored.
CMake will write a ``CMakeCache.txt`` file to identify the directory
as a build tree and store persistent information such as buildsystem
configuration options.
To maintain a pristine source tree, perform an *out-of-source* build
by using a separate dedicated build tree. An *in-source* build in
which the build tree is placed in the same directory as the source
tree is also supported, but discouraged.
Generator
This chooses the kind of buildsystem to generate. See the
:manual:`cmake-generators(7)` manual for documentation of all generators.
Run ``cmake --help`` to see a list of generators available locally.
Optionally use the ``-G`` option below to specify a generator, or simply
accept the default CMake chooses for the current platform.
When using one of the :ref:`Command-Line Build Tool Generators`
CMake expects that the environment needed by the compiler toolchain
is already configured in the shell. When using one of the
:ref:`IDE Build Tool Generators`, no particular environment is needed.
Generate a Project Buildsystem
==============================
Run CMake with one of the following command signatures to specify the
source and build trees and generate a buildsystem:
``cmake [<options>] <path-to-source>``
Uses the current working directory as the build tree, and
``<path-to-source>`` as the source tree. The specified path may
be absolute or relative to the current working directory.
The source tree must contain a ``CMakeLists.txt`` file and must
*not* contain a ``CMakeCache.txt`` file because the latter
identifies an existing build tree. For example:
.. code-block:: console
$ mkdir build ; cd build
$ cmake ../src
``cmake [<options>] <path-to-existing-build>``
Uses ``<path-to-existing-build>`` as the build tree, and loads the
path to the source tree from its ``CMakeCache.txt`` file, which must
have already been generated by a previous run of CMake. The specified
path may be absolute or relative to the current working directory.
For example:
.. code-block:: console
$ cd build
$ cmake .
``cmake [<options>] -S <path-to-source> -B <path-to-build>``
Uses ``<path-to-build>`` as the build tree and ``<path-to-source>``
as the source tree. The specified paths may be absolute or relative
to the current working directory. The source tree must contain a
``CMakeLists.txt`` file. The build tree will be created automatically
if it does not already exist. For example:
.. code-block:: console
$ cmake -S src -B build
In all cases the ``<options>`` may be zero or more of the `Options`_ below.
After generating a buildsystem one may use the corresponding native
build tool to build the project. For example, after using the
:generator:`Unix Makefiles` generator one may run ``make`` directly:
.. code-block:: console
$ make
$ make install
Alternatively, one may use **cmake** to `Build a Project`_ by
automatically choosing and invoking the appropriate native build tool.
.. _`CMake Options`:
Options
-------
.. include:: OPTIONS_BUILD.txt
``-L[A][H]``
List non-advanced cached variables.
List ``CACHE`` variables will run CMake and list all the variables from
the CMake ``CACHE`` that are not marked as ``INTERNAL`` or :prop_cache:`ADVANCED`.
This will effectively display current CMake settings, which can then be
changed with ``-D`` option. Changing some of the variables may result
in more variables being created. If ``A`` is specified, then it will
display also advanced variables. If ``H`` is specified, it will also
display help for each variable.
``-N``
View mode only.
Only load the cache. Do not actually run configure and generate
steps.
``--graphviz=[file]``
Generate graphviz of dependencies, see :module:`CMakeGraphVizOptions` for more.
Generate a graphviz input file that will contain all the library and
executable dependencies in the project. See the documentation for
:module:`CMakeGraphVizOptions` for more details.
``--system-information [file]``
Dump information about this system.
Dump a wide range of information about the current system. If run
from the top of a binary tree for a CMake project it will dump
additional information such as the cache, log files etc.
``--log-level=<ERROR|WARNING|NOTICE|STATUS|VERBOSE|DEBUG|TRACE>``
Set the log level.
The :command:`message` command will only output messages of the specified
log level or higher. The default log level is ``STATUS``.
To make a log level persist between CMake runs, set
:variable:`CMAKE_MESSAGE_LOG_LEVEL` as a cache variable instead.
If both the command line option and the variable are given, the command line
option takes precedence.
For backward compatibility reasons, ``--loglevel`` is also accepted as a
synonym for this option.
``--log-context``
Enable the :command:`message` command outputting context attached to each
message.
This option turns on showing context for the current CMake run only.
To make showing the context persistent for all subsequent CMake runs, set
:variable:`CMAKE_MESSAGE_CONTEXT_SHOW` as a cache variable instead.
When this command line option is given, :variable:`CMAKE_MESSAGE_CONTEXT_SHOW`
is ignored.
``--debug-trycompile``
Do not delete the :command:`try_compile` build tree.
Only useful on one :command:`try_compile` at a time.
Do not delete the files and directories created for :command:`try_compile`
calls. This is useful in debugging failed try_compiles. It may
however change the results of the try-compiles as old junk from a
previous try-compile may cause a different test to either pass or
fail incorrectly. This option is best used for one try-compile at a
time, and only when debugging.
``--debug-output``
Put cmake in a debug mode.
Print extra information during the cmake run like stack traces with
:command:`message(SEND_ERROR)` calls.
``--debug-find``
Put cmake find commands in a debug mode.
Print extra find call information during the cmake run to standard
error. Output is designed for human consumption and not for parsing.
See also the :variable:`CMAKE_FIND_DEBUG_MODE` variable for debugging
a more local part of the project.
``--trace``
Put cmake in trace mode.
Print a trace of all calls made and from where.
``--trace-expand``
Put cmake in trace mode.
Like ``--trace``, but with variables expanded.
``--trace-format=<format>``
Put cmake in trace mode and sets the trace output format.
``<format>`` can be one of the following values.
``human``
Prints each trace line in a human-readable format. This is the
default format.
``json-v1``
Prints each line as a separate JSON document. Each document is
separated by a newline ( ``\n`` ). It is guaranteed that no
newline characters will be present inside a JSON document.
JSON trace format:
.. code-block:: json
{
"file": "/full/path/to/the/CMake/file.txt",
"line": 0,
"cmd": "add_executable",
"args": ["foo", "bar"],
"time": 1579512535.9687231,
"frame": 2
}
The members are:
``file``
The full path to the CMake source file where the function
was called.
``line``
The line in ``file`` of the function call.
``cmd``
The name of the function that was called.
``args``
A string list of all function parameters.
``time``
Timestamp (seconds since epoch) of the function call.
``frame``
Stack frame depth of the function that was called.
Additionally, the first JSON document outputted contains the
``version`` key for the current major and minor version of the
JSON trace format:
.. code-block:: json
{
"version": {
"major": 1,
"minor": 0
}
}
The members are:
``version``
Indicates the version of the JSON format. The version has a
major and minor components following semantic version conventions.
``--trace-source=<file>``
Put cmake in trace mode, but output only lines of a specified file.
Multiple options are allowed.
``--trace-redirect=<file>``
Put cmake in trace mode and redirect trace output to a file instead of stderr.
``--warn-uninitialized``
Warn about uninitialized values.
Print a warning when an uninitialized variable is used.
``--warn-unused-vars``
Warn about unused variables.
Find variables that are declared or set, but not used.
``--no-warn-unused-cli``
Don't warn about command line options.
Don't find variables that are declared on the command line, but not
used.
``--check-system-vars``
Find problems with variable usage in system files.
Normally, unused and uninitialized variables are searched for only
in :variable:`CMAKE_SOURCE_DIR` and :variable:`CMAKE_BINARY_DIR`.
This flag tells CMake to warn about other files as well.
``--profiling-output=<path>``
Used in conjuction with ``--profiling-format`` to output to a given path.
``--profiling-format=<file>``
Enable the output of profiling data of CMake script in the given format.
This can aid performance analysis of CMake scripts executed. Third party
applications should be used to process the output into human readable format.
Currently supported values are:
``google-trace`` Outputs in Google Trace Format, which can be parsed by the
about:tracing tab of Google Chrome or using a plugin for a tool like Trace
Compass.
.. _`Build Tool Mode`:
Build a Project
===============
CMake provides a command-line signature to build an already-generated
project binary tree:
.. code-block:: shell
cmake --build <dir> [<options>] [-- <build-tool-options>]
This abstracts a native build tool's command-line interface with the
following options:
``--build <dir>``
Project binary directory to be built. This is required and must be first.
``--parallel [<jobs>], -j [<jobs>]``
The maximum number of concurrent processes to use when building.
If ``<jobs>`` is omitted the native build tool's default number is used.
The :envvar:`CMAKE_BUILD_PARALLEL_LEVEL` environment variable, if set,
specifies a default parallel level when this option is not given.
Some native build tools always build in parallel. The use of ``<jobs>``
value of ``1`` can be used to limit to a single job.
``--target <tgt>..., -t <tgt>...``
Build ``<tgt>`` instead of the default target. Multiple targets may be
given, separated by spaces.
``--config <cfg>``
For multi-configuration tools, choose configuration ``<cfg>``.
``--clean-first``
Build target ``clean`` first, then build.
(To clean only, use ``--target clean``.)
``--use-stderr``
Ignored. Behavior is default in CMake >= 3.0.
``--verbose, -v``
Enable verbose output - if supported - including the build commands to be
executed.
This option can be omitted if :envvar:`VERBOSE` environment variable or
:variable:`CMAKE_VERBOSE_MAKEFILE` cached variable is set.
``--``
Pass remaining options to the native tool.
Run ``cmake --build`` with no options for quick help.
Install a Project
=================
CMake provides a command-line signature to install an already-generated
project binary tree:
.. code-block:: shell
cmake --install <dir> [<options>]
This may be used after building a project to run installation without
using the generated build system or the native build tool.
The options are:
``--install <dir>``
Project binary directory to install. This is required and must be first.
``--config <cfg>``
For multi-configuration generators, choose configuration ``<cfg>``.
``--component <comp>``
Component-based install. Only install component ``<comp>``.
``--prefix <prefix>``
Override the installation prefix, :variable:`CMAKE_INSTALL_PREFIX`.
``--strip``
Strip before installing.
``-v, --verbose``
Enable verbose output.
This option can be omitted if :envvar:`VERBOSE` environment variable is set.
Run ``cmake --install`` with no options for quick help.
Open a Project
==============
.. code-block:: shell
cmake --open <dir>
Open the generated project in the associated application. This is only
supported by some generators.
.. _`Script Processing Mode`:
Run a Script
============
.. code-block:: shell
cmake [{-D <var>=<value>}...] -P <cmake-script-file> [-- <unparsed-options>...]
Process the given cmake file as a script written in the CMake
language. No configure or generate step is performed and the cache
is not modified. If variables are defined using ``-D``, this must be
done before the ``-P`` argument.
Any options after ``--`` are not parsed by CMake, but they are still included
in the set of :variable:`CMAKE_ARGV<n> <CMAKE_ARGV0>` variables passed to the
script (including the ``--`` itself).
Run a Command-Line Tool
=======================
CMake provides builtin command-line tools through the signature
.. code-block:: shell
cmake -E <command> [<options>]
Run ``cmake -E`` or ``cmake -E help`` for a summary of commands.
Available commands are:
``capabilities``
Report cmake capabilities in JSON format. The output is a JSON object
with the following keys:
``version``
A JSON object with version information. Keys are:
``string``
The full version string as displayed by cmake ``--version``.
``major``
The major version number in integer form.
``minor``
The minor version number in integer form.
``patch``
The patch level in integer form.
``suffix``
The cmake version suffix string.
``isDirty``
A bool that is set if the cmake build is from a dirty tree.
``generators``
A list available generators. Each generator is a JSON object with the
following keys:
``name``
A string containing the name of the generator.
``toolsetSupport``
``true`` if the generator supports toolsets and ``false`` otherwise.
``platformSupport``
``true`` if the generator supports platforms and ``false`` otherwise.
``extraGenerators``
A list of strings with all the extra generators compatible with
the generator.
``fileApi``
Optional member that is present when the :manual:`cmake-file-api(7)`
is available. The value is a JSON object with one member:
``requests``
A JSON array containing zero or more supported file-api requests.
Each request is a JSON object with members:
``kind``
Specifies one of the supported :ref:`file-api object kinds`.
``version``
A JSON array whose elements are each a JSON object containing
``major`` and ``minor`` members specifying non-negative integer
version components.
``serverMode``
``true`` if cmake supports server-mode and ``false`` otherwise.
``cat <files>...``
Concatenate files and print on the standard output.
``chdir <dir> <cmd> [<arg>...]``
Change the current working directory and run a command.
``compare_files [--ignore-eol] <file1> <file2>``
Check if ``<file1>`` is same as ``<file2>``. If files are the same,
then returns ``0``, if not it returns ``1``. The ``--ignore-eol`` option
implies line-wise comparison and ignores LF/CRLF differences.
``copy <file>... <destination>``
Copy files to ``<destination>`` (either file or directory).
If multiple files are specified, the ``<destination>`` must be
directory and it must exist. Wildcards are not supported.
``copy`` does follow symlinks. That means it does not copy symlinks,
but the files or directories it point to.
``copy_directory <dir>... <destination>``
Copy content of ``<dir>...`` directories to ``<destination>`` directory.
If ``<destination>`` directory does not exist it will be created.
``copy_directory`` does follow symlinks.
``copy_if_different <file>... <destination>``
Copy files to ``<destination>`` (either file or directory) if
they have changed.
If multiple files are specified, the ``<destination>`` must be
directory and it must exist.
``copy_if_different`` does follow symlinks.
``create_symlink <old> <new>``
Create a symbolic link ``<new>`` naming ``<old>``.
.. note::
Path to where ``<new>`` symbolic link will be created has to exist beforehand.
``echo [<string>...]``
Displays arguments as text.
``echo_append [<string>...]``
Displays arguments as text but no new line.
``env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...``
Run command in a modified environment.
``environment``
Display the current environment variables.
``false``
Do nothing, with an exit code of 1.
``make_directory <dir>...``
Create ``<dir>`` directories. If necessary, create parent
directories too. If a directory already exists it will be
silently ignored.
``md5sum <file>...``
Create MD5 checksum of files in ``md5sum`` compatible format::
351abe79cd3800b38cdfb25d45015a15 file1.txt
052f86c15bbde68af55c7f7b340ab639 file2.txt
``sha1sum <file>...``
Create SHA1 checksum of files in ``sha1sum`` compatible format::
4bb7932a29e6f73c97bb9272f2bdc393122f86e0 file1.txt
1df4c8f318665f9a5f2ed38f55adadb7ef9f559c file2.txt
``sha224sum <file>...``
Create SHA224 checksum of files in ``sha224sum`` compatible format::
b9b9346bc8437bbda630b0b7ddfc5ea9ca157546dbbf4c613192f930 file1.txt
6dfbe55f4d2edc5fe5c9197bca51ceaaf824e48eba0cc453088aee24 file2.txt
``sha256sum <file>...``
Create SHA256 checksum of files in ``sha256sum`` compatible format::
76713b23615d31680afeb0e9efe94d47d3d4229191198bb46d7485f9cb191acc file1.txt
15b682ead6c12dedb1baf91231e1e89cfc7974b3787c1e2e01b986bffadae0ea file2.txt
``sha384sum <file>...``
Create SHA384 checksum of files in ``sha384sum`` compatible format::
acc049fedc091a22f5f2ce39a43b9057fd93c910e9afd76a6411a28a8f2b8a12c73d7129e292f94fc0329c309df49434 file1.txt
668ddeb108710d271ee21c0f3acbd6a7517e2b78f9181c6a2ff3b8943af92b0195dcb7cce48aa3e17893173c0a39e23d file2.txt
``sha512sum <file>...``
Create SHA512 checksum of files in ``sha512sum`` compatible format::
2a78d7a6c5328cfb1467c63beac8ff21794213901eaadafd48e7800289afbc08e5fb3e86aa31116c945ee3d7bf2a6194489ec6101051083d1108defc8e1dba89 file1.txt
7a0b54896fe5e70cca6dd643ad6f672614b189bf26f8153061c4d219474b05dad08c4e729af9f4b009f1a1a280cb625454bf587c690f4617c27e3aebdf3b7a2d file2.txt
``remove [-f] <file>...``
.. deprecated:: 3.17
Remove the file(s). The planned behaviour was that if any of the
listed files already do not exist, the command returns a non-zero exit code,
but no message is logged. The ``-f`` option changes the behavior to return a
zero exit code (i.e. success) in such situations instead.
``remove`` does not follow symlinks. That means it remove only symlinks
and not files it point to.
The implementation was buggy and always returned 0. It cannot be fixed without
breaking backwards compatibility. Use ``rm`` instead.
``remove_directory <dir>...``
.. deprecated:: 3.17
Remove ``<dir>`` directories and their contents. If a directory does
not exist it will be silently ignored. If ``<dir>`` is a symlink to
a directory, just the symlink will be removed.
Use ``rm`` instead.
``rename <oldname> <newname>``
Rename a file or directory (on one volume). If file with the ``<newname>`` name
already exists, then it will be silently replaced.
``rm [-rRf] <file> <dir>...``
Remove the files ``<file>`` or directories ``dir``.
Use ``-r`` or ``-R`` to remove directories and their contents recursively.
If any of the listed files/directories do not exist, the command returns a
non-zero exit code, but no message is logged. The ``-f`` option changes
the behavior to return a zero exit code (i.e. success) in such
situations instead.
``server``
Launch :manual:`cmake-server(7)` mode.
``sleep <number>...``
Sleep for given number of seconds.
``tar [cxt][vf][zjJ] file.tar [<options>] [--] [<pathname>...]``
Create or extract a tar or zip archive. Options are:
``c``
Create a new archive containing the specified files.
If used, the ``<pathname>...`` argument is mandatory.
``x``
Extract to disk from the archive.
The ``<pathname>...`` argument could be used to extract only selected files
or directories.
When extracting selected files or directories, you must provide their exact
names including the path, as printed by list (``-t``).
``t``
List archive contents.
The ``<pathname>...`` argument could be used to list only selected files
or directories.
``v``
Produce verbose output.
``z``
Compress the resulting archive with gzip.
``j``
Compress the resulting archive with bzip2.
``J``
Compress the resulting archive with XZ.
``--zstd``
Compress the resulting archive with Zstandard.
``--files-from=<file>``
Read file names from the given file, one per line.
Blank lines are ignored. Lines may not start in ``-``
except for ``--add-file=<name>`` to add files whose
names start in ``-``.
``--format=<format>``
Specify the format of the archive to be created.
Supported formats are: ``7zip``, ``gnutar``, ``pax``,
``paxr`` (restricted pax, default), and ``zip``.
``--mtime=<date>``
Specify modification time recorded in tarball entries.
``--``
Stop interpreting options and treat all remaining arguments
as file names, even if they start with ``-``.
``time <command> [<args>...]``
Run command and display elapsed time.
``touch <file>...``
Creates ``<file>`` if file do not exist.
If ``<file>`` exists, it is changing ``<file>`` access and modification times.
``touch_nocreate <file>...``
Touch a file if it exists but do not create it. If a file does
not exist it will be silently ignored.
``true``
Do nothing, with an exit code of 0.
Windows-specific Command-Line Tools
-----------------------------------
The following ``cmake -E`` commands are available only on Windows:
``delete_regv <key>``
Delete Windows registry value.
``env_vs8_wince <sdkname>``
Displays a batch file which sets the environment for the provided
Windows CE SDK installed in VS2005.
``env_vs9_wince <sdkname>``
Displays a batch file which sets the environment for the provided
Windows CE SDK installed in VS2008.
``write_regv <key> <value>``
Write Windows registry value.
Run the Find-Package Tool
=========================
CMake provides a pkg-config like helper for Makefile-based projects:
.. code-block:: shell
cmake --find-package [<options>]
It searches a package using :command:`find_package()` and prints the
resulting flags to stdout. This can be used instead of pkg-config
to find installed libraries in plain Makefile-based projects or in
autoconf-based projects (via ``share/aclocal/cmake.m4``).
.. note::
This mode is not well-supported due to some technical limitations.
It is kept for compatibility but should not be used in new projects.
View Help
=========
To print selected pages from the CMake documentation, use
.. code-block:: shell
cmake --help[-<topic>]
with one of the following options:
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

4
6.5.1/_tools/cmake/share/cmake-3.18/Help/module/CPackPackageMaker.rst
View File

@ -1,4 +0,0 @@
CPackPackageMaker
-----------------
The documentation for the CPack PackageMaker generator has moved here: :cpack_gen:`CPack PackageMaker Generator`

1
6.5.1/_tools/cmake/share/cmake-3.18/Help/module/UseJavaClassFilelist.rst
View File

@ -1 +0,0 @@
.. cmake-module:: ../../Modules/UseJavaClassFilelist.cmake

1
6.5.1/_tools/cmake/share/cmake-3.18/Help/module/UseJavaSymlinks.rst
View File

@ -1 +0,0 @@
.. cmake-module:: ../../Modules/UseJavaSymlinks.cmake

20
6.5.1/_tools/cmake/share/cmake-3.18/Help/policy/CMP0101.rst
View File

@ -1,20 +0,0 @@
CMP0101
-------
:command:`target_compile_options` now honors ``BEFORE`` keyword in all scopes.
In CMake 3.16 and below the :command:`target_compile_options` ignores the
``BEFORE`` keyword in private scope. CMake 3.17 and later honors
``BEFORE`` keyword in all scopes. This policy provides compatibility for
projects that have not been updated to expect the new behavior.
The ``OLD`` behavior for this policy is to not honor ``BEFORE`` keyword in
private scope. The ``NEW`` behavior of this policy is to honor
``BEFORE`` keyword in all scopes.
This policy was introduced in CMake version 3.17. Use the
:command:`cmake_policy` command to set it to ``OLD`` or ``NEW`` explicitly.
Unlike many policies, CMake version |release| does *not* warn
when this policy is not set and simply uses ``OLD`` behavior.
.. include:: DEPRECATED.txt

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_dir/INTERPROCEDURAL_OPTIMIZATION.rst
View File

@ -1,7 +0,0 @@
INTERPROCEDURAL_OPTIMIZATION
----------------------------
Enable interprocedural optimization for targets in a directory.
If set to true, enables interprocedural optimizations if they are
known to be supported by the compiler.

8
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_dir/INTERPROCEDURAL_OPTIMIZATION_CONFIG.rst
View File

@ -1,8 +0,0 @@
INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
-------------------------------------
Per-configuration interprocedural optimization for a directory.
This is a per-configuration version of ``INTERPROCEDURAL_OPTIMIZATION``.
If set, this property overrides the generic property for the named
configuration.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_dir/RULE_LAUNCH_COMPILE.rst
View File

@ -1,7 +0,0 @@
RULE_LAUNCH_COMPILE
-------------------
Specify a launcher for compile rules.
See the global property of the same name for details. This overrides
the global property for a directory.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_dir/RULE_LAUNCH_LINK.rst
View File

@ -1,7 +0,0 @@
RULE_LAUNCH_LINK
----------------
Specify a launcher for link rules.
See the global property of the same name for details. This overrides
the global property for a directory.

15
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_gbl/AUTOGEN_SOURCE_GROUP.rst
View File

@ -1,15 +0,0 @@
AUTOGEN_SOURCE_GROUP
--------------------
Name of the :command:`source_group` for :prop_tgt:`AUTOMOC` and
:prop_tgt:`AUTORCC` generated files.
Files generated by :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTORCC` are not always
known at configure time and therefore can't be passed to
:command:`source_group`.
:prop_gbl:`AUTOGEN_SOURCE_GROUP` an be used instead to generate or select
a source group for :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTORCC` generated files.
For :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTORCC` specific overrides see
:prop_gbl:`AUTOMOC_SOURCE_GROUP` and :prop_gbl:`AUTORCC_SOURCE_GROUP`
respectively.

318
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.rst
View File

@ -1,318 +0,0 @@
CMAKE_CXX_KNOWN_FEATURES
------------------------
List of C++ features known to this version of CMake.
The features listed in this global property may be known to be available to the
C++ compiler. If the feature is available with the C++ compiler, it will
be listed in the :variable:`CMAKE_CXX_COMPILE_FEATURES` variable.
The features listed here may be used with the :command:`target_compile_features`
command. See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.
The features known to this version of CMake are:
``cxx_std_98``
Compiler mode is at least C++ 98.
``cxx_std_11``
Compiler mode is at least C++ 11.
``cxx_std_14``
Compiler mode is at least C++ 14.
``cxx_std_17``
Compiler mode is at least C++ 17.
``cxx_std_20``
Compiler mode is at least C++ 20.
``cxx_aggregate_default_initializers``
Aggregate default initializers, as defined in N3605_.
.. _N3605: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3605.html
``cxx_alias_templates``
Template aliases, as defined in N2258_.
.. _N2258: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf
``cxx_alignas``
Alignment control ``alignas``, as defined in N2341_.
.. _N2341: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf
``cxx_alignof``
Alignment control ``alignof``, as defined in N2341_.
.. _N2341: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf
``cxx_attributes``
Generic attributes, as defined in N2761_.
.. _N2761: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf
``cxx_attribute_deprecated``
``[[deprecated]]`` attribute, as defined in N3760_.
.. _N3760: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html
``cxx_auto_type``
Automatic type deduction, as defined in N1984_.
.. _N1984: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
``cxx_binary_literals``
Binary literals, as defined in N3472_.
.. _N3472: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
``cxx_constexpr``
Constant expressions, as defined in N2235_.
.. _N2235: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
``cxx_contextual_conversions``
Contextual conversions, as defined in N3323_.
.. _N3323: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3323.pdf
``cxx_decltype_incomplete_return_types``
Decltype on incomplete return types, as defined in N3276_.
.. _N3276 : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf
``cxx_decltype``
Decltype, as defined in N2343_.
.. _N2343: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf
``cxx_decltype_auto``
``decltype(auto)`` semantics, as defined in N3638_.
.. _N3638: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html
``cxx_default_function_template_args``
Default template arguments for function templates, as defined in DR226_
.. _DR226: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226
``cxx_defaulted_functions``
Defaulted functions, as defined in N2346_.
.. _N2346: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
``cxx_defaulted_move_initializers``
Defaulted move initializers, as defined in N3053_.
.. _N3053: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html
``cxx_delegating_constructors``
Delegating constructors, as defined in N1986_.
.. _N1986: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf
``cxx_deleted_functions``
Deleted functions, as defined in N2346_.
.. _N2346: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
``cxx_digit_separators``
Digit separators, as defined in N3781_.
.. _N3781: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf
``cxx_enum_forward_declarations``
Enum forward declarations, as defined in N2764_.
.. _N2764: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf
``cxx_explicit_conversions``
Explicit conversion operators, as defined in N2437_.
.. _N2437: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf
``cxx_extended_friend_declarations``
Extended friend declarations, as defined in N1791_.
.. _N1791: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf
``cxx_extern_templates``
Extern templates, as defined in N1987_.
.. _N1987: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm
``cxx_final``
Override control ``final`` keyword, as defined in N2928_, N3206_ and N3272_.
.. _N2928: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
.. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
.. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
``cxx_func_identifier``
Predefined ``__func__`` identifier, as defined in N2340_.
.. _N2340: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2340.htm
``cxx_generalized_initializers``
Initializer lists, as defined in N2672_.
.. _N2672: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm
``cxx_generic_lambdas``
Generic lambdas, as defined in N3649_.
.. _N3649: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html
``cxx_inheriting_constructors``
Inheriting constructors, as defined in N2540_.
.. _N2540: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm
``cxx_inline_namespaces``
Inline namespaces, as defined in N2535_.
.. _N2535: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm
``cxx_lambdas``
Lambda functions, as defined in N2927_.
.. _N2927: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf
``cxx_lambda_init_captures``
Initialized lambda captures, as defined in N3648_.
.. _N3648: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html
``cxx_local_type_template_args``
Local and unnamed types as template arguments, as defined in N2657_.
.. _N2657: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm
``cxx_long_long_type``
``long long`` type, as defined in N1811_.
.. _N1811: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf
``cxx_noexcept``
Exception specifications, as defined in N3050_.
.. _N3050: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html
``cxx_nonstatic_member_init``
Non-static data member initialization, as defined in N2756_.
.. _N2756: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
``cxx_nullptr``
Null pointer, as defined in N2431_.
.. _N2431: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
``cxx_override``
Override control ``override`` keyword, as defined in N2928_, N3206_
and N3272_.
.. _N2928: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
.. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
.. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
``cxx_range_for``
Range-based for, as defined in N2930_.
.. _N2930: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html
``cxx_raw_string_literals``
Raw string literals, as defined in N2442_.
.. _N2442: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
``cxx_reference_qualified_functions``
Reference qualified functions, as defined in N2439_.
.. _N2439: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm
``cxx_relaxed_constexpr``
Relaxed constexpr, as defined in N3652_.
.. _N3652: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html
``cxx_return_type_deduction``
Return type deduction on normal functions, as defined in N3386_.
.. _N3386: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.html
``cxx_right_angle_brackets``
Right angle bracket parsing, as defined in N1757_.
.. _N1757: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
``cxx_rvalue_references``
R-value references, as defined in N2118_.
.. _N2118: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
``cxx_sizeof_member``
Size of non-static data members, as defined in N2253_.
.. _N2253: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
``cxx_static_assert``
Static assert, as defined in N1720_.
.. _N1720: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
``cxx_strong_enums``
Strongly typed enums, as defined in N2347_.
.. _N2347: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
``cxx_thread_local``
Thread-local variables, as defined in N2659_.
.. _N2659: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm
``cxx_trailing_return_types``
Automatic function return type, as defined in N2541_.
.. _N2541: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm
``cxx_unicode_literals``
Unicode string literals, as defined in N2442_.
.. _N2442: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
``cxx_uniform_initialization``
Uniform initialization, as defined in N2640_.
.. _N2640: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2640.pdf
``cxx_unrestricted_unions``
Unrestricted unions, as defined in N2544_.
.. _N2544: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf
``cxx_user_literals``
User-defined literals, as defined in N2765_.
.. _N2765: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf
``cxx_variable_templates``
Variable templates, as defined in N3651_.
.. _N3651: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf
``cxx_variadic_macros``
Variadic macros, as defined in N1653_.
.. _N1653: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.htm
``cxx_variadic_templates``
Variadic templates, as defined in N2242_.
.. _N2242: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf
``cxx_template_template_parameters``
Template template parameters, as defined in ``ISO/IEC 14882:1998``.

10
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_gbl/USE_FOLDERS.rst
View File

@ -1,10 +0,0 @@
USE_FOLDERS
-----------
Use the :prop_tgt:`FOLDER` target property to organize targets into
folders.
If not set, CMake treats this property as ``OFF`` by default. CMake
generators that are capable of organizing into a hierarchy of folders
use the values of the :prop_tgt:`FOLDER` target property to name those
folders. See also the documentation for the :prop_tgt:`FOLDER` target property.

11
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_sf/LANGUAGE.rst
View File

@ -1,11 +0,0 @@
LANGUAGE
--------
What programming language is the file.
A property that can be set to indicate what programming language the
source file is. If it is not set the language is determined based on
the file extension. Typical values are ``CXX`` (i.e. C++), ``C``,
``CSharp``, ``CUDA``, ``Fortran``, and ``ASM``. Setting this
property for a file means this file will be compiled. Do not set this
for headers or files that should not be compiled.

9
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_test/ENVIRONMENT.rst
View File

@ -1,9 +0,0 @@
ENVIRONMENT
-----------
Specify environment variables that should be defined for running a test.
If set to a list of environment variables and values of the form
``MYVAR=value`` those environment variables will be defined while running
the test. The environment is restored to its previous state after the
test is done.

6
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_test/LABELS.rst
View File

@ -1,6 +0,0 @@
LABELS
------
Specify a list of text labels associated with a test.
The list is reported in dashboard submissions.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_test/WILL_FAIL.rst
View File

@ -1,7 +0,0 @@
WILL_FAIL
---------
If set to true, this will invert the pass/fail flag of the test.
This property can be used for tests that are expected to fail and
return a non zero return code.

17
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst
View File

@ -1,17 +0,0 @@
AUTOMOC_MOC_OPTIONS
-------------------
Additional options for ``moc`` when using :prop_tgt:`AUTOMOC`
This property is only used if the :prop_tgt:`AUTOMOC` property is ``ON``
for this target. In this case, it holds additional command line
options which will be used when ``moc`` is executed during the build, i.e.
it is equivalent to the optional ``OPTIONS`` argument of the
:module:`qt4_wrap_cpp() <FindQt4>` macro.
This property is initialized by the value of the
:variable:`CMAKE_AUTOMOC_MOC_OPTIONS` variable if it is set when a target
is created, or an empty string otherwise.
See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/BUILD_RPATH.rst
View File

@ -1,13 +0,0 @@
BUILD_RPATH
-----------
A :ref:`semicolon-separated list <CMake Language Lists>` specifying runtime path (``RPATH``)
entries to add to binaries linked in the build tree (for platforms that
support it). The entries will *not* be used for binaries in the install
tree. See also the :prop_tgt:`INSTALL_RPATH` target property.
This property is initialized by the value of the variable
:variable:`CMAKE_BUILD_RPATH` if it is set when a target is created.
This property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/CONFIG_POSTFIX.rst
View File

@ -1,13 +0,0 @@
<CONFIG>_POSTFIX
----------------
Postfix to append to the target file name for configuration <CONFIG>.
When building with configuration <CONFIG> the value of this property
is appended to the target file name built on disk. For non-executable
targets, this property is initialized by the value of the variable
CMAKE_<CONFIG>_POSTFIX if it is set when a target is created. This
property is ignored on the Mac for Frameworks and App Bundles.
For macOS see also the :prop_tgt:`FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>`
target property.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/DEBUG_POSTFIX.rst
View File

@ -1,7 +0,0 @@
DEBUG_POSTFIX
-------------
See target property ``<CONFIG>_POSTFIX``.
This property is a special case of the more-general ``<CONFIG>_POSTFIX``
property for the ``DEBUG`` configuration.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/DEPRECATION.rst
View File

@ -1,7 +0,0 @@
DEPRECATION
-----------
Deprecation message from imported target's developer.
``DEPRECATION`` is the message regarding a deprecation status to be displayed
to downstream users of a target.

31
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/ENABLE_EXPORTS.rst
View File

@ -1,31 +0,0 @@
ENABLE_EXPORTS
--------------
Specify whether an executable exports symbols for loadable modules.
Normally an executable does not export any symbols because it is the
final program. It is possible for an executable to export symbols to
be used by loadable modules. When this property is set to true CMake
will allow other targets to "link" to the executable with the
:command:`target_link_libraries` command. On all platforms a target-level
dependency on the executable is created for targets that link to it.
Handling of the executable on the link lines of the loadable modules
varies by platform:
* On Windows-based systems (including Cygwin) an "import library" is
created along with the executable to list the exported symbols.
Loadable modules link to the import library to get the symbols.
* On macOS, loadable modules link to the executable itself using the
``-bundle_loader`` flag.
* On AIX, a linker "import file" is created along with the executable
to list the exported symbols for import when linking other targets.
Loadable modules link to the import file to get the symbols.
* On other platforms, loadable modules are simply linked without
referencing the executable since the dynamic loader will
automatically bind symbols when the module is loaded.
This property is initialized by the value of the variable
:variable:`CMAKE_ENABLE_EXPORTS` if it is set when a target is created.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/FOLDER.rst
View File

@ -1,13 +0,0 @@
FOLDER
------
Set the folder name. Use to organize targets in an IDE.
Targets with no ``FOLDER`` property will appear as top level entities in
IDEs like Visual Studio. Targets with the same ``FOLDER`` property value
will appear next to each other in a folder of that name. To nest
folders, use ``FOLDER`` values such as 'GUI/Dialogs' with '/' characters
separating folder levels.
This property is initialized by the value of the variable
:variable:`CMAKE_FOLDER` if it is set when a target is created.

11
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/IMPORTED_CONFIGURATIONS.rst
View File

@ -1,11 +0,0 @@
IMPORTED_CONFIGURATIONS
-----------------------
Configurations provided for an IMPORTED target.
Set this to the list of configuration names available for an IMPORTED
target. The names correspond to configurations defined in the project
from which the target is imported. If the importing project uses a
different set of configurations the names may be mapped using the
MAP_IMPORTED_CONFIG_<CONFIG> property. Ignored for non-imported
targets.

9
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/IMPORTED_IMPLIB.rst
View File

@ -1,9 +0,0 @@
IMPORTED_IMPLIB
---------------
Full path to the import library for an ``IMPORTED`` target.
Set this to the location of the ``.lib`` part of a Windows DLL, or on
AIX set it to an import file created for executables that export symbols
(see the :prop_tgt:`ENABLE_EXPORTS` target property).
Ignored for non-imported targets.

11
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/IMPORTED_OBJECTS.rst
View File

@ -1,11 +0,0 @@
IMPORTED_OBJECTS
----------------
A :ref:`semicolon-separated list <CMake Language Lists>` of absolute paths to the object
files on disk for an :ref:`imported <Imported targets>`
:ref:`object library <object libraries>`.
Ignored for non-imported targets.
Projects may skip ``IMPORTED_OBJECTS`` if the configuration-specific
property :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` is set instead.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst
View File

@ -1,7 +0,0 @@
IMPORTED_OBJECTS_<CONFIG>
-------------------------
<CONFIG>-specific version of :prop_tgt:`IMPORTED_OBJECTS` property.
Configuration names correspond to those provided by the project from
which the target is imported.

16
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/INSTALL_NAME_DIR.rst
View File

@ -1,16 +0,0 @@
INSTALL_NAME_DIR
----------------
macOS directory name for installed targets.
``INSTALL_NAME_DIR`` is a string specifying the directory portion of the
"install_name" field of shared libraries on macOS to use in the
installed targets.
This property is initialized by the value of the variable
:variable:`CMAKE_INSTALL_NAME_DIR` if it is set when a target is
created.
This property supports :manual:`generator expressions <cmake-generator-expressions(7)>`.
In particular, the ``$<INSTALL_PREFIX>`` generator expression can be used to set the
directory relative to the install-time prefix.

16
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/INSTALL_RPATH.rst
View File

@ -1,16 +0,0 @@
INSTALL_RPATH
-------------
The rpath to use for installed targets.
A semicolon-separated list specifying the rpath to use in installed
targets (for platforms that support it). This property is initialized
by the value of the variable :variable:`CMAKE_INSTALL_RPATH` if it is set when
a target is created.
Because the rpath may contain ``${ORIGIN}``, which coincides with CMake syntax,
the contents of ``INSTALL_RPATH`` are properly escaped in the
``cmake_install.cmake`` script (see policy :policy:`CMP0095`.)
This property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/LANG_CLANG_TIDY.rst
View File

@ -1,13 +0,0 @@
<LANG>_CLANG_TIDY
-----------------
This property is implemented only when ``<LANG>`` is ``C`` or ``CXX``.
Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a command
line for the ``clang-tidy`` tool. The :ref:`Makefile Generators`
and the :generator:`Ninja` generator will run this tool along with the
compiler and report a warning if the tool reports any problems.
This property is initialized by the value of
the :variable:`CMAKE_<LANG>_CLANG_TIDY` variable if it is set
when a target is created.

13
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/LANG_CPPLINT.rst
View File

@ -1,13 +0,0 @@
<LANG>_CPPLINT
--------------
This property is supported only when ``<LANG>`` is ``C`` or ``CXX``.
Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a command line
for the ``cpplint`` style checker. The :ref:`Makefile Generators` and the
:generator:`Ninja` generator will run ``cpplint`` along with the compiler
and report any problems.
This property is initialized by the value of the
:variable:`CMAKE_<LANG>_CPPLINT` variable if it is set when a target is
created.

19
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/LINK_LIBRARIES.rst
View File

@ -1,19 +0,0 @@
LINK_LIBRARIES
--------------
List of direct link dependencies.
This property specifies the list of libraries or targets which will be
used for linking. In addition to accepting values from the
:command:`target_link_libraries` command, values may be set directly on
any target using the :command:`set_property` command.
The value of this property is used by the generators to set the link
libraries for the compiler.
Contents of ``LINK_LIBRARIES`` may use "generator expressions" with the
syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
for available expressions. See the :manual:`cmake-buildsystem(7)` manual
for more on defining buildsystem properties.
.. include:: LINK_LIBRARIES_INDIRECTION.txt

15
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/LINK_WHAT_YOU_USE.rst
View File

@ -1,15 +0,0 @@
LINK_WHAT_YOU_USE
---------------------------
This is a boolean option that when set to ``TRUE`` will automatically run
``ldd -r -u`` on the target after it is linked. In addition, the linker flag
``-Wl,--no-as-needed`` will be passed to the target with the link command so
that all libraries specified on the command line will be linked into the
target. This will result in the link producing a list of libraries that
provide no symbols used by this target but are being linked to it.
This is only applicable to executable and shared library targets and
will only work when ld and ldd accept the flags used.
This property is initialized by the value of
the :variable:`CMAKE_LINK_WHAT_YOU_USE` variable if it is set
when a target is created.

15
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/NO_SYSTEM_FROM_IMPORTED.rst
View File

@ -1,15 +0,0 @@
NO_SYSTEM_FROM_IMPORTED
-----------------------
Do not treat include directories from the interfaces of consumed
:ref:`imported targets` as ``SYSTEM``.
The contents of the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` target property
of imported targets are treated as ``SYSTEM`` includes by default. If this
property is enabled on a target, compilation of sources in that target will
not treat the contents of the ``INTERFACE_INCLUDE_DIRECTORIES`` of consumed
imported targets as system includes.
This property is initialized by the value of the
:variable:`CMAKE_NO_SYSTEM_FROM_IMPORTED` variable if it is set when a target
is created.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/RULE_LAUNCH_COMPILE.rst
View File

@ -1,7 +0,0 @@
RULE_LAUNCH_COMPILE
-------------------
Specify a launcher for compile rules.
See the global property of the same name for details. This overrides
the global and directory property for a target.

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/RULE_LAUNCH_LINK.rst
View File

@ -1,7 +0,0 @@
RULE_LAUNCH_LINK
----------------
Specify a launcher for link rules.
See the global property of the same name for details. This overrides
the global and directory property for a target.

6
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/SOURCES.rst
View File

@ -1,6 +0,0 @@
SOURCES
-------
Source names specified for a target.
List of sources specified for a target.

10
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION.rst
View File

@ -1,10 +0,0 @@
VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
--------------------------------------
Visual Studio Windows Target Platform Minimum Version
For Windows 10. Specifies the minimum version of the OS that is being
targeted. For example ``10.0.10240.0``. If the value is not specified, the
value of :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` will be used on
WindowsStore projects otherwise the target platform minimum version will not
be specified for the project.

11
6.5.1/_tools/cmake/share/cmake-3.18/Help/prop_tgt/XXX_OUTPUT_DIRECTORY.txt
View File

@ -1,11 +0,0 @@
Output directory in which to build |XXX| target files.
This property specifies the directory into which |xxx| target files
should be built. The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
Multi-configuration generators (VS, Xcode) append a per-configuration
subdirectory to the specified directory unless a generator expression
is used.
This property is initialized by the value of the variable
|CMAKE_XXX_OUTPUT_DIRECTORY| if it is set when a target is created.

11
6.5.1/_tools/cmake/share/cmake-3.18/Help/variable/CMAKE_ANDROID_API.rst
View File

@ -1,11 +0,0 @@
CMAKE_ANDROID_API
-----------------
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this variable may be set to specify the default value for the
:prop_tgt:`ANDROID_API` target property. See that target property for
additional information.
Otherwise, when :ref:`Cross Compiling for Android`, this variable provides
the Android API version number targeted. This will be the same value as
the :variable:`CMAKE_SYSTEM_VERSION` variable for ``Android`` platforms.

Some files were not shown because too many files have changed in this diff Show More