amass/qt-build-tools
1
0
Fork 0
mirror of https://github.com/crystalidea/qt-build-tools.git synced 2025-07-06 09:35:55 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

qr 6.5.1: still missed with cmake version, trying 3.18.3

Browse Source
This commit is contained in:
kleuter
2023-10-31 23:36:59 +01:00
parent c386aac06f
commit 72a8e4201b
2808 changed files with 8828 additions and 3966 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/ID_RESERVE.txt Normal file
View File

@ -0,0 +1,7 @@
.. note::
CMake reserves identifiers that:
* begin with ``CMAKE_`` (upper-, lower-, or mixed-case), or
* begin with ``_CMAKE_`` (upper-, lower-, or mixed-case), or
* begin with ``_`` followed by the name of any :manual:`CMake Command <cmake-commands(7)>`.

17
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/LINKS.txt Normal file
View File

@ -0,0 +1,17 @@
The following resources are available to get help using CMake:
Home Page
https://cmake.org
The primary starting point for learning about CMake.
Online Documentation and Community Resources
https://cmake.org/documentation
Links to available documentation and community resources may be
found on this web page.
Discourse Forum
https://discourse.cmake.org
The Discourse Forum hosts discussion and questions about CMake.

126
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/OPTIONS_BUILD.txt Normal file
View File

@ -0,0 +1,126 @@
``-S <path-to-source>``
Path to root directory of the CMake project to build.
``-B <path-to-build>``
Path to directory which CMake will use as the root of build directory.
If the directory doesn't already exist CMake will make it.
``-C <initial-cache>``
Pre-load a script to populate the cache.
When CMake is first run in an empty build tree, it creates a
``CMakeCache.txt`` file and populates it with customizable settings for
the project. This option may be used to specify a file from which
to load cache entries before the first pass through the project's
CMake listfiles. The loaded entries take priority over the
project's default values. The given file should be a CMake script
containing :command:`set` commands that use the ``CACHE`` option, not a
cache-format file.
References to :variable:`CMAKE_SOURCE_DIR` and :variable:`CMAKE_BINARY_DIR`
within the script evaluate to the top-level source and build tree.
``-D <var>:<type>=<value>, -D <var>=<value>``
Create or update a CMake ``CACHE`` entry.
When CMake is first run in an empty build tree, it creates a
``CMakeCache.txt`` file and populates it with customizable settings for
the project. This option may be used to specify a setting that
takes priority over the project's default value. The option may be
repeated for as many ``CACHE`` entries as desired.
If the ``:<type>`` portion is given it must be one of the types
specified by the :command:`set` command documentation for its
``CACHE`` signature.
If the ``:<type>`` portion is omitted the entry will be created
with no type if it does not exist with a type already. If a
command in the project sets the type to ``PATH`` or ``FILEPATH``
then the ``<value>`` will be converted to an absolute path.
This option may also be given as a single argument:
``-D<var>:<type>=<value>`` or ``-D<var>=<value>``.
``-U <globbing_expr>``
Remove matching entries from CMake ``CACHE``.
This option may be used to remove one or more variables from the
``CMakeCache.txt`` file, globbing expressions using ``*`` and ``?`` are
supported. The option may be repeated for as many ``CACHE`` entries as
desired.
Use with care, you can make your ``CMakeCache.txt`` non-working.
``-G <generator-name>``
Specify a build system generator.
CMake may support multiple native build systems on certain
platforms. A generator is responsible for generating a particular
build system. Possible generator names are specified in the
:manual:`cmake-generators(7)` manual.
If not specified, CMake checks the :envvar:`CMAKE_GENERATOR` environment
variable and otherwise falls back to a builtin default selection.
``-T <toolset-spec>``
Toolset specification for the generator, if supported.
Some CMake generators support a toolset specification to tell
the native build system how to choose a compiler. See the
:variable:`CMAKE_GENERATOR_TOOLSET` variable for details.
``-A <platform-name>``
Specify platform name if supported by generator.
Some CMake generators support a platform name to be given to the
native build system to choose a compiler or SDK. See the
:variable:`CMAKE_GENERATOR_PLATFORM` variable for details.
``-Wno-dev``
Suppress developer warnings.
Suppress warnings that are meant for the author of the
``CMakeLists.txt`` files. By default this will also turn off
deprecation warnings.
``-Wdev``
Enable developer warnings.
Enable warnings that are meant for the author of the ``CMakeLists.txt``
files. By default this will also turn on deprecation warnings.
``-Werror=dev``
Make developer warnings errors.
Make warnings that are meant for the author of the ``CMakeLists.txt`` files
errors. By default this will also turn on deprecated warnings as errors.
``-Wno-error=dev``
Make developer warnings not errors.
Make warnings that are meant for the author of the ``CMakeLists.txt`` files not
errors. By default this will also turn off deprecated warnings as errors.
``-Wdeprecated``
Enable deprecated functionality warnings.
Enable warnings for usage of deprecated functionality, that are meant
for the author of the ``CMakeLists.txt`` files.
``-Wno-deprecated``
Suppress deprecated functionality warnings.
Suppress warnings for usage of deprecated functionality, that are meant
for the author of the ``CMakeLists.txt`` files.
``-Werror=deprecated``
Make deprecated macro and function warnings errors.
Make warnings for usage of deprecated macros and functions, that are meant
for the author of the ``CMakeLists.txt`` files, errors.
``-Wno-error=deprecated``
Make deprecated macro and function warnings not errors.
Make warnings for usage of deprecated macros and functions, that are meant
for the author of the ``CMakeLists.txt`` files, not errors.

136
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/OPTIONS_HELP.txt Normal file
View File

@ -0,0 +1,136 @@
.. |file| replace:: The help is printed to a named <f>ile if given.
``--help,-help,-usage,-h,-H,/?``
Print usage information and exit.
Usage describes the basic command line interface and its options.
``--version,-version,/V [<f>]``
Show program name/version banner and exit.
If a file is specified, the version is written into it.
|file|
``--help-full [<f>]``
Print all help manuals and exit.
All manuals are printed in a human-readable text format.
|file|
``--help-manual <man> [<f>]``
Print one help manual and exit.
The specified manual is printed in a human-readable text format.
|file|
``--help-manual-list [<f>]``
List help manuals available and exit.
The list contains all manuals for which help may be obtained by
using the ``--help-manual`` option followed by a manual name.
|file|
``--help-command <cmd> [<f>]``
Print help for one command and exit.
The :manual:`cmake-commands(7)` manual entry for ``<cmd>`` is
printed in a human-readable text format.
|file|
``--help-command-list [<f>]``
List commands with help available and exit.
The list contains all commands for which help may be obtained by
using the ``--help-command`` option followed by a command name.
|file|
``--help-commands [<f>]``
Print cmake-commands manual and exit.
The :manual:`cmake-commands(7)` manual is printed in a
human-readable text format.
|file|
``--help-module <mod> [<f>]``
Print help for one module and exit.
The :manual:`cmake-modules(7)` manual entry for ``<mod>`` is printed
in a human-readable text format.
|file|
``--help-module-list [<f>]``
List modules with help available and exit.
The list contains all modules for which help may be obtained by
using the ``--help-module`` option followed by a module name.
|file|
``--help-modules [<f>]``
Print cmake-modules manual and exit.
The :manual:`cmake-modules(7)` manual is printed in a human-readable
text format.
|file|
``--help-policy <cmp> [<f>]``
Print help for one policy and exit.
The :manual:`cmake-policies(7)` manual entry for ``<cmp>`` is
printed in a human-readable text format.
|file|
``--help-policy-list [<f>]``
List policies with help available and exit.
The list contains all policies for which help may be obtained by
using the ``--help-policy`` option followed by a policy name.
|file|
``--help-policies [<f>]``
Print cmake-policies manual and exit.
The :manual:`cmake-policies(7)` manual is printed in a
human-readable text format.
|file|
``--help-property <prop> [<f>]``
Print help for one property and exit.
The :manual:`cmake-properties(7)` manual entries for ``<prop>`` are
printed in a human-readable text format.
|file|
``--help-property-list [<f>]``
List properties with help available and exit.
The list contains all properties for which help may be obtained by
using the ``--help-property`` option followed by a property name.
|file|
``--help-properties [<f>]``
Print cmake-properties manual and exit.
The :manual:`cmake-properties(7)` manual is printed in a
human-readable text format.
|file|
``--help-variable <var> [<f>]``
Print help for one variable and exit.
The :manual:`cmake-variables(7)` manual entry for ``<var>`` is
printed in a human-readable text format.
|file|
``--help-variable-list [<f>]``
List variables with help available and exit.
The list contains all variables for which help may be obtained by
using the ``--help-variable`` option followed by a variable name.
|file|
``--help-variables [<f>]``
Print cmake-variables manual and exit.
The :manual:`cmake-variables(7)` manual is printed in a
human-readable text format.
|file|

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

37
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/ccmake.1.rst Normal file
View File

@ -0,0 +1,37 @@
.. cmake-manual-description: CMake Curses Dialog Command-Line Reference
ccmake(1)
*********
Synopsis
========
.. parsed-literal::
ccmake [<options>] {<path-to-source> | <path-to-existing-build>}
Description
===========
The **ccmake** executable is the CMake curses interface. Project
configuration settings may be specified interactively through this
GUI. Brief instructions are provided at the bottom of the terminal
when the program is running.
CMake is a cross-platform build system generator. Projects specify
their build process with platform-independent CMake listfiles included
in each directory of a source tree with the name ``CMakeLists.txt``.
Users build a project by using CMake to generate a build system for a
native tool on their platform.
Options
=======
.. include:: OPTIONS_BUILD.txt
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

1011
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-buildsystem.7.rst Normal file
View File

File diff suppressed because it is too large Load Diff

173
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-commands.7.rst Normal file
View File

@ -0,0 +1,173 @@
.. cmake-manual-description: CMake Language Command Reference
cmake-commands(7)
*****************
.. only:: html
.. contents::
Scripting Commands
==================
These commands are always available.
.. toctree::
:maxdepth: 1
/command/break
/command/cmake_host_system_information
/command/cmake_language
/command/cmake_minimum_required
/command/cmake_parse_arguments
/command/cmake_policy
/command/configure_file
/command/continue
/command/else
/command/elseif
/command/endforeach
/command/endfunction
/command/endif
/command/endmacro
/command/endwhile
/command/execute_process
/command/file
/command/find_file
/command/find_library
/command/find_package
/command/find_path
/command/find_program
/command/foreach
/command/function
/command/get_cmake_property
/command/get_directory_property
/command/get_filename_component
/command/get_property
/command/if
/command/include
/command/include_guard
/command/list
/command/macro
/command/mark_as_advanced
/command/math
/command/message
/command/option
/command/return
/command/separate_arguments
/command/set
/command/set_directory_properties
/command/set_property
/command/site_name
/command/string
/command/unset
/command/variable_watch
/command/while
Project Commands
================
These commands are available only in CMake projects.
.. toctree::
:maxdepth: 1
/command/add_compile_definitions
/command/add_compile_options
/command/add_custom_command
/command/add_custom_target
/command/add_definitions
/command/add_dependencies
/command/add_executable
/command/add_library
/command/add_link_options
/command/add_subdirectory
/command/add_test
/command/aux_source_directory
/command/build_command
/command/create_test_sourcelist
/command/define_property
/command/enable_language
/command/enable_testing
/command/export
/command/fltk_wrap_ui
/command/get_source_file_property
/command/get_target_property
/command/get_test_property
/command/include_directories
/command/include_external_msproject
/command/include_regular_expression
/command/install
/command/link_directories
/command/link_libraries
/command/load_cache
/command/project
/command/remove_definitions
/command/set_source_files_properties
/command/set_target_properties
/command/set_tests_properties
/command/source_group
/command/target_compile_definitions
/command/target_compile_features
/command/target_compile_options
/command/target_include_directories
/command/target_link_directories
/command/target_link_libraries
/command/target_link_options
/command/target_precompile_headers
/command/target_sources
/command/try_compile
/command/try_run
.. _`CTest Commands`:
CTest Commands
==============
These commands are available only in CTest scripts.
.. toctree::
:maxdepth: 1
/command/ctest_build
/command/ctest_configure
/command/ctest_coverage
/command/ctest_empty_binary_directory
/command/ctest_memcheck
/command/ctest_read_custom_files
/command/ctest_run_script
/command/ctest_sleep
/command/ctest_start
/command/ctest_submit
/command/ctest_test
/command/ctest_update
/command/ctest_upload
Deprecated Commands
===================
These commands are deprecated and are only made available to maintain
backward compatibility. The documentation of each command states the
CMake version in which it was deprecated. Do not use these commands
in new code.
.. toctree::
:maxdepth: 1
/command/build_name
/command/exec_program
/command/export_library_dependencies
/command/install_files
/command/install_programs
/command/install_targets
/command/load_command
/command/make_directory
/command/output_required_files
/command/qt_wrap_cpp
/command/qt_wrap_ui
/command/remove
/command/subdir_depends
/command/subdirs
/command/use_mangled_mesa
/command/utility_source
/command/variable_requires
/command/write_file

376
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-compile-features.7.rst Normal file
View File

@ -0,0 +1,376 @@
.. cmake-manual-description: CMake Compile Features Reference
cmake-compile-features(7)
*************************
.. only:: html
.. contents::
Introduction
============
Project source code may depend on, or be conditional on, the availability
of certain features of the compiler. There are three use-cases which arise:
`Compile Feature Requirements`_, `Optional Compile Features`_
and `Conditional Compilation Options`_.
While features are typically specified in programming language standards,
CMake provides a primary user interface based on granular handling of
the features, not the language standard that introduced the feature.
The :prop_gbl:`CMAKE_C_KNOWN_FEATURES`, :prop_gbl:`CMAKE_CUDA_KNOWN_FEATURES`,
and :prop_gbl:`CMAKE_CXX_KNOWN_FEATURES` global properties contain all the
features known to CMake, regardless of compiler support for the feature.
The :variable:`CMAKE_C_COMPILE_FEATURES`, :variable:`CMAKE_CUDA_COMPILE_FEATURES`
, and :variable:`CMAKE_CXX_COMPILE_FEATURES` variables contain all features
CMake knows are known to the compiler, regardless of language standard
or compile flags needed to use them.
Features known to CMake are named mostly following the same convention
as the Clang feature test macros. There are some exceptions, such as
CMake using ``cxx_final`` and ``cxx_override`` instead of the single
``cxx_override_control`` used by Clang.
Note that there are no separate compile features properties or variables for
the ``OBJC`` or ``OBJCXX`` languages. These are based off ``C`` or ``C++``
respectively, so the properties and variables for their corresponding base
language should be used instead.
Compile Feature Requirements
============================
Compile feature requirements may be specified with the
:command:`target_compile_features` command. For example, if a target must
be compiled with compiler support for the
:prop_gbl:`cxx_constexpr <CMAKE_CXX_KNOWN_FEATURES>` feature:
.. code-block:: cmake
add_library(mylib requires_constexpr.cpp)
target_compile_features(mylib PRIVATE cxx_constexpr)
In processing the requirement for the ``cxx_constexpr`` feature,
:manual:`cmake(1)` will ensure that the in-use C++ compiler is capable
of the feature, and will add any necessary flags such as ``-std=gnu++11``
to the compile lines of C++ files in the ``mylib`` target. A
``FATAL_ERROR`` is issued if the compiler is not capable of the
feature.
The exact compile flags and language standard are deliberately not part
of the user interface for this use-case. CMake will compute the
appropriate compile flags to use by considering the features specified
for each target.
Such compile flags are added even if the compiler supports the
particular feature without the flag. For example, the GNU compiler
supports variadic templates (with a warning) even if ``-std=gnu++98`` is
used. CMake adds the ``-std=gnu++11`` flag if ``cxx_variadic_templates``
is specified as a requirement.
In the above example, ``mylib`` requires ``cxx_constexpr`` when it
is built itself, but consumers of ``mylib`` are not required to use a
compiler which supports ``cxx_constexpr``. If the interface of
``mylib`` does require the ``cxx_constexpr`` feature (or any other
known feature), that may be specified with the ``PUBLIC`` or
``INTERFACE`` signatures of :command:`target_compile_features`:
.. code-block:: cmake
add_library(mylib requires_constexpr.cpp)
# cxx_constexpr is a usage-requirement
target_compile_features(mylib PUBLIC cxx_constexpr)
# main.cpp will be compiled with -std=gnu++11 on GNU for cxx_constexpr.
add_executable(myexe main.cpp)
target_link_libraries(myexe mylib)
Feature requirements are evaluated transitively by consuming the link
implementation. See :manual:`cmake-buildsystem(7)` for more on
transitive behavior of build properties and usage requirements.
Requiring Language Standards
----------------------------
In projects that use a large number of commonly available features from
a particular language standard (e.g. C++ 11) one may specify a
meta-feature (e.g. ``cxx_std_11``) that requires use of a compiler mode
that is at minimum aware of that standard, but could be greater.
This is simpler than specifying all the features individually, but does
not guarantee the existence of any particular feature.
Diagnosis of use of unsupported features will be delayed until compile time.
For example, if C++ 11 features are used extensively in a project's
header files, then clients must use a compiler mode that is no less
than C++ 11. This can be requested with the code:
.. code-block:: cmake
target_compile_features(mylib PUBLIC cxx_std_11)
In this example, CMake will ensure the compiler is invoked in a mode
of at-least C++ 11 (or C++ 14, C++ 17, ...), adding flags such as
``-std=gnu++11`` if necessary. This applies to sources within ``mylib``
as well as any dependents (that may include headers from ``mylib``).
Availability of Compiler Extensions
-----------------------------------
Because the :prop_tgt:`CXX_EXTENSIONS` target property is ``ON`` by default,
CMake uses extended variants of language dialects by default, such as
``-std=gnu++11`` instead of ``-std=c++11``. That target property may be
set to ``OFF`` to use the non-extended variant of the dialect flag. Note
that because most compilers enable extensions by default, this could
expose cross-platform bugs in user code or in the headers of third-party
dependencies.
Optional Compile Features
=========================
Compile features may be preferred if available, without creating a hard
requirement. For example, a library may provides alternative
implementations depending on whether the ``cxx_variadic_templates``
feature is available:
.. code-block:: c++
#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
template<int I, int... Is>
struct Interface;
template<int I>
struct Interface<I>
{
static int accumulate()
{
return I;
}
};
template<int I, int... Is>
struct Interface
{
static int accumulate()
{
return I + Interface<Is...>::accumulate();
}
};
#else
template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
struct Interface
{
static int accumulate() { return I1 + I2 + I3 + I4; }
};
#endif
Such an interface depends on using the correct preprocessor defines for the
compiler features. CMake can generate a header file containing such
defines using the :module:`WriteCompilerDetectionHeader` module. The
module contains the ``write_compiler_detection_header`` function which
accepts parameters to control the content of the generated header file:
.. code-block:: cmake
write_compiler_detection_header(
FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
PREFIX Foo
COMPILERS GNU
FEATURES
cxx_variadic_templates
)
Such a header file may be used internally in the source code of a project,
and it may be installed and used in the interface of library code.
For each feature listed in ``FEATURES``, a preprocessor definition
is created in the header file, and defined to either ``1`` or ``0``.
Additionally, some features call for additional defines, such as the
``cxx_final`` and ``cxx_override`` features. Rather than being used in
``#ifdef`` code, the ``final`` keyword is abstracted by a symbol
which is defined to either ``final``, a compiler-specific equivalent, or
to empty. That way, C++ code can be written to unconditionally use the
symbol, and compiler support determines what it is expanded to:
.. code-block:: c++
struct Interface {
virtual void Execute() = 0;
};
struct Concrete Foo_FINAL {
void Execute() Foo_OVERRIDE;
};
In this case, ``Foo_FINAL`` will expand to ``final`` if the
compiler supports the keyword, or to empty otherwise.
In this use-case, the CMake code will wish to enable a particular language
standard if available from the compiler. The :prop_tgt:`CXX_STANDARD`
target property variable may be set to the desired language standard
for a particular target, and the :variable:`CMAKE_CXX_STANDARD` may be
set to influence all following targets:
.. code-block:: cmake
write_compiler_detection_header(
FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
PREFIX Foo
COMPILERS GNU
FEATURES
cxx_final cxx_override
)
# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
# which will expand to 'final' if the compiler supports the requested
# CXX_STANDARD.
add_library(foo foo.cpp)
set_property(TARGET foo PROPERTY CXX_STANDARD 11)
# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
# which will expand to 'final' if the compiler supports the feature,
# even though CXX_STANDARD is not set explicitly. The requirement of
# cxx_constexpr causes CMake to set CXX_STANDARD internally, which
# affects the compile flags.
add_library(foo_impl foo_impl.cpp)
target_compile_features(foo_impl PRIVATE cxx_constexpr)
The ``write_compiler_detection_header`` function also creates compatibility
code for other features which have standard equivalents. For example, the
``cxx_static_assert`` feature is emulated with a template and abstracted
via the ``<PREFIX>_STATIC_ASSERT`` and ``<PREFIX>_STATIC_ASSERT_MSG``
function-macros.
Conditional Compilation Options
===============================
Libraries may provide entirely different header files depending on
requested compiler features.
For example, a header at ``with_variadics/interface.h`` may contain:
.. code-block:: c++
template<int I, int... Is>
struct Interface;
template<int I>
struct Interface<I>
{
static int accumulate()
{
return I;
}
};
template<int I, int... Is>
struct Interface
{
static int accumulate()
{
return I + Interface<Is...>::accumulate();
}
};
while a header at ``no_variadics/interface.h`` may contain:
.. code-block:: c++
template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
struct Interface
{
static int accumulate() { return I1 + I2 + I3 + I4; }
};
It would be possible to write a abstraction ``interface.h`` header
containing something like:
.. code-block:: c++
#include "foo_compiler_detection.h"
#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
#include "with_variadics/interface.h"
#else
#include "no_variadics/interface.h"
#endif
However this could be unmaintainable if there are many files to
abstract. What is needed is to use alternative include directories
depending on the compiler capabilities.
CMake provides a ``COMPILE_FEATURES``
:manual:`generator expression <cmake-generator-expressions(7)>` to implement
such conditions. This may be used with the build-property commands such as
:command:`target_include_directories` and :command:`target_link_libraries`
to set the appropriate :manual:`buildsystem <cmake-buildsystem(7)>`
properties:
.. code-block:: cmake
add_library(foo INTERFACE)
set(with_variadics ${CMAKE_CURRENT_SOURCE_DIR}/with_variadics)
set(no_variadics ${CMAKE_CURRENT_SOURCE_DIR}/no_variadics)
target_include_directories(foo
INTERFACE
"$<$<COMPILE_FEATURES:cxx_variadic_templates>:${with_variadics}>"
"$<$<NOT:$<COMPILE_FEATURES:cxx_variadic_templates>>:${no_variadics}>"
)
Consuming code then simply links to the ``foo`` target as usual and uses
the feature-appropriate include directory
.. code-block:: cmake
add_executable(consumer_with consumer_with.cpp)
target_link_libraries(consumer_with foo)
set_property(TARGET consumer_with CXX_STANDARD 11)
add_executable(consumer_no consumer_no.cpp)
target_link_libraries(consumer_no foo)
Supported Compilers
===================
CMake is currently aware of the :prop_tgt:`C++ standards <CXX_STANDARD>`
and :prop_gbl:`compile features <CMAKE_CXX_KNOWN_FEATURES>` available from
the following :variable:`compiler ids <CMAKE_<LANG>_COMPILER_ID>` as of the
versions specified for each:
* ``AppleClang``: Apple Clang for Xcode versions 4.4+.
* ``Clang``: Clang compiler versions 2.9+.
* ``GNU``: GNU compiler versions 4.4+.
* ``MSVC``: Microsoft Visual Studio versions 2010+.
* ``SunPro``: Oracle SolarisStudio versions 12.4+.
* ``Intel``: Intel compiler versions 12.1+.
CMake is currently aware of the :prop_tgt:`C standards <C_STANDARD>`
and :prop_gbl:`compile features <CMAKE_C_KNOWN_FEATURES>` available from
the following :variable:`compiler ids <CMAKE_<LANG>_COMPILER_ID>` as of the
versions specified for each:
* all compilers and versions listed above for C++.
* ``GNU``: GNU compiler versions 3.4+
CMake is currently aware of the :prop_tgt:`C++ standards <CXX_STANDARD>` and
their associated meta-features (e.g. ``cxx_std_11``) available from the
following :variable:`compiler ids <CMAKE_<LANG>_COMPILER_ID>` as of the
versions specified for each:
* ``Cray``: Cray Compiler Environment version 8.1+.
* ``PGI``: PGI version 12.10+.
* ``XL``: IBM XL version 10.1+.
CMake is currently aware of the :prop_tgt:`C standards <C_STANDARD>` and
their associated meta-features (e.g. ``c_std_99``) available from the
following :variable:`compiler ids <CMAKE_<LANG>_COMPILER_ID>` as of the
versions specified for each:
* all compilers and versions listed above with only meta-features for C++.
* ``TI``: Texas Instruments compiler.
CMake is currently aware of the :prop_tgt:`CUDA standards <CUDA_STANDARD>` and
their associated meta-features (e.g. ``cuda_std_11``) available from the
following :variable:`compiler ids <CMAKE_<LANG>_COMPILER_ID>` as of the
versions specified for each:
* ``NVIDIA``: NVIDIA nvcc compiler 7.5+.

433
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-developer.7.rst Normal file
View File

@ -0,0 +1,433 @@
.. cmake-manual-description: CMake Developer Reference
cmake-developer(7)
******************
.. only:: html
.. contents::
Introduction
============
This manual is intended for reference by developers working with
:manual:`cmake-language(7)` code, whether writing their own modules,
authoring their own build systems, or working on CMake itself.
See https://cmake.org/get-involved/ to get involved in development of
CMake upstream. It includes links to contribution instructions, which
in turn link to developer guides for CMake itself.
.. _`Find Modules`:
Find Modules
============
A "find module" is a ``Find<PackageName>.cmake`` file to be loaded
by the :command:`find_package` command when invoked for ``<PackageName>``.
The primary task of a find module is to determine whether a package
exists on the system, set the ``<PackageName>_FOUND`` variable to reflect
this and provide any variables, macros and imported targets required to
use the package. A find module is useful in cases where an upstream
library does not provide a
:ref:`config file package <Config File Packages>`.
The traditional approach is to use variables for everything, including
libraries and executables: see the `Standard Variable Names`_ section
below. This is what most of the existing find modules provided by CMake
do.
The more modern approach is to behave as much like
:ref:`config file packages <Config File Packages>` files as possible, by
providing :ref:`imported target <Imported targets>`. This has the advantage
of propagating :ref:`Target Usage Requirements` to consumers.
In either case (or even when providing both variables and imported
targets), find modules should provide backwards compatibility with old
versions that had the same name.
A FindFoo.cmake module will typically be loaded by the command::
find_package(Foo [major[.minor[.patch[.tweak]]]]
[EXACT] [QUIET] [REQUIRED]
[[COMPONENTS] [components...]]
[OPTIONAL_COMPONENTS components...]
[NO_POLICY_SCOPE])
See the :command:`find_package` documentation for details on what
variables are set for the find module. Most of these are dealt with by
using :module:`FindPackageHandleStandardArgs`.
Briefly, the module should only locate versions of the package
compatible with the requested version, as described by the
``Foo_FIND_VERSION`` family of variables. If ``Foo_FIND_QUIETLY`` is
set to true, it should avoid printing messages, including anything
complaining about the package not being found. If ``Foo_FIND_REQUIRED``
is set to true, the module should issue a ``FATAL_ERROR`` if the package
cannot be found. If neither are set to true, it should print a
non-fatal message if it cannot find the package.
Packages that find multiple semi-independent parts (like bundles of
libraries) should search for the components listed in
``Foo_FIND_COMPONENTS`` if it is set , and only set ``Foo_FOUND`` to
true if for each searched-for component ``<c>`` that was not found,
``Foo_FIND_REQUIRED_<c>`` is not set to true. The ``HANDLE_COMPONENTS``
argument of ``find_package_handle_standard_args()`` can be used to
implement this.
If ``Foo_FIND_COMPONENTS`` is not set, which modules are searched for
and required is up to the find module, but should be documented.
For internal implementation, it is a generally accepted convention that
variables starting with underscore are for temporary use only.
.. _`CMake Developer Standard Variable Names`:
Standard Variable Names
-----------------------
For a ``FindXxx.cmake`` module that takes the approach of setting
variables (either instead of or in addition to creating imported
targets), the following variable names should be used to keep things
consistent between find modules. Note that all variables start with
``Xxx_`` to make sure they do not interfere with other find modules; the
same consideration applies to macros, functions and imported targets.
``Xxx_INCLUDE_DIRS``
The final set of include directories listed in one variable for use by
client code. This should not be a cache entry.
``Xxx_LIBRARIES``
The libraries to link against to use Xxx. These should include full
paths. This should not be a cache entry.
``Xxx_DEFINITIONS``
Definitions to use when compiling code that uses Xxx. This really
shouldn't include options such as ``-DHAS_JPEG`` that a client
source-code file uses to decide whether to ``#include <jpeg.h>``
``Xxx_EXECUTABLE``
Where to find the Xxx tool.
``Xxx_Yyy_EXECUTABLE``
Where to find the Yyy tool that comes with Xxx.
``Xxx_LIBRARY_DIRS``
Optionally, the final set of library directories listed in one
variable for use by client code. This should not be a cache entry.
``Xxx_ROOT_DIR``
Where to find the base directory of Xxx.
``Xxx_VERSION_Yy``
Expect Version Yy if true. Make sure at most one of these is ever true.
``Xxx_WRAP_Yy``
If False, do not try to use the relevant CMake wrapping command.
``Xxx_Yy_FOUND``
If False, optional Yy part of Xxx system is not available.
``Xxx_FOUND``
Set to false, or undefined, if we haven't found, or don't want to use
Xxx.
``Xxx_NOT_FOUND_MESSAGE``
Should be set by config-files in the case that it has set
``Xxx_FOUND`` to FALSE. The contained message will be printed by the
:command:`find_package` command and by
``find_package_handle_standard_args()`` to inform the user about the
problem.
``Xxx_RUNTIME_LIBRARY_DIRS``
Optionally, the runtime library search path for use when running an
executable linked to shared libraries. The list should be used by
user code to create the ``PATH`` on windows or ``LD_LIBRARY_PATH`` on
UNIX. This should not be a cache entry.
``Xxx_VERSION``
The full version string of the package found, if any. Note that many
existing modules provide ``Xxx_VERSION_STRING`` instead.
``Xxx_VERSION_MAJOR``
The major version of the package found, if any.
``Xxx_VERSION_MINOR``
The minor version of the package found, if any.
``Xxx_VERSION_PATCH``
The patch version of the package found, if any.
The following names should not usually be used in CMakeLists.txt files, but
are typically cache variables for users to edit and control the
behaviour of find modules (like entering the path to a library manually)
``Xxx_LIBRARY``
The path of the Xxx library (as used with :command:`find_library`, for
example).
``Xxx_Yy_LIBRARY``
The path of the Yy library that is part of the Xxx system. It may or
may not be required to use Xxx.
``Xxx_INCLUDE_DIR``
Where to find headers for using the Xxx library.
``Xxx_Yy_INCLUDE_DIR``
Where to find headers for using the Yy library of the Xxx system.
To prevent users being overwhelmed with settings to configure, try to
keep as many options as possible out of the cache, leaving at least one
option which can be used to disable use of the module, or locate a
not-found library (e.g. ``Xxx_ROOT_DIR``). For the same reason, mark
most cache options as advanced. For packages which provide both debug
and release binaries, it is common to create cache variables with a
``_LIBRARY_<CONFIG>`` suffix, such as ``Foo_LIBRARY_RELEASE`` and
``Foo_LIBRARY_DEBUG``.
While these are the standard variable names, you should provide
backwards compatibility for any old names that were actually in use.
Make sure you comment them as deprecated, so that no-one starts using
them.
A Sample Find Module
--------------------
We will describe how to create a simple find module for a library ``Foo``.
The top of the module should begin with a license notice, followed by
a blank line, and then followed by a :ref:`Bracket Comment`. The comment
should begin with ``.rst:`` to indicate that the rest of its content is
reStructuredText-format documentation. For example:
::
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file Copyright.txt or https://cmake.org/licensing for details.
#[=======================================================================[.rst:
FindFoo
-------
Finds the Foo library.
Imported Targets
^^^^^^^^^^^^^^^^
This module provides the following imported targets, if found:
``Foo::Foo``
The Foo library
Result Variables
^^^^^^^^^^^^^^^^
This will define the following variables:
``Foo_FOUND``
True if the system has the Foo library.
``Foo_VERSION``
The version of the Foo library which was found.
``Foo_INCLUDE_DIRS``
Include directories needed to use Foo.
``Foo_LIBRARIES``
Libraries needed to link to Foo.
Cache Variables
^^^^^^^^^^^^^^^
The following cache variables may also be set:
``Foo_INCLUDE_DIR``
The directory containing ``foo.h``.
``Foo_LIBRARY``
The path to the Foo library.
#]=======================================================================]
The module documentation consists of:
* An underlined heading specifying the module name.
* A simple description of what the module finds.
More description may be required for some packages. If there are
caveats or other details users of the module should be aware of,
specify them here.
* A section listing imported targets provided by the module, if any.
* A section listing result variables provided by the module.
* Optionally a section listing cache variables used by the module, if any.
If the package provides any macros or functions, they should be listed in
an additional section, but can be documented by additional ``.rst:``
comment blocks immediately above where those macros or functions are defined.
The find module implementation may begin below the documentation block.
Now the actual libraries and so on have to be found. The code here will
obviously vary from module to module (dealing with that, after all, is the
point of find modules), but there tends to be a common pattern for libraries.
First, we try to use ``pkg-config`` to find the library. Note that we
cannot rely on this, as it may not be available, but it provides a good
starting point.
.. code-block:: cmake
find_package(PkgConfig)
pkg_check_modules(PC_Foo QUIET Foo)
This should define some variables starting ``PC_Foo_`` that contain the
information from the ``Foo.pc`` file.
Now we need to find the libraries and include files; we use the
information from ``pkg-config`` to provide hints to CMake about where to
look.
.. code-block:: cmake
find_path(Foo_INCLUDE_DIR
NAMES foo.h
PATHS ${PC_Foo_INCLUDE_DIRS}
PATH_SUFFIXES Foo
)
find_library(Foo_LIBRARY
NAMES foo
PATHS ${PC_Foo_LIBRARY_DIRS}
)
If you have a good way of getting the version (from a header file, for
example), you can use that information to set ``Foo_VERSION`` (although
note that find modules have traditionally used ``Foo_VERSION_STRING``,
so you may want to set both). Otherwise, attempt to use the information
from ``pkg-config``
.. code-block:: cmake
set(Foo_VERSION ${PC_Foo_VERSION})
Now we can use :module:`FindPackageHandleStandardArgs` to do most of the
rest of the work for us
.. code-block:: cmake
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Foo
FOUND_VAR Foo_FOUND
REQUIRED_VARS
Foo_LIBRARY
Foo_INCLUDE_DIR
VERSION_VAR Foo_VERSION
)
This will check that the ``REQUIRED_VARS`` contain values (that do not
end in ``-NOTFOUND``) and set ``Foo_FOUND`` appropriately. It will also
cache those values. If ``Foo_VERSION`` is set, and a required version
was passed to :command:`find_package`, it will check the requested version
against the one in ``Foo_VERSION``. It will also print messages as
appropriate; note that if the package was found, it will print the
contents of the first required variable to indicate where it was found.
At this point, we have to provide a way for users of the find module to
link to the library or libraries that were found. There are two
approaches, as discussed in the `Find Modules`_ section above. The
traditional variable approach looks like
.. code-block:: cmake
if(Foo_FOUND)
set(Foo_LIBRARIES ${Foo_LIBRARY})
set(Foo_INCLUDE_DIRS ${Foo_INCLUDE_DIR})
set(Foo_DEFINITIONS ${PC_Foo_CFLAGS_OTHER})
endif()
If more than one library was found, all of them should be included in
these variables (see the `Standard Variable Names`_ section for more
information).
When providing imported targets, these should be namespaced (hence the
``Foo::`` prefix); CMake will recognize that values passed to
:command:`target_link_libraries` that contain ``::`` in their name are
supposed to be imported targets (rather than just library names), and
will produce appropriate diagnostic messages if that target does not
exist (see policy :policy:`CMP0028`).
.. code-block:: cmake
if(Foo_FOUND AND NOT TARGET Foo::Foo)
add_library(Foo::Foo UNKNOWN IMPORTED)
set_target_properties(Foo::Foo PROPERTIES
IMPORTED_LOCATION "${Foo_LIBRARY}"
INTERFACE_COMPILE_OPTIONS "${PC_Foo_CFLAGS_OTHER}"
INTERFACE_INCLUDE_DIRECTORIES "${Foo_INCLUDE_DIR}"
)
endif()
One thing to note about this is that the ``INTERFACE_INCLUDE_DIRECTORIES`` and
similar properties should only contain information about the target itself, and
not any of its dependencies. Instead, those dependencies should also be
targets, and CMake should be told that they are dependencies of this target.
CMake will then combine all the necessary information automatically.
The type of the :prop_tgt:`IMPORTED` target created in the
:command:`add_library` command can always be specified as ``UNKNOWN``
type. This simplifies the code in cases where static or shared variants may
be found, and CMake will determine the type by inspecting the files.
If the library is available with multiple configurations, the
:prop_tgt:`IMPORTED_CONFIGURATIONS` target property should also be
populated:
.. code-block:: cmake
if(Foo_FOUND)
if (NOT TARGET Foo::Foo)
add_library(Foo::Foo UNKNOWN IMPORTED)
endif()
if (Foo_LIBRARY_RELEASE)
set_property(TARGET Foo::Foo APPEND PROPERTY
IMPORTED_CONFIGURATIONS RELEASE
)
set_target_properties(Foo::Foo PROPERTIES
IMPORTED_LOCATION_RELEASE "${Foo_LIBRARY_RELEASE}"
)
endif()
if (Foo_LIBRARY_DEBUG)
set_property(TARGET Foo::Foo APPEND PROPERTY
IMPORTED_CONFIGURATIONS DEBUG
)
set_target_properties(Foo::Foo PROPERTIES
IMPORTED_LOCATION_DEBUG "${Foo_LIBRARY_DEBUG}"
)
endif()
set_target_properties(Foo::Foo PROPERTIES
INTERFACE_COMPILE_OPTIONS "${PC_Foo_CFLAGS_OTHER}"
INTERFACE_INCLUDE_DIRECTORIES "${Foo_INCLUDE_DIR}"
)
endif()
The ``RELEASE`` variant should be listed first in the property
so that the variant is chosen if the user uses a configuration which is
not an exact match for any listed ``IMPORTED_CONFIGURATIONS``.
Most of the cache variables should be hidden in the ``ccmake`` interface unless
the user explicitly asks to edit them.
.. code-block:: cmake
mark_as_advanced(
Foo_INCLUDE_DIR
Foo_LIBRARY
)
If this module replaces an older version, you should set compatibility variables
to cause the least disruption possible.
.. code-block:: cmake
# compatibility variables
set(Foo_VERSION_STRING ${Foo_VERSION})

92
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-env-variables.7.rst Normal file
View File

@ -0,0 +1,92 @@
.. cmake-manual-description: CMake Environment Variables Reference
cmake-env-variables(7)
**********************
.. only:: html
.. contents::
This page lists environment variables that have special
meaning to CMake.
For general information on environment variables, see the
:ref:`Environment Variables <CMake Language Environment Variables>`
section in the cmake-language manual.
Environment Variables that Change Behavior
==========================================
.. toctree::
:maxdepth: 1
/envvar/CMAKE_PREFIX_PATH
Environment Variables that Control the Build
============================================
.. toctree::
:maxdepth: 1
/envvar/CMAKE_BUILD_PARALLEL_LEVEL
/envvar/CMAKE_CONFIG_TYPE
/envvar/CMAKE_EXPORT_COMPILE_COMMANDS
/envvar/CMAKE_GENERATOR
/envvar/CMAKE_GENERATOR_INSTANCE
/envvar/CMAKE_GENERATOR_PLATFORM
/envvar/CMAKE_GENERATOR_TOOLSET
/envvar/CMAKE_LANG_COMPILER_LAUNCHER
/envvar/CMAKE_MSVCIDE_RUN_PATH
/envvar/CMAKE_NO_VERBOSE
/envvar/CMAKE_OSX_ARCHITECTURES
/envvar/DESTDIR
/envvar/LDFLAGS
/envvar/MACOSX_DEPLOYMENT_TARGET
/envvar/PackageName_ROOT
/envvar/VERBOSE
Environment Variables for Languages
===================================
.. toctree::
:maxdepth: 1
/envvar/ASM_DIALECT
/envvar/ASM_DIALECTFLAGS
/envvar/CC
/envvar/CFLAGS
/envvar/CSFLAGS
/envvar/CUDACXX
/envvar/CUDAFLAGS
/envvar/CUDAHOSTCXX
/envvar/CXX
/envvar/CXXFLAGS
/envvar/FC
/envvar/FFLAGS
/envvar/OBJC
/envvar/OBJCXX
/envvar/RC
/envvar/RCFLAGS
/envvar/SWIFTC
Environment Variables for CTest
===============================
.. toctree::
:maxdepth: 1
/envvar/CMAKE_CONFIG_TYPE
/envvar/CTEST_INTERACTIVE_DEBUG_MODE
/envvar/CTEST_OUTPUT_ON_FAILURE
/envvar/CTEST_PARALLEL_LEVEL
/envvar/CTEST_PROGRESS_OUTPUT
/envvar/CTEST_USE_LAUNCHERS_DEFAULT
/envvar/DASHBOARD_TEST_FROM_CTEST
Environment Variables for the CMake curses interface
====================================================
.. toctree::
:maxdepth: 1
/envvar/CCMAKE_COLORS

1135
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-file-api.7.rst Normal file
View File

File diff suppressed because it is too large Load Diff

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

@ -0,0 +1,791 @@
.. 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 "$<...>")

118
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-generators.7.rst Normal file
View File

@ -0,0 +1,118 @@
.. cmake-manual-description: CMake Generators Reference
cmake-generators(7)
*******************
.. only:: html
.. contents::
Introduction
============
A *CMake Generator* is responsible for writing the input files for
a native build system. Exactly one of the `CMake Generators`_ must be
selected for a build tree to determine what native build system is to
be used. Optionally one of the `Extra Generators`_ may be selected
as a variant of some of the `Command-Line Build Tool Generators`_ to
produce project files for an auxiliary IDE.
CMake Generators are platform-specific so each may be available only
on certain platforms. The :manual:`cmake(1)` command-line tool ``--help``
output lists available generators on the current platform. Use its ``-G``
option to specify the generator for a new build tree.
The :manual:`cmake-gui(1)` offers interactive selection of a generator
when creating a new build tree.
CMake Generators
================
.. _`Command-Line Build Tool Generators`:
Command-Line Build Tool Generators
----------------------------------
These generators support command-line build tools. In order to use them,
one must launch CMake from a command-line prompt whose environment is
already configured for the chosen compiler and build tool.
.. _`Makefile Generators`:
Makefile Generators
^^^^^^^^^^^^^^^^^^^
.. toctree::
:maxdepth: 1
/generator/Borland Makefiles
/generator/MSYS Makefiles
/generator/MinGW Makefiles
/generator/NMake Makefiles
/generator/NMake Makefiles JOM
/generator/Unix Makefiles
/generator/Watcom WMake
Ninja Generators
^^^^^^^^^^^^^^^^
.. toctree::
:maxdepth: 1
/generator/Ninja
/generator/Ninja Multi-Config
.. _`IDE Build Tool Generators`:
IDE Build Tool Generators
-------------------------
These generators support Integrated Development Environment (IDE)
project files. Since the IDEs configure their own environment
one may launch CMake from any environment.
.. _`Visual Studio Generators`:
Visual Studio Generators
^^^^^^^^^^^^^^^^^^^^^^^^
.. toctree::
:maxdepth: 1
/generator/Visual Studio 6
/generator/Visual Studio 7
/generator/Visual Studio 7 .NET 2003
/generator/Visual Studio 8 2005
/generator/Visual Studio 9 2008
/generator/Visual Studio 10 2010
/generator/Visual Studio 11 2012
/generator/Visual Studio 12 2013
/generator/Visual Studio 14 2015
/generator/Visual Studio 15 2017
/generator/Visual Studio 16 2019
Other Generators
^^^^^^^^^^^^^^^^
.. toctree::
:maxdepth: 1
/generator/Green Hills MULTI
/generator/Xcode
Extra Generators
================
Some of the `CMake Generators`_ listed in the :manual:`cmake(1)`
command-line tool ``--help`` output may have variants that specify
an extra generator for an auxiliary IDE tool. Such generator
names have the form ``<extra-generator> - <main-generator>``.
The following extra generators are known to CMake.
.. toctree::
:maxdepth: 1
/generator/CodeBlocks
/generator/CodeLite
/generator/Eclipse CDT4
/generator/Kate
/generator/Sublime Text 2

44
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-gui.1.rst Normal file
View File

@ -0,0 +1,44 @@
.. cmake-manual-description: CMake GUI Command-Line Reference
cmake-gui(1)
************
Synopsis
========
.. parsed-literal::
cmake-gui [<options>]
cmake-gui [<options>] {<path-to-source> | <path-to-existing-build>}
cmake-gui [<options>] -S <path-to-source> -B <path-to-build>
Description
===========
The **cmake-gui** executable is the CMake GUI. Project configuration
settings may be specified interactively. Brief instructions are
provided at the bottom of the window when the program is running.
CMake is a cross-platform build system generator. Projects specify
their build process with platform-independent CMake listfiles included
in each directory of a source tree with the name ``CMakeLists.txt``.
Users build a project by using CMake to generate a build system for a
native tool on their platform.
Options
=======
``-S <path-to-source>``
Path to root directory of the CMake project to build.
``-B <path-to-build>``
Path to directory which CMake will use as the root of build directory.
If the directory doesn't already exist CMake will make it.
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

629
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-language.7.rst Normal file
View File

@ -0,0 +1,629 @@
.. cmake-manual-description: CMake Language Reference
cmake-language(7)
*****************
.. only:: html
.. contents::
Organization
============
CMake input files are written in the "CMake Language" in source files
named ``CMakeLists.txt`` or ending in a ``.cmake`` file name extension.
CMake Language source files in a project are organized into:
* `Directories`_ (``CMakeLists.txt``),
* `Scripts`_ (``<script>.cmake``), and
* `Modules`_ (``<module>.cmake``).
Directories
-----------
When CMake processes a project source tree, the entry point is
a source file called ``CMakeLists.txt`` in the top-level source
directory. This file may contain the entire build specification
or use the :command:`add_subdirectory` command to add subdirectories
to the build. Each subdirectory added by the command must also
contain a ``CMakeLists.txt`` file as the entry point to that
directory. For each source directory whose ``CMakeLists.txt`` file
is processed CMake generates a corresponding directory in the build
tree to act as the default working and output directory.
Scripts
-------
An individual ``<script>.cmake`` source file may be processed
in *script mode* by using the :manual:`cmake(1)` command-line tool
with the ``-P`` option. Script mode simply runs the commands in
the given CMake Language source file and does not generate a
build system. It does not allow CMake commands that define build
targets or actions.
Modules
-------
CMake Language code in either `Directories`_ or `Scripts`_ may
use the :command:`include` command to load a ``<module>.cmake``
source file in the scope of the including context.
See the :manual:`cmake-modules(7)` manual page for documentation
of modules included with the CMake distribution.
Project source trees may also provide their own modules and
specify their location(s) in the :variable:`CMAKE_MODULE_PATH`
variable.
Syntax
======
.. _`CMake Language Encoding`:
Encoding
--------
A CMake Language source file may be written in 7-bit ASCII text for
maximum portability across all supported platforms. Newlines may be
encoded as either ``\n`` or ``\r\n`` but will be converted to ``\n``
as input files are read.
Note that the implementation is 8-bit clean so source files may
be encoded as UTF-8 on platforms with system APIs supporting this
encoding. In addition, CMake 3.2 and above support source files
encoded in UTF-8 on Windows (using UTF-16 to call system APIs).
Furthermore, CMake 3.0 and above allow a leading UTF-8
`Byte-Order Mark`_ in source files.
.. _`Byte-Order Mark`: http://en.wikipedia.org/wiki/Byte_order_mark
Source Files
------------
A CMake Language source file consists of zero or more
`Command Invocations`_ separated by newlines and optionally
spaces and `Comments`_:
.. raw:: latex
\begin{small}
.. productionlist::
file: `file_element`*
file_element: `command_invocation` `line_ending` |
: (`bracket_comment`|`space`)* `line_ending`
line_ending: `line_comment`? `newline`
space: <match '[ \t]+'>
newline: <match '\n'>
.. raw:: latex
\end{small}
Note that any source file line not inside `Command Arguments`_ or
a `Bracket Comment`_ can end in a `Line Comment`_.
.. _`Command Invocations`:
Command Invocations
-------------------
A *command invocation* is a name followed by paren-enclosed arguments
separated by whitespace:
.. raw:: latex
\begin{small}
.. productionlist::
command_invocation: `space`* `identifier` `space`* '(' `arguments` ')'
identifier: <match '[A-Za-z_][A-Za-z0-9_]*'>
arguments: `argument`? `separated_arguments`*
separated_arguments: `separation`+ `argument`? |
: `separation`* '(' `arguments` ')'
separation: `space` | `line_ending`
.. raw:: latex
\end{small}
For example:
.. code-block:: cmake
add_executable(hello world.c)
Command names are case-insensitive.
Nested unquoted parentheses in the arguments must balance.
Each ``(`` or ``)`` is given to the command invocation as
a literal `Unquoted Argument`_. This may be used in calls
to the :command:`if` command to enclose conditions.
For example:
.. code-block:: cmake
if(FALSE AND (FALSE OR TRUE)) # evaluates to FALSE
.. note::
CMake versions prior to 3.0 require command name identifiers
to be at least 2 characters.
CMake versions prior to 2.8.12 silently accept an `Unquoted Argument`_
or a `Quoted Argument`_ immediately following a `Quoted Argument`_ and
not separated by any whitespace. For compatibility, CMake 2.8.12 and
higher accept such code but produce a warning.
Command Arguments
-----------------
There are three types of arguments within `Command Invocations`_:
.. raw:: latex
\begin{small}
.. productionlist::
argument: `bracket_argument` | `quoted_argument` | `unquoted_argument`
.. raw:: latex
\end{small}
.. _`Bracket Argument`:
Bracket Argument
^^^^^^^^^^^^^^^^
A *bracket argument*, inspired by `Lua`_ long bracket syntax,
encloses content between opening and closing "brackets" of the
same length:
.. raw:: latex
\begin{small}
.. productionlist::
bracket_argument: `bracket_open` `bracket_content` `bracket_close`
bracket_open: '[' '='* '['
bracket_content: <any text not containing a `bracket_close` with
: the same number of '=' as the `bracket_open`>
bracket_close: ']' '='* ']'
.. raw:: latex
\end{small}
An opening bracket is written ``[`` followed by zero or more ``=`` followed
by ``[``. The corresponding closing bracket is written ``]`` followed
by the same number of ``=`` followed by ``]``.
Brackets do not nest. A unique length may always be chosen
for the opening and closing brackets to contain closing brackets
of other lengths.
Bracket argument content consists of all text between the opening
and closing brackets, except that one newline immediately following
the opening bracket, if any, is ignored. No evaluation of the
enclosed content, such as `Escape Sequences`_ or `Variable References`_,
is performed. A bracket argument is always given to the command
invocation as exactly one argument.
.. No code-block syntax highlighting in the following example
(long string literal not supported by our cmake.py)
For example::
message([=[
This is the first line in a bracket argument with bracket length 1.
No \-escape sequences or ${variable} references are evaluated.
This is always one argument even though it contains a ; character.
The text does not end on a closing bracket of length 0 like ]].
It does end in a closing bracket of length 1.
]=])
.. note::
CMake versions prior to 3.0 do not support bracket arguments.
They interpret the opening bracket as the start of an
`Unquoted Argument`_.
.. _`Lua`: http://www.lua.org/
.. _`Quoted Argument`:
Quoted Argument
^^^^^^^^^^^^^^^
A *quoted argument* encloses content between opening and closing
double-quote characters:
.. raw:: latex
\begin{small}
.. productionlist::
quoted_argument: '"' `quoted_element`* '"'
quoted_element: <any character except '\' or '"'> |
: `escape_sequence` |
: `quoted_continuation`
quoted_continuation: '\' `newline`
.. raw:: latex
\end{small}
Quoted argument content consists of all text between opening and
closing quotes. Both `Escape Sequences`_ and `Variable References`_
are evaluated. A quoted argument is always given to the command
invocation as exactly one argument.
.. No code-block syntax highlighting in the following example
(escape \" not supported by our cmake.py)
For example:
.. code-block:: cmake
message("This is a quoted argument containing multiple lines.
This is always one argument even though it contains a ; character.
Both \\-escape sequences and ${variable} references are evaluated.
The text does not end on an escaped double-quote like \".
It does end in an unescaped double quote.
")
.. No code-block syntax highlighting in the following example
(for conformity with the two above examples)
The final ``\`` on any line ending in an odd number of backslashes
is treated as a line continuation and ignored along with the
immediately following newline character. For example:
.. code-block:: cmake
message("\
This is the first line of a quoted argument. \
In fact it is the only line but since it is long \
the source code uses line continuation.\
")
.. note::
CMake versions prior to 3.0 do not support continuation with ``\``.
They report errors in quoted arguments containing lines ending in
an odd number of ``\`` characters.
.. _`Unquoted Argument`:
Unquoted Argument
^^^^^^^^^^^^^^^^^
An *unquoted argument* is not enclosed by any quoting syntax.
It may not contain any whitespace, ``(``, ``)``, ``#``, ``"``, or ``\``
except when escaped by a backslash:
.. raw:: latex
\begin{small}
.. productionlist::
unquoted_argument: `unquoted_element`+ | `unquoted_legacy`
unquoted_element: <any character except whitespace or one of '()#"\'> |
: `escape_sequence`
unquoted_legacy: <see note in text>
.. raw:: latex
\end{small}
Unquoted argument content consists of all text in a contiguous block
of allowed or escaped characters. Both `Escape Sequences`_ and
`Variable References`_ are evaluated. The resulting value is divided
in the same way `Lists`_ divide into elements. Each non-empty element
is given to the command invocation as an argument. Therefore an
unquoted argument may be given to a command invocation as zero or
more arguments.
For example:
.. code-block:: cmake
foreach(arg
NoSpace
Escaped\ Space
This;Divides;Into;Five;Arguments
Escaped\;Semicolon
)
message("${arg}")
endforeach()
.. note::
To support legacy CMake code, unquoted arguments may also contain
double-quoted strings (``"..."``, possibly enclosing horizontal
whitespace), and make-style variable references (``$(MAKEVAR)``).
Unescaped double-quotes must balance, may not appear at the
beginning of an unquoted argument, and are treated as part of the
content. For example, the unquoted arguments ``-Da="b c"``,
``-Da=$(v)``, and ``a" "b"c"d`` are each interpreted literally.
They may instead be written as quoted arguments ``"-Da=\"b c\""``,
``"-Da=$(v)"``, and ``"a\" \"b\"c\"d"``, respectively.
Make-style references are treated literally as part of the content
and do not undergo variable expansion. They are treated as part
of a single argument (rather than as separate ``$``, ``(``,
``MAKEVAR``, and ``)`` arguments).
The above "unquoted_legacy" production represents such arguments.
We do not recommend using legacy unquoted arguments in new code.
Instead use a `Quoted Argument`_ or a `Bracket Argument`_ to
represent the content.
.. _`Escape Sequences`:
Escape Sequences
----------------
An *escape sequence* is a ``\`` followed by one character:
.. raw:: latex
\begin{small}
.. productionlist::
escape_sequence: `escape_identity` | `escape_encoded` | `escape_semicolon`
escape_identity: '\' <match '[^A-Za-z0-9;]'>
escape_encoded: '\t' | '\r' | '\n'
escape_semicolon: '\;'
.. raw:: latex
\end{small}
A ``\`` followed by a non-alphanumeric character simply encodes the literal
character without interpreting it as syntax. A ``\t``, ``\r``, or ``\n``
encodes a tab, carriage return, or newline character, respectively. A ``\;``
outside of any `Variable References`_ encodes itself but may be used in an
`Unquoted Argument`_ to encode the ``;`` without dividing the argument
value on it. A ``\;`` inside `Variable References`_ encodes the literal
``;`` character. (See also policy :policy:`CMP0053` documentation for
historical considerations.)
.. _`Variable References`:
Variable References
-------------------
A *variable reference* has the form ``${<variable>}`` and is
evaluated inside a `Quoted Argument`_ or an `Unquoted Argument`_.
A variable reference is replaced by the value of the variable,
or by the empty string if the variable is not set.
Variable references can nest and are evaluated from the
inside out, e.g. ``${outer_${inner_variable}_variable}``.
Literal variable references may consist of alphanumeric characters,
the characters ``/_.+-``, and `Escape Sequences`_. Nested references
may be used to evaluate variables of any name. See also policy
:policy:`CMP0053` documentation for historical considerations and reasons why
the ``$`` is also technically permitted but is discouraged.
The `Variables`_ section documents the scope of variable names
and how their values are set.
An *environment variable reference* has the form ``$ENV{<variable>}``.
See the `Environment Variables`_ section for more information.
A *cache variable reference* has the form ``$CACHE{<variable>}``.
See :variable:`CACHE` for more information.
The :command:`if` command has a special condition syntax that
allows for variable references in the short form ``<variable>``
instead of ``${<variable>}``.
However, environment and cache variables always need to be
referenced as ``$ENV{<variable>}`` or ``$CACHE{<variable>}``.
Comments
--------
A comment starts with a ``#`` character that is not inside a
`Bracket Argument`_, `Quoted Argument`_, or escaped with ``\``
as part of an `Unquoted Argument`_. There are two types of
comments: a `Bracket Comment`_ and a `Line Comment`_.
.. _`Bracket Comment`:
Bracket Comment
^^^^^^^^^^^^^^^
A ``#`` immediately followed by a :token:`bracket_open` forms a
*bracket comment* consisting of the entire bracket enclosure:
.. raw:: latex
\begin{small}
.. productionlist::
bracket_comment: '#' `bracket_argument`
.. raw:: latex
\end{small}
For example:
::
#[[This is a bracket comment.
It runs until the close bracket.]]
message("First Argument\n" #[[Bracket Comment]] "Second Argument")
.. note::
CMake versions prior to 3.0 do not support bracket comments.
They interpret the opening ``#`` as the start of a `Line Comment`_.
.. _`Line Comment`:
Line Comment
^^^^^^^^^^^^
A ``#`` not immediately followed by a :token:`bracket_open` forms a
*line comment* that runs until the end of the line:
.. raw:: latex
\begin{small}
.. productionlist::
line_comment: '#' <any text not starting in a `bracket_open`
: and not containing a `newline`>
.. raw:: latex
\end{small}
For example:
.. code-block:: cmake
# This is a line comment.
message("First Argument\n" # This is a line comment :)
"Second Argument") # This is a line comment.
Control Structures
==================
Conditional Blocks
------------------
The :command:`if`/:command:`elseif`/:command:`else`/:command:`endif`
commands delimit code blocks to be executed conditionally.
Loops
-----
The :command:`foreach`/:command:`endforeach` and
:command:`while`/:command:`endwhile` commands delimit code
blocks to be executed in a loop. Inside such blocks the
:command:`break` command may be used to terminate the loop
early whereas the :command:`continue` command may be used
to start with the next iteration immediately.
Command Definitions
-------------------
The :command:`macro`/:command:`endmacro`, and
:command:`function`/:command:`endfunction` commands delimit
code blocks to be recorded for later invocation as commands.
.. _`CMake Language Variables`:
Variables
=========
Variables are the basic unit of storage in the CMake Language.
Their values are always of string type, though some commands may
interpret the strings as values of other types.
The :command:`set` and :command:`unset` commands explicitly
set or unset a variable, but other commands have semantics
that modify variables as well.
Variable names are case-sensitive and may consist of almost
any text, but we recommend sticking to names consisting only
of alphanumeric characters plus ``_`` and ``-``.
Variables have dynamic scope. Each variable "set" or "unset"
creates a binding in the current scope:
Function Scope
`Command Definitions`_ created by the :command:`function` command
create commands that, when invoked, process the recorded commands
in a new variable binding scope. A variable "set" or "unset"
binds in this scope and is visible for the current function and
any nested calls within it, but not after the function returns.
Directory Scope
Each of the `Directories`_ in a source tree has its own variable
bindings. Before processing the ``CMakeLists.txt`` file for a
directory, CMake copies all variable bindings currently defined
in the parent directory, if any, to initialize the new directory
scope. CMake `Scripts`_, when processed with ``cmake -P``, bind
variables in one "directory" scope.
A variable "set" or "unset" not inside a function call binds
to the current directory scope.
Persistent Cache
CMake stores a separate set of "cache" variables, or "cache entries",
whose values persist across multiple runs within a project build
tree. Cache entries have an isolated binding scope modified only
by explicit request, such as by the ``CACHE`` option of the
:command:`set` and :command:`unset` commands.
When evaluating `Variable References`_, CMake first searches the
function call stack, if any, for a binding and then falls back
to the binding in the current directory scope, if any. If a
"set" binding is found, its value is used. If an "unset" binding
is found, or no binding is found, CMake then searches for a
cache entry. If a cache entry is found, its value is used.
Otherwise, the variable reference evaluates to an empty string.
The ``$CACHE{VAR}`` syntax can be used to do direct cache entry
lookups.
The :manual:`cmake-variables(7)` manual documents the many variables
that are provided by CMake or have meaning to CMake when set
by project code.
.. include:: ID_RESERVE.txt
.. _`CMake Language Environment Variables`:
Environment Variables
=====================
Environment Variables are like ordinary `Variables`_, with the
following differences:
Scope
Environment variables have global scope in a CMake process.
They are never cached.
References
`Variable References`_ have the form ``$ENV{<variable>}``.
Initialization
Initial values of the CMake environment variables are those of
the calling process.
Values can be changed using the :command:`set` and :command:`unset`
commands.
These commands only affect the running CMake process,
not the system environment at large.
Changed values are not written back to the calling process,
and they are not seen by subsequent build or test processes.
The :manual:`cmake-env-variables(7)` manual documents environment
variables that have special meaning to CMake.
.. _`CMake Language Lists`:
Lists
=====
Although all values in CMake are stored as strings, a string
may be treated as a list in certain contexts, such as during
evaluation of an `Unquoted Argument`_. In such contexts, a string
is divided into list elements by splitting on ``;`` characters not
following an unequal number of ``[`` and ``]`` characters and not
immediately preceded by a ``\``. The sequence ``\;`` does not
divide a value but is replaced by ``;`` in the resulting element.
A list of elements is represented as a string by concatenating
the elements separated by ``;``. For example, the :command:`set`
command stores multiple values into the destination variable
as a list:
.. code-block:: cmake
set(srcs a.c b.c c.c) # sets "srcs" to "a.c;b.c;c.c"
Lists are meant for simple use cases such as a list of source
files and should not be used for complex data processing tasks.
Most commands that construct lists do not escape ``;`` characters
in list elements, thus flattening nested lists:
.. code-block:: cmake
set(x a "b;c") # sets "x" to "a;b;c", not "a;b\;c"

319
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-modules.7.rst Normal file
View File

@ -0,0 +1,319 @@
.. cmake-manual-description: CMake Modules Reference
cmake-modules(7)
****************
The modules listed here are part of the CMake distribution.
Projects may provide further modules; their location(s)
can be specified in the :variable:`CMAKE_MODULE_PATH` variable.
Utility Modules
^^^^^^^^^^^^^^^
These modules are loaded using the :command:`include` command.
.. toctree::
:maxdepth: 1
/module/AddFileDependencies
/module/AndroidTestUtilities
/module/BundleUtilities
/module/CheckCCompilerFlag
/module/CheckCSourceCompiles
/module/CheckCSourceRuns
/module/CheckCXXCompilerFlag
/module/CheckCXXSourceCompiles
/module/CheckCXXSourceRuns
/module/CheckCXXSymbolExists
/module/CheckFortranCompilerFlag
/module/CheckFortranFunctionExists
/module/CheckFortranSourceCompiles
/module/CheckFortranSourceRuns
/module/CheckFunctionExists
/module/CheckIPOSupported
/module/CheckIncludeFileCXX
/module/CheckIncludeFile
/module/CheckIncludeFiles
/module/CheckLanguage
/module/CheckLibraryExists
/module/CheckLinkerFlag
/module/CheckOBJCCompilerFlag
/module/CheckOBJCSourceCompiles
/module/CheckOBJCSourceRuns
/module/CheckOBJCXXCompilerFlag
/module/CheckOBJCXXSourceCompiles
/module/CheckOBJCXXSourceRuns
/module/CheckPIESupported
/module/CheckPrototypeDefinition
/module/CheckStructHasMember
/module/CheckSymbolExists
/module/CheckTypeSize
/module/CheckVariableExists
/module/CMakeAddFortranSubdirectory
/module/CMakeBackwardCompatibilityCXX
/module/CMakeDependentOption
/module/CMakeFindDependencyMacro
/module/CMakeFindFrameworks
/module/CMakeFindPackageMode
/module/CMakeGraphVizOptions
/module/CMakePackageConfigHelpers
/module/CMakePrintHelpers
/module/CMakePrintSystemInformation
/module/CMakePushCheckState
/module/CMakeVerifyManifest
/module/CPackComponent
/module/CPackIFW
/module/CPackIFWConfigureFile
/module/CPack
/module/CSharpUtilities
/module/CTest
/module/CTestCoverageCollectGCOV
/module/CTestScriptMode
/module/CTestUseLaunchers
/module/Dart
/module/DeployQt4
/module/Documentation
/module/ExternalData
/module/ExternalProject
/module/FeatureSummary
/module/FetchContent
/module/FindPackageHandleStandardArgs
/module/FindPackageMessage
/module/FortranCInterface
/module/GenerateExportHeader
/module/GetPrerequisites
/module/GNUInstallDirs
/module/GoogleTest
/module/InstallRequiredSystemLibraries
/module/ProcessorCount
/module/SelectLibraryConfigurations
/module/SquishTestScript
/module/TestBigEndian
/module/TestForANSIForScope
/module/TestForANSIStreamHeaders
/module/TestForSSTREAM
/module/TestForSTDNamespace
/module/UseEcos
/module/UseJavaClassFilelist
/module/UseJava
/module/UseJavaSymlinks
/module/UseSWIG
/module/UsewxWidgets
/module/WriteCompilerDetectionHeader
Find Modules
^^^^^^^^^^^^
These modules search for third-party software.
They are normally called through the :command:`find_package` command.
.. toctree::
:maxdepth: 1
/module/FindALSA
/module/FindArmadillo
/module/FindASPELL
/module/FindAVIFile
/module/FindBISON
/module/FindBLAS
/module/FindBacktrace
/module/FindBoost
/module/FindBullet
/module/FindBZip2
/module/FindCABLE
/module/FindCoin3D
/module/FindCups
/module/FindCUDAToolkit
/module/FindCURL
/module/FindCurses
/module/FindCVS
/module/FindCxxTest
/module/FindCygwin
/module/FindDart
/module/FindDCMTK
/module/FindDevIL
/module/FindDoxygen
/module/FindEnvModules
/module/FindEXPAT
/module/FindFLEX
/module/FindFLTK2
/module/FindFLTK
/module/FindFontconfig
/module/FindFreetype
/module/FindGCCXML
/module/FindGDAL
/module/FindGettext
/module/FindGIF
/module/FindGit
/module/FindGLEW
/module/FindGLUT
/module/FindGnuplot
/module/FindGnuTLS
/module/FindGSL
/module/FindGTest
/module/FindGTK2
/module/FindGTK
/module/FindHDF5
/module/FindHg
/module/FindHSPELL
/module/FindHTMLHelp
/module/FindIce
/module/FindIcotool
/module/FindICU
/module/FindImageMagick
/module/FindIconv
/module/FindIntl
/module/FindITK
/module/FindJasper
/module/FindJava
/module/FindJNI
/module/FindJPEG
/module/FindKDE3
/module/FindKDE4
/module/FindLAPACK
/module/FindLATEX
/module/FindLibArchive
/module/FindLibinput
/module/FindLibLZMA
/module/FindLibXml2
/module/FindLibXslt
/module/FindLTTngUST
/module/FindLua50
/module/FindLua51
/module/FindLua
/module/FindMatlab
/module/FindMFC
/module/FindMotif
/module/FindMPEG2
/module/FindMPEG
/module/FindMPI
/module/FindODBC
/module/FindOpenACC
/module/FindOpenAL
/module/FindOpenCL
/module/FindOpenGL
/module/FindOpenMP
/module/FindOpenSceneGraph
/module/FindOpenSSL
/module/FindOpenThreads
/module/FindosgAnimation
/module/FindosgDB
/module/Findosg_functions
/module/FindosgFX
/module/FindosgGA
/module/FindosgIntrospection
/module/FindosgManipulator
/module/FindosgParticle
/module/FindosgPresentation
/module/FindosgProducer
/module/FindosgQt
/module/Findosg
/module/FindosgShadow
/module/FindosgSim
/module/FindosgTerrain
/module/FindosgText
/module/FindosgUtil
/module/FindosgViewer
/module/FindosgVolume
/module/FindosgWidget
/module/FindPatch
/module/FindPerlLibs
/module/FindPerl
/module/FindPHP4
/module/FindPhysFS
/module/FindPike
/module/FindPkgConfig
/module/FindPNG
/module/FindPostgreSQL
/module/FindProducer
/module/FindProtobuf
/module/FindPython
/module/FindPython2
/module/FindPython3
/module/FindQt3
/module/FindQt4
/module/FindQuickTime
/module/FindRTI
/module/FindRuby
/module/FindSDL_image
/module/FindSDL_mixer
/module/FindSDL_net
/module/FindSDL
/module/FindSDL_sound
/module/FindSDL_ttf
/module/FindSelfPackers
/module/FindSquish
/module/FindSQLite3
/module/FindSubversion
/module/FindSWIG
/module/FindTCL
/module/FindTclsh
/module/FindTclStub
/module/FindThreads
/module/FindTIFF
/module/FindUnixCommands
/module/FindVTK
/module/FindVulkan
/module/FindWget
/module/FindWish
/module/FindwxWidgets
/module/FindXCTest
/module/FindXalanC
/module/FindXercesC
/module/FindX11
/module/FindXMLRPC
/module/FindZLIB
Deprecated Modules
^^^^^^^^^^^^^^^^^^^
Deprecated Utility Modules
==========================
.. toctree::
:maxdepth: 1
/module/CMakeDetermineVSServicePack
/module/CMakeExpandImportedTargets
/module/CMakeForceCompiler
/module/CMakeParseArguments
/module/MacroAddFileDependencies
/module/TestCXXAcceptsFlag
/module/UsePkgConfig
/module/Use_wxWindows
/module/WriteBasicConfigVersionFile
Deprecated Find Modules
=======================
.. toctree::
:maxdepth: 1
/module/FindCUDA
/module/FindPythonInterp
/module/FindPythonLibs
/module/FindQt
/module/FindwxWindows
Legacy CPack Modules
====================
These modules used to be mistakenly exposed to the user, and have been moved
out of user visibility. They are for CPack internal use, and should never be
used directly.
.. toctree::
:maxdepth: 1
/module/CPackArchive
/module/CPackBundle
/module/CPackCygwin
/module/CPackDeb
/module/CPackDMG
/module/CPackFreeBSD
/module/CPackNSIS
/module/CPackNuGet
/module/CPackPackageMaker
/module/CPackProductBuild
/module/CPackRPM
/module/CPackWIX

719
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-packages.7.rst Normal file
View File

@ -0,0 +1,719 @@
.. cmake-manual-description: CMake Packages Reference
cmake-packages(7)
*****************
.. only:: html
.. contents::
Introduction
============
Packages provide dependency information to CMake based buildsystems. Packages
are found with the :command:`find_package` command. The result of
using :command:`find_package` is either a set of :prop_tgt:`IMPORTED` targets, or
a set of variables corresponding to build-relevant information.
Using Packages
==============
CMake provides direct support for two forms of packages,
`Config-file Packages`_ and `Find-module Packages`_.
Indirect support for ``pkg-config`` packages is also provided via
the :module:`FindPkgConfig` module. In all cases, the basic form
of :command:`find_package` calls is the same:
.. code-block:: cmake
find_package(Qt4 4.7.0 REQUIRED) # CMake provides a Qt4 find-module
find_package(Qt5Core 5.1.0 REQUIRED) # Qt provides a Qt5 package config file.
find_package(LibXml2 REQUIRED) # Use pkg-config via the LibXml2 find-module
In cases where it is known that a package configuration file is provided by
upstream, and only that should be used, the ``CONFIG`` keyword may be passed
to :command:`find_package`:
.. code-block:: cmake
find_package(Qt5Core 5.1.0 CONFIG REQUIRED)
find_package(Qt5Gui 5.1.0 CONFIG)
Similarly, the ``MODULE`` keyword says to use only a find-module:
.. code-block:: cmake
find_package(Qt4 4.7.0 MODULE REQUIRED)
Specifying the type of package explicitly improves the error message shown to
the user if it is not found.
Both types of packages also support specifying components of a package,
either after the ``REQUIRED`` keyword:
.. code-block:: cmake
find_package(Qt5 5.1.0 CONFIG REQUIRED Widgets Xml Sql)
or as a separate ``COMPONENTS`` list:
.. code-block:: cmake
find_package(Qt5 5.1.0 COMPONENTS Widgets Xml Sql)
or as a separate ``OPTIONAL_COMPONENTS`` list:
.. code-block:: cmake
find_package(Qt5 5.1.0 COMPONENTS Widgets
OPTIONAL_COMPONENTS Xml Sql
)
Handling of ``COMPONENTS`` and ``OPTIONAL_COMPONENTS`` is defined by the
package.
By setting the :variable:`CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` variable to
``TRUE``, the ``<PackageName>`` package will not be searched, and will always
be ``NOTFOUND``.
.. _`Config File Packages`:
Config-file Packages
--------------------
A config-file package is a set of files provided by upstreams for downstreams
to use. CMake searches in a number of locations for package configuration files, as
described in the :command:`find_package` documentation. The most simple way for
a CMake user to tell :manual:`cmake(1)` to search in a non-standard prefix for
a package is to set the ``CMAKE_PREFIX_PATH`` cache variable.
Config-file packages are provided by upstream vendors as part of development
packages, that is, they belong with the header files and any other files
provided to assist downstreams in using the package.
A set of variables which provide package status information are also set
automatically when using a config-file package. The ``<PackageName>_FOUND``
variable is set to true or false, depending on whether the package was
found. The ``<PackageName>_DIR`` cache variable is set to the location of the
package configuration file.
Find-module Packages
--------------------
A find module is a file with a set of rules for finding the required pieces of
a dependency, primarily header files and libraries. Typically, a find module
is needed when the upstream is not built with CMake, or is not CMake-aware
enough to otherwise provide a package configuration file. Unlike a package configuration
file, it is not shipped with upstream, but is used by downstream to find the
files by guessing locations of files with platform-specific hints.
Unlike the case of an upstream-provided package configuration file, no single point
of reference identifies the package as being found, so the ``<PackageName>_FOUND``
variable is not automatically set by the :command:`find_package` command. It
can still be expected to be set by convention however and should be set by
the author of the Find-module. Similarly there is no ``<PackageName>_DIR`` variable,
but each of the artifacts such as library locations and header file locations
provide a separate cache variable.
See the :manual:`cmake-developer(7)` manual for more information about creating
Find-module files.
Package Layout
==============
A config-file package consists of a `Package Configuration File`_ and
optionally a `Package Version File`_ provided with the project distribution.
Package Configuration File
--------------------------
Consider a project ``Foo`` that installs the following files::
<prefix>/include/foo-1.2/foo.h
<prefix>/lib/foo-1.2/libfoo.a
It may also provide a CMake package configuration file::
<prefix>/lib/cmake/foo-1.2/FooConfig.cmake
with content defining :prop_tgt:`IMPORTED` targets, or defining variables, such
as:
.. code-block:: cmake
# ...
# (compute PREFIX relative to file location)
# ...
set(Foo_INCLUDE_DIRS ${PREFIX}/include/foo-1.2)
set(Foo_LIBRARIES ${PREFIX}/lib/foo-1.2/libfoo.a)
If another project wishes to use ``Foo`` it need only to locate the ``FooConfig.cmake``
file and load it to get all the information it needs about package content
locations. Since the package configuration file is provided by the package
installation it already knows all the file locations.
The :command:`find_package` command may be used to search for the package
configuration file. This command constructs a set of installation prefixes
and searches under each prefix in several locations. Given the name ``Foo``,
it looks for a file called ``FooConfig.cmake`` or ``foo-config.cmake``.
The full set of locations is specified in the :command:`find_package` command
documentation. One place it looks is::
<prefix>/lib/cmake/Foo*/
where ``Foo*`` is a case-insensitive globbing expression. In our example the
globbing expression will match ``<prefix>/lib/cmake/foo-1.2`` and the package
configuration file will be found.
Once found, a package configuration file is immediately loaded. It, together
with a package version file, contains all the information the project needs to
use the package.
Package Version File
--------------------
When the :command:`find_package` command finds a candidate package configuration
file it looks next to it for a version file. The version file is loaded to test
whether the package version is an acceptable match for the version requested.
If the version file claims compatibility the configuration file is accepted.
Otherwise it is ignored.
The name of the package version file must match that of the package configuration
file but has either ``-version`` or ``Version`` appended to the name before
the ``.cmake`` extension. For example, the files::
<prefix>/lib/cmake/foo-1.3/foo-config.cmake
<prefix>/lib/cmake/foo-1.3/foo-config-version.cmake
and::
<prefix>/lib/cmake/bar-4.2/BarConfig.cmake
<prefix>/lib/cmake/bar-4.2/BarConfigVersion.cmake
are each pairs of package configuration files and corresponding package version
files.
When the :command:`find_package` command loads a version file it first sets the
following variables:
``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 must use these variables to check whether it is compatible or
an exact match for the requested version and set the following variables with
results:
``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
Version files are loaded in a nested scope so they are free to set any variables
they wish as part of their computation. The find_package command wipes out the
scope when the version file has completed and it has checked the output
variables. When the version file claims to be an acceptable match for the
requested version the find_package command sets the following variables for
use by the project:
``<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
The variables report the version of the package that was actually found.
The ``<PackageName>`` part of their name matches the argument given to the
:command:`find_package` command.
.. _`Creating Packages`:
Creating Packages
=================
Usually, the upstream depends on CMake itself and can use some CMake facilities
for creating the package files. Consider an upstream which provides a single
shared library:
.. code-block:: cmake
project(UpstreamLib)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE ON)
set(Upstream_VERSION 3.4.1)
include(GenerateExportHeader)
add_library(ClimbingStats SHARED climbingstats.cpp)
generate_export_header(ClimbingStats)
set_property(TARGET ClimbingStats PROPERTY VERSION ${Upstream_VERSION})
set_property(TARGET ClimbingStats PROPERTY SOVERSION 3)
set_property(TARGET ClimbingStats PROPERTY
INTERFACE_ClimbingStats_MAJOR_VERSION 3)
set_property(TARGET ClimbingStats APPEND PROPERTY
COMPATIBLE_INTERFACE_STRING ClimbingStats_MAJOR_VERSION
)
install(TARGETS ClimbingStats EXPORT ClimbingStatsTargets
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
RUNTIME DESTINATION bin
INCLUDES DESTINATION include
)
install(
FILES
climbingstats.h
"${CMAKE_CURRENT_BINARY_DIR}/climbingstats_export.h"
DESTINATION
include
COMPONENT
Devel
)
include(CMakePackageConfigHelpers)
write_basic_package_version_file(
"${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfigVersion.cmake"
VERSION ${Upstream_VERSION}
COMPATIBILITY AnyNewerVersion
)
export(EXPORT ClimbingStatsTargets
FILE "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsTargets.cmake"
NAMESPACE Upstream::
)
configure_file(cmake/ClimbingStatsConfig.cmake
"${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfig.cmake"
COPYONLY
)
set(ConfigPackageLocation lib/cmake/ClimbingStats)
install(EXPORT ClimbingStatsTargets
FILE
ClimbingStatsTargets.cmake
NAMESPACE
Upstream::
DESTINATION
${ConfigPackageLocation}
)
install(
FILES
cmake/ClimbingStatsConfig.cmake
"${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfigVersion.cmake"
DESTINATION
${ConfigPackageLocation}
COMPONENT
Devel
)
The :module:`CMakePackageConfigHelpers` module provides a macro for creating
a simple ``ConfigVersion.cmake`` file. This file sets the version of the
package. It is read by CMake when :command:`find_package` is called to
determine the compatibility with the requested version, and to set some
version-specific variables ``<PackageName>_VERSION``, ``<PackageName>_VERSION_MAJOR``,
``<PackageName>_VERSION_MINOR`` etc. The :command:`install(EXPORT)` command is
used to export the targets in the ``ClimbingStatsTargets`` export-set, defined
previously by the :command:`install(TARGETS)` command. This command generates
the ``ClimbingStatsTargets.cmake`` file to contain :prop_tgt:`IMPORTED`
targets, suitable for use by downstreams and arranges to install it to
``lib/cmake/ClimbingStats``. The generated ``ClimbingStatsConfigVersion.cmake``
and a ``cmake/ClimbingStatsConfig.cmake`` are installed to the same location,
completing the package.
The generated :prop_tgt:`IMPORTED` targets have appropriate properties set
to define their :ref:`usage requirements <Target Usage Requirements>`, such as
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`,
:prop_tgt:`INTERFACE_COMPILE_DEFINITIONS` and other relevant built-in
``INTERFACE_`` properties. The ``INTERFACE`` variant of user-defined
properties listed in :prop_tgt:`COMPATIBLE_INTERFACE_STRING` and
other :ref:`Compatible Interface Properties` are also propagated to the
generated :prop_tgt:`IMPORTED` targets. In the above case,
``ClimbingStats_MAJOR_VERSION`` is defined as a string which must be
compatible among the dependencies of any depender. By setting this custom
defined user property in this version and in the next version of
``ClimbingStats``, :manual:`cmake(1)` will issue a diagnostic if there is an
attempt to use version 3 together with version 4. Packages can choose to
employ such a pattern if different major versions of the package are designed
to be incompatible.
A ``NAMESPACE`` with double-colons is specified when exporting the targets
for installation. This convention of double-colons gives CMake a hint that
the name is an :prop_tgt:`IMPORTED` target when it is used by downstreams
with the :command:`target_link_libraries` command. This way, CMake can
issue a diagnostic if the package providing it has not yet been found.
In this case, when using :command:`install(TARGETS)` the ``INCLUDES DESTINATION``
was specified. This causes the ``IMPORTED`` targets to have their
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` populated with the ``include``
directory in the :variable:`CMAKE_INSTALL_PREFIX`. When the ``IMPORTED``
target is used by downstream, it automatically consumes the entries from
that property.
Creating a Package Configuration File
-------------------------------------
In this case, the ``ClimbingStatsConfig.cmake`` file could be as simple as:
.. code-block:: cmake
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
As this allows downstreams to use the ``IMPORTED`` targets. If any macros
should be provided by the ``ClimbingStats`` package, they should
be in a separate file which is installed to the same location as the
``ClimbingStatsConfig.cmake`` file, and included from there.
This can also be extended to cover dependencies:
.. code-block:: cmake
# ...
add_library(ClimbingStats SHARED climbingstats.cpp)
generate_export_header(ClimbingStats)
find_package(Stats 2.6.4 REQUIRED)
target_link_libraries(ClimbingStats PUBLIC Stats::Types)
As the ``Stats::Types`` target is a ``PUBLIC`` dependency of ``ClimbingStats``,
downstreams must also find the ``Stats`` package and link to the ``Stats::Types``
library. The ``Stats`` package should be found in the ``ClimbingStatsConfig.cmake``
file to ensure this. The ``find_dependency`` macro from the
:module:`CMakeFindDependencyMacro` helps with this by propagating
whether the package is ``REQUIRED``, or ``QUIET`` etc. All ``REQUIRED``
dependencies of a package should be found in the ``Config.cmake`` file:
.. code-block:: cmake
include(CMakeFindDependencyMacro)
find_dependency(Stats 2.6.4)
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")
The ``find_dependency`` macro also sets ``ClimbingStats_FOUND`` to ``False`` if
the dependency is not found, along with a diagnostic that the ``ClimbingStats``
package can not be used without the ``Stats`` package.
If ``COMPONENTS`` are specified when the downstream uses :command:`find_package`,
they are listed in the ``<PackageName>_FIND_COMPONENTS`` variable. If a particular
component is non-optional, then the ``<PackageName>_FIND_REQUIRED_<comp>`` will
be true. This can be tested with logic in the package configuration file:
.. code-block:: cmake
include(CMakeFindDependencyMacro)
find_dependency(Stats 2.6.4)
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")
set(_supported_components Plot Table)
foreach(_comp ${ClimbingStats_FIND_COMPONENTS})
if (NOT ";${_supported_components};" MATCHES _comp)
set(ClimbingStats_FOUND False)
set(ClimbingStats_NOT_FOUND_MESSAGE "Unsupported component: ${_comp}")
endif()
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStats${_comp}Targets.cmake")
endforeach()
Here, the ``ClimbingStats_NOT_FOUND_MESSAGE`` is set to a diagnosis that the package
could not be found because an invalid component was specified. This message
variable can be set for any case where the ``_FOUND`` variable is set to ``False``,
and will be displayed to the user.
Creating a Package Configuration File for the Build Tree
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The :command:`export(EXPORT)` command creates an :prop_tgt:`IMPORTED` targets
definition file which is specific to the build-tree, and is not relocatable.
This can similarly be used with a suitable package configuration file and
package version file to define a package for the build tree which may be used
without installation. Consumers of the build tree can simply ensure that the
:variable:`CMAKE_PREFIX_PATH` contains the build directory, or set the
``ClimbingStats_DIR`` to ``<build_dir>/ClimbingStats`` in the cache.
.. _`Creating Relocatable Packages`:
Creating Relocatable Packages
-----------------------------
A relocatable package must not reference absolute paths of files on
the machine where the package is built that will not exist on the
machines where the package may be installed.
Packages created by :command:`install(EXPORT)` are designed to be relocatable,
using paths relative to the location of the package itself. When defining
the interface of a target for ``EXPORT``, keep in mind that the include
directories should be specified as relative paths which are relative to the
:variable:`CMAKE_INSTALL_PREFIX`:
.. code-block:: cmake
target_include_directories(tgt INTERFACE
# Wrong, not relocatable:
$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include/TgtName>
)
target_include_directories(tgt INTERFACE
# Ok, relocatable:
$<INSTALL_INTERFACE:include/TgtName>
)
The ``$<INSTALL_PREFIX>``
:manual:`generator expression <cmake-generator-expressions(7)>` may be used as
a placeholder for the install prefix without resulting in a non-relocatable
package. This is necessary if complex generator expressions are used:
.. code-block:: cmake
target_include_directories(tgt INTERFACE
# Ok, relocatable:
$<INSTALL_INTERFACE:$<$<CONFIG:Debug>:$<INSTALL_PREFIX>/include/TgtName>>
)
This also applies to paths referencing external dependencies.
It is not advisable to populate any properties which may contain
paths, such as :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` and
:prop_tgt:`INTERFACE_LINK_LIBRARIES`, with paths relevant to dependencies.
For example, this code may not work well for a relocatable package:
.. code-block:: cmake
target_link_libraries(ClimbingStats INTERFACE
${Foo_LIBRARIES} ${Bar_LIBRARIES}
)
target_include_directories(ClimbingStats INTERFACE
"$<INSTALL_INTERFACE:${Foo_INCLUDE_DIRS};${Bar_INCLUDE_DIRS}>"
)
The referenced variables may contain the absolute paths to libraries
and include directories **as found on the machine the package was made on**.
This would create a package with hard-coded paths to dependencies and not
suitable for relocation.
Ideally such dependencies should be used through their own
:ref:`IMPORTED targets <Imported Targets>` that have their own
:prop_tgt:`IMPORTED_LOCATION` and usage requirement properties
such as :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` populated
appropriately. Those imported targets may then be used with
the :command:`target_link_libraries` command for ``ClimbingStats``:
.. code-block:: cmake
target_link_libraries(ClimbingStats INTERFACE Foo::Foo Bar::Bar)
With this approach the package references its external dependencies
only through the names of :ref:`IMPORTED targets <Imported Targets>`.
When a consumer uses the installed package, the consumer will run the
appropriate :command:`find_package` commands (via the ``find_dependency``
macro described above) to find the dependencies and populate the
imported targets with appropriate paths on their own machine.
Unfortunately many :manual:`modules <cmake-modules(7)>` shipped with
CMake do not yet provide :ref:`IMPORTED targets <Imported Targets>`
because their development pre-dated this approach. This may improve
incrementally over time. Workarounds to create relocatable packages
using such modules include:
* When building the package, specify each ``Foo_LIBRARY`` cache
entry as just a library name, e.g. ``-DFoo_LIBRARY=foo``. This
tells the corresponding find module to populate the ``Foo_LIBRARIES``
with just ``foo`` to ask the linker to search for the library
instead of hard-coding a path.
* Or, after installing the package content but before creating the
package installation binary for redistribution, manually replace
the absolute paths with placeholders for substitution by the
installation tool when the package is installed.
.. _`Package Registry`:
Package Registry
================
CMake provides two central locations to register packages that have
been built or installed anywhere on a system:
* `User Package Registry`_
* `System Package Registry`_
The registries are especially useful to help projects find packages in
non-standard install locations or directly in their own build trees.
A project may populate either the user or system registry (using its own
means, see below) to refer to its location.
In either case the package should store at the registered location a
`Package Configuration File`_ (``<PackageName>Config.cmake``) and optionally a
`Package Version File`_ (``<PackageName>ConfigVersion.cmake``).
The :command:`find_package` command searches the two package registries
as two of the search steps specified in its documentation. If it has
sufficient permissions it also removes stale package registry entries
that refer to directories that do not exist or do not contain a matching
package configuration file.
.. _`User Package Registry`:
User Package Registry
---------------------
The User Package Registry is stored in a per-user location.
The :command:`export(PACKAGE)` command may be used to register a project
build tree in the user package registry. CMake currently provides no
interface to add install trees to the user package registry. Installers
must be manually taught to register their packages if desired.
On Windows the user package registry is stored in the Windows registry
under a key in ``HKEY_CURRENT_USER``.
A ``<PackageName>`` may appear under registry key::
HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\<PackageName>
as a ``REG_SZ`` value, with arbitrary name, that specifies the directory
containing the package configuration file.
On UNIX platforms the user package registry is stored in the user home
directory under ``~/.cmake/packages``. A ``<PackageName>`` may appear under
the directory::
~/.cmake/packages/<PackageName>
as a file, with arbitrary name, whose content specifies the directory
containing the package configuration file.
.. _`System Package Registry`:
System Package Registry
-----------------------
The System Package Registry is stored in a system-wide location.
CMake currently provides no interface to add to the system package registry.
Installers must be manually taught to register their packages if desired.
On Windows the system package registry is stored in the Windows registry
under a key in ``HKEY_LOCAL_MACHINE``. A ``<PackageName>`` may appear under
registry key::
HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<PackageName>
as a ``REG_SZ`` value, with arbitrary name, that specifies the directory
containing the package configuration file.
There is no system package registry on non-Windows platforms.
.. _`Disabling the Package Registry`:
Disabling the Package Registry
------------------------------
In some cases using the Package Registries is not desirable. CMake
allows one to disable them using the following variables:
* The :command:`export(PACKAGE)` command does not populate the user
package registry when :policy:`CMP0090` is set to ``NEW`` unless the
:variable:`CMAKE_EXPORT_PACKAGE_REGISTRY` variable explicitly enables it.
When :policy:`CMP0090` is *not* set to ``NEW`` then
:command:`export(PACKAGE)` populates the user package registry unless
the :variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable explicitly
disables it.
* :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` disables the
User Package Registry in all the :command:`find_package` calls when
set to ``FALSE``.
* Deprecated :variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` disables the
User Package Registry in all the :command:`find_package` calls when set
to ``TRUE``. This variable is ignored when
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` has been set.
* :variable:`CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY` disables
the System Package Registry in all the :command:`find_package` calls.
Package Registry Example
------------------------
A simple convention for naming package registry entries is to use content
hashes. They are deterministic and unlikely to collide
(:command:`export(PACKAGE)` uses this approach).
The name of an entry referencing a specific directory is simply the content
hash of the directory path itself.
If a project arranges for package registry entries to exist, such as::
> reg query HKCU\Software\Kitware\CMake\Packages\MyPackage
HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\MyPackage
45e7d55f13b87179bb12f907c8de6fc4 REG_SZ c:/Users/Me/Work/lib/cmake/MyPackage
7b4a9844f681c80ce93190d4e3185db9 REG_SZ c:/Users/Me/Work/MyPackage-build
or::
$ cat ~/.cmake/packages/MyPackage/7d1fb77e07ce59a81bed093bbee945bd
/home/me/work/lib/cmake/MyPackage
$ cat ~/.cmake/packages/MyPackage/f92c1db873a1937f3100706657c63e07
/home/me/work/MyPackage-build
then the ``CMakeLists.txt`` code:
.. code-block:: cmake
find_package(MyPackage)
will search the registered locations for package configuration files
(``MyPackageConfig.cmake``). The search order among package registry
entries for a single package is unspecified and the entry names
(hashes in this example) have no meaning. Registered locations may
contain package version files (``MyPackageConfigVersion.cmake``) to
tell :command:`find_package` whether a specific location is suitable
for the version requested.
Package Registry Ownership
--------------------------
Package registry entries are individually owned by the project installations
that they reference. A package installer is responsible for adding its own
entry and the corresponding uninstaller is responsible for removing it.
The :command:`export(PACKAGE)` command populates the user package registry
with the location of a project build tree. Build trees tend to be deleted by
developers and have no "uninstall" event that could trigger removal of their
entries. In order to keep the registries clean the :command:`find_package`
command automatically removes stale entries it encounters if it has sufficient
permissions. CMake provides no interface to remove an entry referencing an
existing build tree once :command:`export(PACKAGE)` has been invoked.
However, if the project removes its package configuration file from the build
tree then the entry referencing the location will be considered stale.

295
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-policies.7.rst Normal file
View File

@ -0,0 +1,295 @@
.. cmake-manual-description: CMake Policies Reference
cmake-policies(7)
*****************
.. only:: html
.. contents::
Introduction
============
Policies in CMake are used to preserve backward compatible behavior
across multiple releases. When a new policy is introduced, newer CMake
versions will begin to warn about the backward compatible behavior. It
is possible to disable the warning by explicitly requesting the OLD, or
backward compatible behavior using the :command:`cmake_policy` command.
It is also possible to request ``NEW``, or non-backward compatible behavior
for a policy, also avoiding the warning. Each policy can also be set to
either ``NEW`` or ``OLD`` behavior explicitly on the command line with the
:variable:`CMAKE_POLICY_DEFAULT_CMP<NNNN>` variable.
A policy is a deprecation mechanism and not a reliable feature toggle.
A policy should almost never be set to ``OLD``, except to silence warnings
in an otherwise frozen or stable codebase, or temporarily as part of a
larger migration path. The ``OLD`` behavior of each policy is undesirable
and will be replaced with an error condition in a future release.
The :command:`cmake_minimum_required` command does more than report an
error if a too-old version of CMake is used to build a project. It
also sets all policies introduced in that CMake version or earlier to
``NEW`` behavior. To manage policies without increasing the minimum required
CMake version, the :command:`if(POLICY)` command may be used:
.. code-block:: cmake
if(POLICY CMP0990)
cmake_policy(SET CMP0990 NEW)
endif()
This has the effect of using the ``NEW`` behavior with newer CMake releases which
users may be using and not issuing a compatibility warning.
The setting of a policy is confined in some cases to not propagate to the
parent scope. For example, if the files read by the :command:`include` command
or the :command:`find_package` command contain a use of :command:`cmake_policy`,
that policy setting will not affect the caller by default. Both commands accept
an optional ``NO_POLICY_SCOPE`` keyword to control this behavior.
The :variable:`CMAKE_MINIMUM_REQUIRED_VERSION` variable may also be used
to determine whether to report an error on use of deprecated macros or
functions.
Policies Introduced by CMake 3.18
=================================
.. toctree::
:maxdepth: 1
CMP0108: A target cannot link to itself through an alias. </policy/CMP0108>
CMP0107: An ALIAS target cannot overwrite another target. </policy/CMP0107>
CMP0106: The Documentation module is removed. </policy/CMP0106>
CMP0105: Device link step uses the link options. </policy/CMP0105>
CMP0104: CMAKE_CUDA_ARCHITECTURES now detected for NVCC, empty CUDA_ARCHITECTURES not allowed. </policy/CMP0104>
CMP0103: Multiple export() with same FILE without APPEND is not allowed. </policy/CMP0103>
Policies Introduced by CMake 3.17
=================================
.. toctree::
:maxdepth: 1
CMP0102: mark_as_advanced() does nothing if a cache entry does not exist. </policy/CMP0102>
CMP0101: target_compile_options honors BEFORE keyword in all scopes. </policy/CMP0101>
CMP0100: Let AUTOMOC and AUTOUIC process .hh header files. </policy/CMP0100>
CMP0099: Link properties are transitive over private dependency on static libraries. </policy/CMP0099>
CMP0098: FindFLEX runs flex in CMAKE_CURRENT_BINARY_DIR when executing. </policy/CMP0098>
Policies Introduced by CMake 3.16
=================================
.. toctree::
:maxdepth: 1
CMP0097: ExternalProject_Add with GIT_SUBMODULES "" initializes no submodules. </policy/CMP0097>
CMP0096: project() preserves leading zeros in version components. </policy/CMP0096>
CMP0095: RPATH entries are properly escaped in the intermediary CMake install script. </policy/CMP0095>
Policies Introduced by CMake 3.15
=================================
.. toctree::
:maxdepth: 1
CMP0094: FindPython3, FindPython2 and FindPython use LOCATION for lookup strategy. </policy/CMP0094>
CMP0093: FindBoost reports Boost_VERSION in x.y.z format. </policy/CMP0093>
CMP0092: MSVC warning flags are not in CMAKE_{C,CXX}_FLAGS by default. </policy/CMP0092>
CMP0091: MSVC runtime library flags are selected by an abstraction. </policy/CMP0091>
CMP0090: export(PACKAGE) does not populate package registry by default. </policy/CMP0090>
CMP0089: Compiler id for IBM Clang-based XL compilers is now XLClang. </policy/CMP0089>
Policies Introduced by CMake 3.14
=================================
.. toctree::
:maxdepth: 1
CMP0088: FindBISON runs bison in CMAKE_CURRENT_BINARY_DIR when executing. </policy/CMP0088>
CMP0087: install(SCRIPT | CODE) supports generator expressions. </policy/CMP0087>
CMP0086: UseSWIG honors SWIG_MODULE_NAME via -module flag. </policy/CMP0086>
CMP0085: IN_LIST generator expression handles empty list items. </policy/CMP0085>
CMP0084: The FindQt module does not exist for find_package(). </policy/CMP0084>
CMP0083: Add PIE options when linking executable. </policy/CMP0083>
CMP0082: Install rules from add_subdirectory() are interleaved with those in caller. </policy/CMP0082>
Policies Introduced by CMake 3.13
=================================
.. toctree::
:maxdepth: 1
CMP0081: Relative paths not allowed in LINK_DIRECTORIES target property. </policy/CMP0081>
CMP0080: BundleUtilities cannot be included at configure time. </policy/CMP0080>
CMP0079: target_link_libraries allows use with targets in other directories. </policy/CMP0079>
CMP0078: UseSWIG generates standard target names. </policy/CMP0078>
CMP0077: option() honors normal variables. </policy/CMP0077>
CMP0076: target_sources() command converts relative paths to absolute. </policy/CMP0076>
Policies Introduced by CMake 3.12
=================================
.. toctree::
:maxdepth: 1
CMP0075: Include file check macros honor CMAKE_REQUIRED_LIBRARIES. </policy/CMP0075>
CMP0074: find_package uses PackageName_ROOT variables. </policy/CMP0074>
CMP0073: Do not produce legacy _LIB_DEPENDS cache entries. </policy/CMP0073>
Policies Introduced by CMake 3.11
=================================
.. toctree::
:maxdepth: 1
CMP0072: FindOpenGL prefers GLVND by default when available. </policy/CMP0072>
Policies Introduced by CMake 3.10
=================================
.. toctree::
:maxdepth: 1
CMP0071: Let AUTOMOC and AUTOUIC process GENERATED files. </policy/CMP0071>
CMP0070: Define file(GENERATE) behavior for relative paths. </policy/CMP0070>
Policies Introduced by CMake 3.9
================================
.. toctree::
:maxdepth: 1
CMP0069: INTERPROCEDURAL_OPTIMIZATION is enforced when enabled. </policy/CMP0069>
CMP0068: RPATH settings on macOS do not affect install_name. </policy/CMP0068>
Policies Introduced by CMake 3.8
================================
.. toctree::
:maxdepth: 1
CMP0067: Honor language standard in try_compile() source-file signature. </policy/CMP0067>
Policies Introduced by CMake 3.7
================================
.. toctree::
:maxdepth: 1
CMP0066: Honor per-config flags in try_compile() source-file signature. </policy/CMP0066>
Policies Introduced by CMake 3.4
================================
.. toctree::
:maxdepth: 1
CMP0065: Do not add flags to export symbols from executables without the ENABLE_EXPORTS target property. </policy/CMP0065>
CMP0064: Support new TEST if() operator. </policy/CMP0064>
Policies Introduced by CMake 3.3
================================
.. toctree::
:maxdepth: 1
CMP0063: Honor visibility properties for all target types. </policy/CMP0063>
CMP0062: Disallow install() of export() result. </policy/CMP0062>
CMP0061: CTest does not by default tell make to ignore errors (-i). </policy/CMP0061>
CMP0060: Link libraries by full path even in implicit directories. </policy/CMP0060>
CMP0059: Do not treat DEFINITIONS as a built-in directory property. </policy/CMP0059>
CMP0058: Ninja requires custom command byproducts to be explicit. </policy/CMP0058>
CMP0057: Support new IN_LIST if() operator. </policy/CMP0057>
Policies Introduced by CMake 3.2
================================
.. toctree::
:maxdepth: 1
CMP0056: Honor link flags in try_compile() source-file signature. </policy/CMP0056>
CMP0055: Strict checking for break() command. </policy/CMP0055>
Policies Introduced by CMake 3.1
================================
.. toctree::
:maxdepth: 1
CMP0054: Only interpret if() arguments as variables or keywords when unquoted. </policy/CMP0054>
CMP0053: Simplify variable reference and escape sequence evaluation. </policy/CMP0053>
CMP0052: Reject source and build dirs in installed INTERFACE_INCLUDE_DIRECTORIES. </policy/CMP0052>
CMP0051: List TARGET_OBJECTS in SOURCES target property. </policy/CMP0051>
Policies Introduced by CMake 3.0
================================
.. toctree::
:maxdepth: 1
CMP0050: Disallow add_custom_command SOURCE signatures. </policy/CMP0050>
CMP0049: Do not expand variables in target source entries. </policy/CMP0049>
CMP0048: project() command manages VERSION variables. </policy/CMP0048>
CMP0047: Use QCC compiler id for the qcc drivers on QNX. </policy/CMP0047>
CMP0046: Error on non-existent dependency in add_dependencies. </policy/CMP0046>
CMP0045: Error on non-existent target in get_target_property. </policy/CMP0045>
CMP0044: Case sensitive Lang_COMPILER_ID generator expressions. </policy/CMP0044>
CMP0043: Ignore COMPILE_DEFINITIONS_Config properties. </policy/CMP0043>
CMP0042: MACOSX_RPATH is enabled by default. </policy/CMP0042>
CMP0041: Error on relative include with generator expression. </policy/CMP0041>
CMP0040: The target in the TARGET signature of add_custom_command() must exist. </policy/CMP0040>
CMP0039: Utility targets may not have link dependencies. </policy/CMP0039>
CMP0038: Targets may not link directly to themselves. </policy/CMP0038>
CMP0037: Target names should not be reserved and should match a validity pattern. </policy/CMP0037>
CMP0036: The build_name command should not be called. </policy/CMP0036>
CMP0035: The variable_requires command should not be called. </policy/CMP0035>
CMP0034: The utility_source command should not be called. </policy/CMP0034>
CMP0033: The export_library_dependencies command should not be called. </policy/CMP0033>
CMP0032: The output_required_files command should not be called. </policy/CMP0032>
CMP0031: The load_command command should not be called. </policy/CMP0031>
CMP0030: The use_mangled_mesa command should not be called. </policy/CMP0030>
CMP0029: The subdir_depends command should not be called. </policy/CMP0029>
CMP0028: Double colon in target name means ALIAS or IMPORTED target. </policy/CMP0028>
CMP0027: Conditionally linked imported targets with missing include directories. </policy/CMP0027>
CMP0026: Disallow use of the LOCATION target property. </policy/CMP0026>
CMP0025: Compiler id for Apple Clang is now AppleClang. </policy/CMP0025>
CMP0024: Disallow include export result. </policy/CMP0024>
Policies Introduced by CMake 2.8
================================
.. toctree::
:maxdepth: 1
CMP0023: Plain and keyword target_link_libraries signatures cannot be mixed. </policy/CMP0023>
CMP0022: INTERFACE_LINK_LIBRARIES defines the link interface. </policy/CMP0022>
CMP0021: Fatal error on relative paths in INCLUDE_DIRECTORIES target property. </policy/CMP0021>
CMP0020: Automatically link Qt executables to qtmain target on Windows. </policy/CMP0020>
CMP0019: Do not re-expand variables in include and link information. </policy/CMP0019>
CMP0018: Ignore CMAKE_SHARED_LIBRARY_Lang_FLAGS variable. </policy/CMP0018>
CMP0017: Prefer files from the CMake module directory when including from there. </policy/CMP0017>
CMP0016: target_link_libraries() reports error if its only argument is not a target. </policy/CMP0016>
CMP0015: link_directories() treats paths relative to the source dir. </policy/CMP0015>
CMP0014: Input directories must have CMakeLists.txt. </policy/CMP0014>
CMP0013: Duplicate binary directories are not allowed. </policy/CMP0013>
CMP0012: if() recognizes numbers and boolean constants. </policy/CMP0012>
Policies Introduced by CMake 2.6
================================
.. toctree::
:maxdepth: 1
CMP0011: Included scripts do automatic cmake_policy PUSH and POP. </policy/CMP0011>
CMP0010: Bad variable reference syntax is an error. </policy/CMP0010>
CMP0009: FILE GLOB_RECURSE calls should not follow symlinks by default. </policy/CMP0009>
CMP0008: Libraries linked by full-path must have a valid library file name. </policy/CMP0008>
CMP0007: list command no longer ignores empty elements. </policy/CMP0007>
CMP0006: Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION. </policy/CMP0006>
CMP0005: Preprocessor definition values are now escaped automatically. </policy/CMP0005>
CMP0004: Libraries linked may not have leading or trailing whitespace. </policy/CMP0004>
CMP0003: Libraries linked via full path no longer produce linker search paths. </policy/CMP0003>
CMP0002: Logical target names must be globally unique. </policy/CMP0002>
CMP0001: CMAKE_BACKWARDS_COMPATIBILITY should no longer be used. </policy/CMP0001>
CMP0000: A minimum required CMake version must be specified. </policy/CMP0000>

574
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-properties.7.rst Normal file
View File

@ -0,0 +1,574 @@
.. cmake-manual-description: CMake Properties Reference
cmake-properties(7)
*******************
.. only:: html
.. contents::
.. _`Global Properties`:
Properties of Global Scope
==========================
.. toctree::
:maxdepth: 1
/prop_gbl/ALLOW_DUPLICATE_CUSTOM_TARGETS
/prop_gbl/AUTOGEN_SOURCE_GROUP
/prop_gbl/AUTOGEN_TARGETS_FOLDER
/prop_gbl/AUTOMOC_SOURCE_GROUP
/prop_gbl/AUTOMOC_TARGETS_FOLDER
/prop_gbl/AUTORCC_SOURCE_GROUP
/prop_gbl/CMAKE_C_KNOWN_FEATURES
/prop_gbl/CMAKE_CUDA_KNOWN_FEATURES
/prop_gbl/CMAKE_CXX_KNOWN_FEATURES
/prop_gbl/CMAKE_ROLE
/prop_gbl/DEBUG_CONFIGURATIONS
/prop_gbl/DISABLED_FEATURES
/prop_gbl/ECLIPSE_EXTRA_CPROJECT_CONTENTS
/prop_gbl/ECLIPSE_EXTRA_NATURES
/prop_gbl/ENABLED_FEATURES
/prop_gbl/ENABLED_LANGUAGES
/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS
/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS
/prop_gbl/FIND_LIBRARY_USE_LIBX32_PATHS
/prop_gbl/FIND_LIBRARY_USE_OPENBSD_VERSIONING
/prop_gbl/GENERATOR_IS_MULTI_CONFIG
/prop_gbl/GLOBAL_DEPENDS_DEBUG_MODE
/prop_gbl/GLOBAL_DEPENDS_NO_CYCLES
/prop_gbl/IN_TRY_COMPILE
/prop_gbl/JOB_POOLS
/prop_gbl/PACKAGES_FOUND
/prop_gbl/PACKAGES_NOT_FOUND
/prop_gbl/PREDEFINED_TARGETS_FOLDER
/prop_gbl/REPORT_UNDEFINED_PROPERTIES
/prop_gbl/RULE_LAUNCH_COMPILE
/prop_gbl/RULE_LAUNCH_CUSTOM
/prop_gbl/RULE_LAUNCH_LINK
/prop_gbl/RULE_MESSAGES
/prop_gbl/TARGET_ARCHIVES_MAY_BE_SHARED_LIBS
/prop_gbl/TARGET_MESSAGES
/prop_gbl/TARGET_SUPPORTS_SHARED_LIBS
/prop_gbl/USE_FOLDERS
/prop_gbl/XCODE_EMIT_EFFECTIVE_PLATFORM_NAME
.. _`Directory Properties`:
Properties on Directories
=========================
.. toctree::
:maxdepth: 1
/prop_dir/ADDITIONAL_CLEAN_FILES
/prop_dir/BINARY_DIR
/prop_dir/BUILDSYSTEM_TARGETS
/prop_dir/CACHE_VARIABLES
/prop_dir/CLEAN_NO_CUSTOM
/prop_dir/CMAKE_CONFIGURE_DEPENDS
/prop_dir/COMPILE_DEFINITIONS
/prop_dir/COMPILE_OPTIONS
/prop_dir/DEFINITIONS
/prop_dir/EXCLUDE_FROM_ALL
/prop_dir/IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
/prop_dir/INCLUDE_DIRECTORIES
/prop_dir/INCLUDE_REGULAR_EXPRESSION
/prop_dir/INTERPROCEDURAL_OPTIMIZATION_CONFIG
/prop_dir/INTERPROCEDURAL_OPTIMIZATION
/prop_dir/LABELS
/prop_dir/LINK_DIRECTORIES
/prop_dir/LINK_OPTIONS
/prop_dir/LISTFILE_STACK
/prop_dir/MACROS
/prop_dir/PARENT_DIRECTORY
/prop_dir/RULE_LAUNCH_COMPILE
/prop_dir/RULE_LAUNCH_CUSTOM
/prop_dir/RULE_LAUNCH_LINK
/prop_dir/SOURCE_DIR
/prop_dir/SUBDIRECTORIES
/prop_dir/TESTS
/prop_dir/TEST_INCLUDE_FILES
/prop_dir/VARIABLES
/prop_dir/VS_GLOBAL_SECTION_POST_section
/prop_dir/VS_GLOBAL_SECTION_PRE_section
/prop_dir/VS_STARTUP_PROJECT
.. _`Target Properties`:
Properties on Targets
=====================
.. toctree::
:maxdepth: 1
/prop_tgt/ADDITIONAL_CLEAN_FILES
/prop_tgt/AIX_EXPORT_ALL_SYMBOLS
/prop_tgt/ALIAS_GLOBAL
/prop_tgt/ALIASED_TARGET
/prop_tgt/ANDROID_ANT_ADDITIONAL_OPTIONS
/prop_tgt/ANDROID_API
/prop_tgt/ANDROID_API_MIN
/prop_tgt/ANDROID_ARCH
/prop_tgt/ANDROID_ASSETS_DIRECTORIES
/prop_tgt/ANDROID_GUI
/prop_tgt/ANDROID_JAR_DEPENDENCIES
/prop_tgt/ANDROID_JAR_DIRECTORIES
/prop_tgt/ANDROID_JAVA_SOURCE_DIR
/prop_tgt/ANDROID_NATIVE_LIB_DEPENDENCIES
/prop_tgt/ANDROID_NATIVE_LIB_DIRECTORIES
/prop_tgt/ANDROID_PROCESS_MAX
/prop_tgt/ANDROID_PROGUARD
/prop_tgt/ANDROID_PROGUARD_CONFIG_PATH
/prop_tgt/ANDROID_SECURE_PROPS_PATH
/prop_tgt/ANDROID_SKIP_ANT_STEP
/prop_tgt/ANDROID_STL_TYPE
/prop_tgt/ARCHIVE_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/ARCHIVE_OUTPUT_DIRECTORY
/prop_tgt/ARCHIVE_OUTPUT_NAME_CONFIG
/prop_tgt/ARCHIVE_OUTPUT_NAME
/prop_tgt/AUTOGEN_BUILD_DIR
/prop_tgt/AUTOGEN_ORIGIN_DEPENDS
/prop_tgt/AUTOGEN_PARALLEL
/prop_tgt/AUTOGEN_TARGET_DEPENDS
/prop_tgt/AUTOMOC
/prop_tgt/AUTOMOC_COMPILER_PREDEFINES
/prop_tgt/AUTOMOC_DEPEND_FILTERS
/prop_tgt/AUTOMOC_EXECUTABLE
/prop_tgt/AUTOMOC_MACRO_NAMES
/prop_tgt/AUTOMOC_MOC_OPTIONS
/prop_tgt/AUTOMOC_PATH_PREFIX
/prop_tgt/AUTORCC
/prop_tgt/AUTORCC_EXECUTABLE
/prop_tgt/AUTORCC_OPTIONS
/prop_tgt/AUTOUIC
/prop_tgt/AUTOUIC_EXECUTABLE
/prop_tgt/AUTOUIC_OPTIONS
/prop_tgt/AUTOUIC_SEARCH_PATHS
/prop_tgt/BINARY_DIR
/prop_tgt/BUILD_RPATH
/prop_tgt/BUILD_RPATH_USE_ORIGIN
/prop_tgt/BUILD_WITH_INSTALL_NAME_DIR
/prop_tgt/BUILD_WITH_INSTALL_RPATH
/prop_tgt/BUNDLE_EXTENSION
/prop_tgt/BUNDLE
/prop_tgt/C_EXTENSIONS
/prop_tgt/C_STANDARD
/prop_tgt/C_STANDARD_REQUIRED
/prop_tgt/COMMON_LANGUAGE_RUNTIME
/prop_tgt/COMPATIBLE_INTERFACE_BOOL
/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX
/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN
/prop_tgt/COMPATIBLE_INTERFACE_STRING
/prop_tgt/COMPILE_DEFINITIONS
/prop_tgt/COMPILE_FEATURES
/prop_tgt/COMPILE_FLAGS
/prop_tgt/COMPILE_OPTIONS
/prop_tgt/COMPILE_PDB_NAME
/prop_tgt/COMPILE_PDB_NAME_CONFIG
/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY
/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/CONFIG_OUTPUT_NAME
/prop_tgt/CONFIG_POSTFIX
/prop_tgt/CROSSCOMPILING_EMULATOR
/prop_tgt/CUDA_ARCHITECTURES
/prop_tgt/CUDA_PTX_COMPILATION
/prop_tgt/CUDA_SEPARABLE_COMPILATION
/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS
/prop_tgt/CUDA_RUNTIME_LIBRARY
/prop_tgt/CUDA_EXTENSIONS
/prop_tgt/CUDA_STANDARD
/prop_tgt/CUDA_STANDARD_REQUIRED
/prop_tgt/CXX_EXTENSIONS
/prop_tgt/CXX_STANDARD
/prop_tgt/CXX_STANDARD_REQUIRED
/prop_tgt/DEBUG_POSTFIX
/prop_tgt/DEFINE_SYMBOL
/prop_tgt/DEPLOYMENT_REMOTE_DIRECTORY
/prop_tgt/DEPLOYMENT_ADDITIONAL_FILES
/prop_tgt/DEPRECATION
/prop_tgt/DISABLE_PRECOMPILE_HEADERS
/prop_tgt/DOTNET_TARGET_FRAMEWORK
/prop_tgt/DOTNET_TARGET_FRAMEWORK_VERSION
/prop_tgt/EchoString
/prop_tgt/ENABLE_EXPORTS
/prop_tgt/EXCLUDE_FROM_ALL
/prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD_CONFIG
/prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD
/prop_tgt/EXPORT_NAME
/prop_tgt/EXPORT_PROPERTIES
/prop_tgt/FOLDER
/prop_tgt/Fortran_FORMAT
/prop_tgt/Fortran_MODULE_DIRECTORY
/prop_tgt/Fortran_PREPROCESS
/prop_tgt/FRAMEWORK
/prop_tgt/FRAMEWORK_MULTI_CONFIG_POSTFIX_CONFIG
/prop_tgt/FRAMEWORK_VERSION
/prop_tgt/GENERATOR_FILE_NAME
/prop_tgt/GHS_INTEGRITY_APP
/prop_tgt/GHS_NO_SOURCE_GROUP_FILE
/prop_tgt/GNUtoMS
/prop_tgt/HAS_CXX
/prop_tgt/IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
/prop_tgt/IMPORTED_COMMON_LANGUAGE_RUNTIME
/prop_tgt/IMPORTED_CONFIGURATIONS
/prop_tgt/IMPORTED_GLOBAL
/prop_tgt/IMPORTED_IMPLIB_CONFIG
/prop_tgt/IMPORTED_IMPLIB
/prop_tgt/IMPORTED_LIBNAME_CONFIG
/prop_tgt/IMPORTED_LIBNAME
/prop_tgt/IMPORTED_LINK_DEPENDENT_LIBRARIES_CONFIG
/prop_tgt/IMPORTED_LINK_DEPENDENT_LIBRARIES
/prop_tgt/IMPORTED_LINK_INTERFACE_LANGUAGES_CONFIG
/prop_tgt/IMPORTED_LINK_INTERFACE_LANGUAGES
/prop_tgt/IMPORTED_LINK_INTERFACE_LIBRARIES_CONFIG
/prop_tgt/IMPORTED_LINK_INTERFACE_LIBRARIES
/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY_CONFIG
/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY
/prop_tgt/IMPORTED_LOCATION_CONFIG
/prop_tgt/IMPORTED_LOCATION
/prop_tgt/IMPORTED_NO_SONAME_CONFIG
/prop_tgt/IMPORTED_NO_SONAME
/prop_tgt/IMPORTED_OBJECTS_CONFIG
/prop_tgt/IMPORTED_OBJECTS
/prop_tgt/IMPORTED
/prop_tgt/IMPORTED_SONAME_CONFIG
/prop_tgt/IMPORTED_SONAME
/prop_tgt/IMPORT_PREFIX
/prop_tgt/IMPORT_SUFFIX
/prop_tgt/INCLUDE_DIRECTORIES
/prop_tgt/INSTALL_NAME_DIR
/prop_tgt/INSTALL_REMOVE_ENVIRONMENT_RPATH
/prop_tgt/INSTALL_RPATH
/prop_tgt/INSTALL_RPATH_USE_LINK_PATH
/prop_tgt/INTERFACE_AUTOUIC_OPTIONS
/prop_tgt/INTERFACE_COMPILE_DEFINITIONS
/prop_tgt/INTERFACE_COMPILE_FEATURES
/prop_tgt/INTERFACE_COMPILE_OPTIONS
/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES
/prop_tgt/INTERFACE_LINK_DEPENDS
/prop_tgt/INTERFACE_LINK_DIRECTORIES
/prop_tgt/INTERFACE_LINK_LIBRARIES
/prop_tgt/INTERFACE_LINK_OPTIONS
/prop_tgt/INTERFACE_PRECOMPILE_HEADERS
/prop_tgt/INTERFACE_POSITION_INDEPENDENT_CODE
/prop_tgt/INTERFACE_SOURCES
/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
/prop_tgt/INTERPROCEDURAL_OPTIMIZATION_CONFIG
/prop_tgt/INTERPROCEDURAL_OPTIMIZATION
/prop_tgt/IOS_INSTALL_COMBINED
/prop_tgt/JOB_POOL_COMPILE
/prop_tgt/JOB_POOL_LINK
/prop_tgt/JOB_POOL_PRECOMPILE_HEADER
/prop_tgt/LABELS
/prop_tgt/LANG_CLANG_TIDY
/prop_tgt/LANG_COMPILER_LAUNCHER
/prop_tgt/LANG_CPPCHECK
/prop_tgt/LANG_CPPLINT
/prop_tgt/LANG_INCLUDE_WHAT_YOU_USE
/prop_tgt/LANG_VISIBILITY_PRESET
/prop_tgt/LIBRARY_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/LIBRARY_OUTPUT_DIRECTORY
/prop_tgt/LIBRARY_OUTPUT_NAME_CONFIG
/prop_tgt/LIBRARY_OUTPUT_NAME
/prop_tgt/LINK_DEPENDS_NO_SHARED
/prop_tgt/LINK_DEPENDS
/prop_tgt/LINKER_LANGUAGE
/prop_tgt/LINK_DIRECTORIES
/prop_tgt/LINK_FLAGS_CONFIG
/prop_tgt/LINK_FLAGS
/prop_tgt/LINK_INTERFACE_LIBRARIES_CONFIG
/prop_tgt/LINK_INTERFACE_LIBRARIES
/prop_tgt/LINK_INTERFACE_MULTIPLICITY_CONFIG
/prop_tgt/LINK_INTERFACE_MULTIPLICITY
/prop_tgt/LINK_LIBRARIES
/prop_tgt/LINK_OPTIONS
/prop_tgt/LINK_SEARCH_END_STATIC
/prop_tgt/LINK_SEARCH_START_STATIC
/prop_tgt/LINK_WHAT_YOU_USE
/prop_tgt/LOCATION_CONFIG
/prop_tgt/LOCATION
/prop_tgt/MACHO_COMPATIBILITY_VERSION
/prop_tgt/MACHO_CURRENT_VERSION
/prop_tgt/MACOSX_BUNDLE_INFO_PLIST
/prop_tgt/MACOSX_BUNDLE
/prop_tgt/MACOSX_FRAMEWORK_INFO_PLIST
/prop_tgt/MACOSX_RPATH
/prop_tgt/MANUALLY_ADDED_DEPENDENCIES
/prop_tgt/MAP_IMPORTED_CONFIG_CONFIG
/prop_tgt/MSVC_RUNTIME_LIBRARY
/prop_tgt/NAME
/prop_tgt/NO_SONAME
/prop_tgt/NO_SYSTEM_FROM_IMPORTED
/prop_tgt/OBJC_EXTENSIONS
/prop_tgt/OBJC_STANDARD
/prop_tgt/OBJC_STANDARD_REQUIRED
/prop_tgt/OBJCXX_EXTENSIONS
/prop_tgt/OBJCXX_STANDARD
/prop_tgt/OBJCXX_STANDARD_REQUIRED
/prop_tgt/OSX_ARCHITECTURES_CONFIG
/prop_tgt/OSX_ARCHITECTURES
/prop_tgt/OUTPUT_NAME_CONFIG
/prop_tgt/OUTPUT_NAME
/prop_tgt/PCH_WARN_INVALID
/prop_tgt/PDB_NAME_CONFIG
/prop_tgt/PDB_NAME
/prop_tgt/PDB_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/PDB_OUTPUT_DIRECTORY
/prop_tgt/POSITION_INDEPENDENT_CODE
/prop_tgt/PRECOMPILE_HEADERS
/prop_tgt/PRECOMPILE_HEADERS_REUSE_FROM
/prop_tgt/PREFIX
/prop_tgt/PRIVATE_HEADER
/prop_tgt/PROJECT_LABEL
/prop_tgt/PUBLIC_HEADER
/prop_tgt/RESOURCE
/prop_tgt/RULE_LAUNCH_COMPILE
/prop_tgt/RULE_LAUNCH_CUSTOM
/prop_tgt/RULE_LAUNCH_LINK
/prop_tgt/RUNTIME_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/RUNTIME_OUTPUT_DIRECTORY
/prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG
/prop_tgt/RUNTIME_OUTPUT_NAME
/prop_tgt/SKIP_BUILD_RPATH
/prop_tgt/SOURCE_DIR
/prop_tgt/SOURCES
/prop_tgt/SOVERSION
/prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG
/prop_tgt/STATIC_LIBRARY_FLAGS
/prop_tgt/STATIC_LIBRARY_OPTIONS
/prop_tgt/SUFFIX
/prop_tgt/Swift_DEPENDENCIES_FILE
/prop_tgt/Swift_LANGUAGE_VERSION
/prop_tgt/Swift_MODULE_DIRECTORY
/prop_tgt/Swift_MODULE_NAME
/prop_tgt/TYPE
/prop_tgt/UNITY_BUILD
/prop_tgt/UNITY_BUILD_BATCH_SIZE
/prop_tgt/UNITY_BUILD_CODE_AFTER_INCLUDE
/prop_tgt/UNITY_BUILD_CODE_BEFORE_INCLUDE
/prop_tgt/UNITY_BUILD_MODE
/prop_tgt/VERSION
/prop_tgt/VISIBILITY_INLINES_HIDDEN
/prop_tgt/VS_CONFIGURATION_TYPE
/prop_tgt/VS_DEBUGGER_COMMAND
/prop_tgt/VS_DEBUGGER_COMMAND_ARGUMENTS
/prop_tgt/VS_DEBUGGER_ENVIRONMENT
/prop_tgt/VS_DEBUGGER_WORKING_DIRECTORY
/prop_tgt/VS_DESKTOP_EXTENSIONS_VERSION
/prop_tgt/VS_DOTNET_REFERENCE_refname
/prop_tgt/VS_DOTNET_REFERENCEPROP_refname_TAG_tagname
/prop_tgt/VS_DOTNET_REFERENCES
/prop_tgt/VS_DOTNET_REFERENCES_COPY_LOCAL
/prop_tgt/VS_DOTNET_TARGET_FRAMEWORK_VERSION
/prop_tgt/VS_DOTNET_DOCUMENTATION_FILE
/prop_tgt/VS_DPI_AWARE
/prop_tgt/VS_GLOBAL_KEYWORD
/prop_tgt/VS_GLOBAL_PROJECT_TYPES
/prop_tgt/VS_GLOBAL_ROOTNAMESPACE
/prop_tgt/VS_GLOBAL_variable
/prop_tgt/VS_IOT_EXTENSIONS_VERSION
/prop_tgt/VS_IOT_STARTUP_TASK
/prop_tgt/VS_JUST_MY_CODE_DEBUGGING
/prop_tgt/VS_KEYWORD
/prop_tgt/VS_MOBILE_EXTENSIONS_VERSION
/prop_tgt/VS_NO_SOLUTION_DEPLOY
/prop_tgt/VS_PACKAGE_REFERENCES
/prop_tgt/VS_PLATFORM_TOOLSET
/prop_tgt/VS_PROJECT_IMPORT
/prop_tgt/VS_SCC_AUXPATH
/prop_tgt/VS_SCC_LOCALPATH
/prop_tgt/VS_SCC_PROJECTNAME
/prop_tgt/VS_SCC_PROVIDER
/prop_tgt/VS_SDK_REFERENCES
/prop_tgt/VS_SOLUTION_DEPLOY
/prop_tgt/VS_SOURCE_SETTINGS_tool
/prop_tgt/VS_USER_PROPS
/prop_tgt/VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
/prop_tgt/VS_WINRT_COMPONENT
/prop_tgt/VS_WINRT_EXTENSIONS
/prop_tgt/VS_WINRT_REFERENCES
/prop_tgt/WIN32_EXECUTABLE
/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS
/prop_tgt/XCODE_ATTRIBUTE_an-attribute
/prop_tgt/XCODE_EXPLICIT_FILE_TYPE
/prop_tgt/XCODE_GENERATE_SCHEME
/prop_tgt/XCODE_PRODUCT_TYPE
/prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER
/prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
/prop_tgt/XCODE_SCHEME_ARGUMENTS
/prop_tgt/XCODE_SCHEME_DEBUG_AS_ROOT
/prop_tgt/XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING
/prop_tgt/XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
/prop_tgt/XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
/prop_tgt/XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
/prop_tgt/XCODE_SCHEME_ENVIRONMENT
/prop_tgt/XCODE_SCHEME_EXECUTABLE
/prop_tgt/XCODE_SCHEME_GUARD_MALLOC
/prop_tgt/XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
/prop_tgt/XCODE_SCHEME_MALLOC_GUARD_EDGES
/prop_tgt/XCODE_SCHEME_MALLOC_SCRIBBLE
/prop_tgt/XCODE_SCHEME_MALLOC_STACK
/prop_tgt/XCODE_SCHEME_THREAD_SANITIZER
/prop_tgt/XCODE_SCHEME_THREAD_SANITIZER_STOP
/prop_tgt/XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
/prop_tgt/XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
/prop_tgt/XCODE_SCHEME_WORKING_DIRECTORY
/prop_tgt/XCODE_SCHEME_ZOMBIE_OBJECTS
/prop_tgt/XCTEST
.. _`Test Properties`:
Properties on Tests
===================
.. toctree::
:maxdepth: 1
/prop_test/ATTACHED_FILES_ON_FAIL
/prop_test/ATTACHED_FILES
/prop_test/COST
/prop_test/DEPENDS
/prop_test/DISABLED
/prop_test/ENVIRONMENT
/prop_test/FAIL_REGULAR_EXPRESSION
/prop_test/FIXTURES_CLEANUP
/prop_test/FIXTURES_REQUIRED
/prop_test/FIXTURES_SETUP
/prop_test/LABELS
/prop_test/MEASUREMENT
/prop_test/PASS_REGULAR_EXPRESSION
/prop_test/PROCESSOR_AFFINITY
/prop_test/PROCESSORS
/prop_test/REQUIRED_FILES
/prop_test/RESOURCE_GROUPS
/prop_test/RESOURCE_LOCK
/prop_test/RUN_SERIAL
/prop_test/SKIP_REGULAR_EXPRESSION
/prop_test/SKIP_RETURN_CODE
/prop_test/TIMEOUT
/prop_test/TIMEOUT_AFTER_MATCH
/prop_test/WILL_FAIL
/prop_test/WORKING_DIRECTORY
.. _`Source File Properties`:
Properties on Source Files
==========================
.. toctree::
:maxdepth: 1
/prop_sf/ABSTRACT
/prop_sf/AUTORCC_OPTIONS
/prop_sf/AUTOUIC_OPTIONS
/prop_sf/COMPILE_DEFINITIONS
/prop_sf/COMPILE_FLAGS
/prop_sf/COMPILE_OPTIONS
/prop_sf/EXTERNAL_OBJECT
/prop_sf/Fortran_FORMAT
/prop_sf/Fortran_PREPROCESS
/prop_sf/GENERATED
/prop_sf/HEADER_FILE_ONLY
/prop_sf/INCLUDE_DIRECTORIES
/prop_sf/KEEP_EXTENSION
/prop_sf/LABELS
/prop_sf/LANGUAGE
/prop_sf/LOCATION
/prop_sf/MACOSX_PACKAGE_LOCATION
/prop_sf/OBJECT_DEPENDS
/prop_sf/OBJECT_OUTPUTS
/prop_sf/SKIP_AUTOGEN
/prop_sf/SKIP_AUTOMOC
/prop_sf/SKIP_AUTORCC
/prop_sf/SKIP_AUTOUIC
/prop_sf/SKIP_PRECOMPILE_HEADERS
/prop_sf/SKIP_UNITY_BUILD_INCLUSION
/prop_sf/Swift_DEPENDENCIES_FILE
/prop_sf/Swift_DIAGNOSTICS_FILE
/prop_sf/SYMBOLIC
/prop_sf/UNITY_GROUP
/prop_sf/VS_COPY_TO_OUT_DIR
/prop_sf/VS_CSHARP_tagname
/prop_sf/VS_DEPLOYMENT_CONTENT
/prop_sf/VS_DEPLOYMENT_LOCATION
/prop_sf/VS_INCLUDE_IN_VSIX
/prop_sf/VS_RESOURCE_GENERATOR
/prop_sf/VS_SETTINGS
/prop_sf/VS_SHADER_DISABLE_OPTIMIZATIONS
/prop_sf/VS_SHADER_ENABLE_DEBUG
/prop_sf/VS_SHADER_ENTRYPOINT
/prop_sf/VS_SHADER_FLAGS
/prop_sf/VS_SHADER_MODEL
/prop_sf/VS_SHADER_OBJECT_FILE_NAME
/prop_sf/VS_SHADER_OUTPUT_HEADER_FILE
/prop_sf/VS_SHADER_TYPE
/prop_sf/VS_SHADER_VARIABLE_NAME
/prop_sf/VS_TOOL_OVERRIDE.rst
/prop_sf/VS_XAML_TYPE
/prop_sf/WRAP_EXCLUDE
/prop_sf/XCODE_EXPLICIT_FILE_TYPE
/prop_sf/XCODE_FILE_ATTRIBUTES
/prop_sf/XCODE_LAST_KNOWN_FILE_TYPE
.. _`Cache Entry Properties`:
Properties on Cache Entries
===========================
.. toctree::
:maxdepth: 1
/prop_cache/ADVANCED
/prop_cache/HELPSTRING
/prop_cache/MODIFIED
/prop_cache/STRINGS
/prop_cache/TYPE
/prop_cache/VALUE
.. _`Installed File Properties`:
Properties on Installed Files
=============================
.. toctree::
:maxdepth: 1
/prop_inst/CPACK_DESKTOP_SHORTCUTS.rst
/prop_inst/CPACK_NEVER_OVERWRITE.rst
/prop_inst/CPACK_PERMANENT.rst
/prop_inst/CPACK_START_MENU_SHORTCUTS.rst
/prop_inst/CPACK_STARTUP_SHORTCUTS.rst
/prop_inst/CPACK_WIX_ACL.rst
Deprecated Properties on Directories
====================================
.. toctree::
:maxdepth: 1
/prop_dir/ADDITIONAL_MAKE_CLEAN_FILES
/prop_dir/COMPILE_DEFINITIONS_CONFIG
/prop_dir/TEST_INCLUDE_FILE
Deprecated Properties on Targets
================================
.. toctree::
:maxdepth: 1
/prop_tgt/COMPILE_DEFINITIONS_CONFIG
/prop_tgt/POST_INSTALL_SCRIPT
/prop_tgt/PRE_INSTALL_SCRIPT
Deprecated Properties on Source Files
=====================================
.. toctree::
:maxdepth: 1
/prop_sf/COMPILE_DEFINITIONS_CONFIG

259
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-qt.7.rst Normal file
View File

@ -0,0 +1,259 @@
.. cmake-manual-description: CMake Qt Features Reference
cmake-qt(7)
***********
.. only:: html
.. contents::
Introduction
============
CMake can find and use Qt 4 and Qt 5 libraries. The Qt 4 libraries are found
by the :module:`FindQt4` find-module shipped with CMake, whereas the
Qt 5 libraries are found using "Config-file Packages" shipped with Qt 5. See
:manual:`cmake-packages(7)` for more information about CMake packages, and
see `the Qt cmake manual <http://qt-project.org/doc/qt-5/cmake-manual.html>`_
for your Qt version.
Qt 4 and Qt 5 may be used together in the same
:manual:`CMake buildsystem <cmake-buildsystem(7)>`:
.. code-block:: cmake
cmake_minimum_required(VERSION 3.8.0 FATAL_ERROR)
project(Qt4And5)
set(CMAKE_AUTOMOC ON)
find_package(Qt5 COMPONENTS Widgets DBus REQUIRED)
add_executable(publisher publisher.cpp)
target_link_libraries(publisher Qt5::Widgets Qt5::DBus)
find_package(Qt4 REQUIRED)
add_executable(subscriber subscriber.cpp)
target_link_libraries(subscriber Qt4::QtGui Qt4::QtDBus)
A CMake target may not link to both Qt 4 and Qt 5. A diagnostic is issued if
this is attempted or results from transitive target dependency evaluation.
Qt Build Tools
==============
Qt relies on some bundled tools for code generation, such as ``moc`` for
meta-object code generation, ``uic`` for widget layout and population,
and ``rcc`` for virtual file system content generation. These tools may be
automatically invoked by :manual:`cmake(1)` if the appropriate conditions
are met. The automatic tool invocation may be used with both Qt 4 and Qt 5.
AUTOMOC
^^^^^^^
The :prop_tgt:`AUTOMOC` target property controls whether :manual:`cmake(1)`
inspects the C++ files in the target to determine if they require ``moc`` to
be run, and to create rules to execute ``moc`` at the appropriate time.
If a macro from :prop_tgt:`AUTOMOC_MACRO_NAMES` is found in a header file,
``moc`` will be run on the file. The result will be put into a file named
according to ``moc_<basename>.cpp``.
If the macro is found in a C++ implementation
file, the moc output will be put into a file named according to
``<basename>.moc``, following the Qt conventions. The ``<basename>.moc`` must
be included by the user in the C++ implementation file with a preprocessor
``#include``.
Included ``moc_*.cpp`` and ``*.moc`` files will be generated in the
``<AUTOGEN_BUILD_DIR>/include`` directory which is
automatically added to the target's :prop_tgt:`INCLUDE_DIRECTORIES`.
* This differs from CMake 3.7 and below; see their documentation for details.
* For :prop_gbl:`multi configuration generators <GENERATOR_IS_MULTI_CONFIG>`,
the include directory is ``<AUTOGEN_BUILD_DIR>/include_<CONFIG>``.
* See :prop_tgt:`AUTOGEN_BUILD_DIR`.
Not included ``moc_<basename>.cpp`` files will be generated in custom
folders to avoid name collisions and included in a separate
``<AUTOGEN_BUILD_DIR>/mocs_compilation.cpp`` file which is compiled
into the target.
* See :prop_tgt:`AUTOGEN_BUILD_DIR`.
The ``moc`` command line will consume the :prop_tgt:`COMPILE_DEFINITIONS` and
:prop_tgt:`INCLUDE_DIRECTORIES` target properties from the target it is being
invoked for, and for the appropriate build configuration.
The :prop_tgt:`AUTOMOC` target property may be pre-set for all
following targets by setting the :variable:`CMAKE_AUTOMOC` variable. The
:prop_tgt:`AUTOMOC_MOC_OPTIONS` target property may be populated to set
options to pass to ``moc``. The :variable:`CMAKE_AUTOMOC_MOC_OPTIONS`
variable may be populated to pre-set the options for all following targets.
Additional macro names to search for can be added to
:prop_tgt:`AUTOMOC_MACRO_NAMES`.
Additional ``moc`` dependency file names can be extracted from source code
by using :prop_tgt:`AUTOMOC_DEPEND_FILTERS`.
Source C++ files can be excluded from :prop_tgt:`AUTOMOC` processing by
enabling :prop_sf:`SKIP_AUTOMOC` or the broader :prop_sf:`SKIP_AUTOGEN`.
.. _`Qt AUTOUIC`:
AUTOUIC
^^^^^^^
The :prop_tgt:`AUTOUIC` target property controls whether :manual:`cmake(1)`
inspects the C++ files in the target to determine if they require ``uic`` to
be run, and to create rules to execute ``uic`` at the appropriate time.
If a preprocessor ``#include`` directive is found which matches
``<path>ui_<basename>.h``, and a ``<basename>.ui`` file exists,
then ``uic`` will be executed to generate the appropriate file.
The ``<basename>.ui`` file is searched for in the following places
1. ``<source_dir>/<basename>.ui``
2. ``<source_dir>/<path><basename>.ui``
3. ``<AUTOUIC_SEARCH_PATHS>/<basename>.ui``
4. ``<AUTOUIC_SEARCH_PATHS>/<path><basename>.ui``
where ``<source_dir>`` is the directory of the C++ file and
:prop_tgt:`AUTOUIC_SEARCH_PATHS` is a list of additional search paths.
The generated generated ``ui_*.h`` files are placed in the
``<AUTOGEN_BUILD_DIR>/include`` directory which is
automatically added to the target's :prop_tgt:`INCLUDE_DIRECTORIES`.
* This differs from CMake 3.7 and below; see their documentation for details.
* For :prop_gbl:`multi configuration generators <GENERATOR_IS_MULTI_CONFIG>`,
the include directory is ``<AUTOGEN_BUILD_DIR>/include_<CONFIG>``.
* See :prop_tgt:`AUTOGEN_BUILD_DIR`.
The :prop_tgt:`AUTOUIC` target property may be pre-set for all following
targets by setting the :variable:`CMAKE_AUTOUIC` variable. The
:prop_tgt:`AUTOUIC_OPTIONS` target property may be populated to set options
to pass to ``uic``. The :variable:`CMAKE_AUTOUIC_OPTIONS` variable may be
populated to pre-set the options for all following targets. The
:prop_sf:`AUTOUIC_OPTIONS` source file property may be set on the
``<basename>.ui`` file to set particular options for the file. This
overrides options from the :prop_tgt:`AUTOUIC_OPTIONS` target property.
A target may populate the :prop_tgt:`INTERFACE_AUTOUIC_OPTIONS` target
property with options that should be used when invoking ``uic``. This must be
consistent with the :prop_tgt:`AUTOUIC_OPTIONS` target property content of the
depender target. The :variable:`CMAKE_DEBUG_TARGET_PROPERTIES` variable may
be used to track the origin target of such
:prop_tgt:`INTERFACE_AUTOUIC_OPTIONS`. This means that a library which
provides an alternative translation system for Qt may specify options which
should be used when running ``uic``:
.. code-block:: cmake
add_library(KI18n klocalizedstring.cpp)
target_link_libraries(KI18n Qt5::Core)
# KI18n uses the tr2i18n() function instead of tr(). That function is
# declared in the klocalizedstring.h header.
set(autouic_options
-tr tr2i18n
-include klocalizedstring.h
)
set_property(TARGET KI18n APPEND PROPERTY
INTERFACE_AUTOUIC_OPTIONS ${autouic_options}
)
A consuming project linking to the target exported from upstream automatically
uses appropriate options when ``uic`` is run by :prop_tgt:`AUTOUIC`, as a
result of linking with the :prop_tgt:`IMPORTED` target:
.. code-block:: cmake
set(CMAKE_AUTOUIC ON)
# Uses a libwidget.ui file:
add_library(LibWidget libwidget.cpp)
target_link_libraries(LibWidget
KF5::KI18n
Qt5::Widgets
)
Source files can be excluded from :prop_tgt:`AUTOUIC` processing by
enabling :prop_sf:`SKIP_AUTOUIC` or the broader :prop_sf:`SKIP_AUTOGEN`.
.. _`Qt AUTORCC`:
AUTORCC
^^^^^^^
The :prop_tgt:`AUTORCC` target property controls whether :manual:`cmake(1)`
creates rules to execute ``rcc`` at the appropriate time on source files
which have the suffix ``.qrc``.
.. code-block:: cmake
add_executable(myexe main.cpp resource_file.qrc)
The :prop_tgt:`AUTORCC` target property may be pre-set for all following targets
by setting the :variable:`CMAKE_AUTORCC` variable. The
:prop_tgt:`AUTORCC_OPTIONS` target property may be populated to set options
to pass to ``rcc``. The :variable:`CMAKE_AUTORCC_OPTIONS` variable may be
populated to pre-set the options for all following targets. The
:prop_sf:`AUTORCC_OPTIONS` source file property may be set on the
``<name>.qrc`` file to set particular options for the file. This
overrides options from the :prop_tgt:`AUTORCC_OPTIONS` target property.
Source files can be excluded from :prop_tgt:`AUTORCC` processing by
enabling :prop_sf:`SKIP_AUTORCC` or the broader :prop_sf:`SKIP_AUTOGEN`.
The ``<ORIGIN>_autogen`` target
===============================
The ``moc`` and ``uic`` tools are executed as part of a synthesized
``<ORIGIN>_autogen`` :command:`custom target <add_custom_target>` generated by
CMake. By default that ``<ORIGIN>_autogen`` target inherits the dependencies
of the ``<ORIGIN>`` target (see :prop_tgt:`AUTOGEN_ORIGIN_DEPENDS`).
Target dependencies may be added to the ``<ORIGIN>_autogen`` target by adding
them to the :prop_tgt:`AUTOGEN_TARGET_DEPENDS` target property.
Visual Studio Generators
========================
When using the :manual:`Visual Studio generators <cmake-generators(7)>`, CMake
generates a ``PRE_BUILD`` :command:`custom command <add_custom_command>`
instead of the ``<ORIGIN>_autogen`` :command:`custom target <add_custom_target>`
(for :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`).
This isn't always possible though and
an ``<ORIGIN>_autogen`` :command:`custom target <add_custom_target>` is used,
when either
- the ``<ORIGIN>`` target depends on :prop_sf:`GENERATED` files which aren't
excluded from :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` by
:prop_sf:`SKIP_AUTOMOC`, :prop_sf:`SKIP_AUTOUIC`, :prop_sf:`SKIP_AUTOGEN`
or :policy:`CMP0071`
- :prop_tgt:`AUTOGEN_TARGET_DEPENDS` lists a source file
- :variable:`CMAKE_GLOBAL_AUTOGEN_TARGET` is enabled
qtmain.lib on Windows
=====================
The Qt 4 and 5 :prop_tgt:`IMPORTED` targets for the QtGui libraries specify
that the qtmain.lib static library shipped with Qt will be linked by all
dependent executables which have the :prop_tgt:`WIN32_EXECUTABLE` enabled.
To disable this behavior, enable the ``Qt5_NO_LINK_QTMAIN`` target property for
Qt 5 based targets or ``QT4_NO_LINK_QTMAIN`` target property for Qt 4 based
targets.
.. code-block:: cmake
add_executable(myexe WIN32 main.cpp)
target_link_libraries(myexe Qt4::QtGui)
add_executable(myexe_no_qtmain WIN32 main_no_qtmain.cpp)
set_property(TARGET main_no_qtmain PROPERTY QT4_NO_LINK_QTMAIN ON)
target_link_libraries(main_no_qtmain Qt4::QtGui)

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

@ -0,0 +1,744 @@
.. 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" ==]

666
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-toolchains.7.rst Normal file
View File

@ -0,0 +1,666 @@
.. cmake-manual-description: CMake Toolchains Reference
cmake-toolchains(7)
*******************
.. only:: html
.. contents::
Introduction
============
CMake uses a toolchain of utilities to compile, link libraries and create
archives, and other tasks to drive the build. The toolchain utilities available
are determined by the languages enabled. In normal builds, CMake automatically
determines the toolchain for host builds based on system introspection and
defaults. In cross-compiling scenarios, a toolchain file may be specified
with information about compiler and utility paths.
Languages
=========
Languages are enabled by the :command:`project` command. Language-specific
built-in variables, such as
:variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>`,
:variable:`CMAKE_CXX_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` etc are set by
invoking the :command:`project` command. If no project command
is in the top-level CMakeLists file, one will be implicitly generated. By default
the enabled languages are ``C`` and ``CXX``:
.. code-block:: cmake
project(C_Only C)
A special value of ``NONE`` can also be used with the :command:`project` command
to enable no languages:
.. code-block:: cmake
project(MyProject NONE)
The :command:`enable_language` command can be used to enable languages after the
:command:`project` command:
.. code-block:: cmake
enable_language(CXX)
When a language is enabled, CMake finds a compiler for that language, and
determines some information, such as the vendor and version of the compiler,
the target architecture and bitwidth, the location of corresponding utilities
etc.
The :prop_gbl:`ENABLED_LANGUAGES` global property contains the languages which
are currently enabled.
Variables and Properties
========================
Several variables relate to the language components of a toolchain which are
enabled. :variable:`CMAKE_<LANG>_COMPILER` is the full path to the compiler used
for ``<LANG>``. :variable:`CMAKE_<LANG>_COMPILER_ID` is the identifier used
by CMake for the compiler and :variable:`CMAKE_<LANG>_COMPILER_VERSION` is the
version of the compiler.
The :variable:`CMAKE_<LANG>_FLAGS` variables and the configuration-specific
equivalents contain flags that will be added to the compile command when
compiling a file of a particular language.
As the linker is invoked by the compiler driver, CMake needs a way to determine
which compiler to use to invoke the linker. This is calculated by the
:prop_sf:`LANGUAGE` of source files in the target, and in the case of static
libraries, the language of the dependent libraries. The choice CMake makes may
be overridden with the :prop_tgt:`LINKER_LANGUAGE` target property.
Toolchain Features
==================
CMake provides the :command:`try_compile` command and wrapper macros such as
:module:`CheckCXXSourceCompiles`, :module:`CheckCXXSymbolExists` and
:module:`CheckIncludeFile` to test capability and availability of various
toolchain features. These APIs test the toolchain in some way and cache the
result so that the test does not have to be performed again the next time
CMake runs.
Some toolchain features have built-in handling in CMake, and do not require
compile-tests. For example, :prop_tgt:`POSITION_INDEPENDENT_CODE` allows
specifying that a target should be built as position-independent code, if
the compiler supports that feature. The :prop_tgt:`<LANG>_VISIBILITY_PRESET`
and :prop_tgt:`VISIBILITY_INLINES_HIDDEN` target properties add flags for
hidden visibility, if supported by the compiler.
.. _`Cross Compiling Toolchain`:
Cross Compiling
===============
If :manual:`cmake(1)` is invoked with the command line parameter
``-DCMAKE_TOOLCHAIN_FILE=path/to/file``, the file will be loaded early to set
values for the compilers.
The :variable:`CMAKE_CROSSCOMPILING` variable is set to true when CMake is
cross-compiling.
Note that using the :variable:`CMAKE_SOURCE_DIR` or :variable:`CMAKE_BINARY_DIR`
variables inside a toolchain file is typically undesirable. The toolchain
file is used in contexts where these variables have different values when used
in different places (e.g. as part of a call to :command:`try_compile`). In most
cases, where there is a need to evaluate paths inside a toolchain file, the more
appropriate variable to use would be :variable:`CMAKE_CURRENT_LIST_DIR`, since
it always has an unambiguous, predictable value.
Cross Compiling for Linux
-------------------------
A typical cross-compiling toolchain for Linux has content such
as:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs)
set(CMAKE_STAGING_PREFIX /home/devel/stage)
set(tools /home/devel/gcc-4.7-linaro-rpi-gnueabihf)
set(CMAKE_C_COMPILER ${tools}/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER ${tools}/bin/arm-linux-gnueabihf-g++)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
The :variable:`CMAKE_SYSTEM_NAME` is the CMake-identifier of the target platform
to build for.
The :variable:`CMAKE_SYSTEM_PROCESSOR` is the CMake-identifier of the target architecture
to build for.
The :variable:`CMAKE_SYSROOT` is optional, and may be specified if a sysroot
is available.
The :variable:`CMAKE_STAGING_PREFIX` is also optional. It may be used to specify
a path on the host to install to. The :variable:`CMAKE_INSTALL_PREFIX` is always
the runtime installation location, even when cross-compiling.
The :variable:`CMAKE_<LANG>_COMPILER` variables may be set to full paths, or to
names of compilers to search for in standard locations. For toolchains that
do not support linking binaries without custom flags or scripts one may set
the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable to ``STATIC_LIBRARY``
to tell CMake not to try to link executables during its checks.
CMake ``find_*`` commands will look in the sysroot, and the :variable:`CMAKE_FIND_ROOT_PATH`
entries by default in all cases, as well as looking in the host system root prefix.
Although this can be controlled on a case-by-case basis, when cross-compiling, it
can be useful to exclude looking in either the host or the target for particular
artifacts. Generally, includes, libraries and packages should be found in the
target system prefixes, whereas executables which must be run as part of the build
should be found only on the host and not on the target. This is the purpose of
the ``CMAKE_FIND_ROOT_PATH_MODE_*`` variables.
.. _`Cray Cross-Compile`:
Cross Compiling for the Cray Linux Environment
----------------------------------------------
Cross compiling for compute nodes in the Cray Linux Environment can be done
without needing a separate toolchain file. Specifying
``-DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment`` on the CMake command line will
ensure that the appropriate build settings and search paths are configured.
The platform will pull its configuration from the current environment
variables and will configure a project to use the compiler wrappers from the
Cray Programming Environment's ``PrgEnv-*`` modules if present and loaded.
The default configuration of the Cray Programming Environment is to only
support static libraries. This can be overridden and shared libraries
enabled by setting the ``CRAYPE_LINK_TYPE`` environment variable to
``dynamic``.
Running CMake without specifying :variable:`CMAKE_SYSTEM_NAME` will
run the configure step in host mode assuming a standard Linux environment.
If not overridden, the ``PrgEnv-*`` compiler wrappers will end up getting used,
which if targeting the either the login node or compute node, is likely not the
desired behavior. The exception to this would be if you are building directly
on a NID instead of cross-compiling from a login node. If trying to build
software for a login node, you will need to either first unload the
currently loaded ``PrgEnv-*`` module or explicitly tell CMake to use the
system compilers in ``/usr/bin`` instead of the Cray wrappers. If instead
targeting a compute node is desired, just specify the
:variable:`CMAKE_SYSTEM_NAME` as mentioned above.
Cross Compiling using Clang
---------------------------
Some compilers such as Clang are inherently cross compilers.
The :variable:`CMAKE_<LANG>_COMPILER_TARGET` can be set to pass a
value to those supported compilers when compiling:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(triple arm-linux-gnueabihf)
set(CMAKE_C_COMPILER clang)
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_CXX_COMPILER_TARGET ${triple})
Similarly, some compilers do not ship their own supplementary utilities
such as linkers, but provide a way to specify the location of the external
toolchain which will be used by the compiler driver. The
:variable:`CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a
toolchain file to pass the path to the compiler driver.
Cross Compiling for QNX
-----------------------
As the Clang compiler the QNX QCC compile is inherently a cross compiler.
And the :variable:`CMAKE_<LANG>_COMPILER_TARGET` can be set to pass a
value to those supported compilers when compiling:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME QNX)
set(arch gcc_ntoarmv7le)
set(CMAKE_C_COMPILER qcc)
set(CMAKE_C_COMPILER_TARGET ${arch})
set(CMAKE_CXX_COMPILER QCC)
set(CMAKE_CXX_COMPILER_TARGET ${arch})
set(CMAKE_SYSROOT $ENV{QNX_TARGET})
Cross Compiling for Windows CE
------------------------------
Cross compiling for Windows CE requires the corresponding SDK being
installed on your system. These SDKs are usually installed under
``C:/Program Files (x86)/Windows CE Tools/SDKs``.
A toolchain file to configure a Visual Studio generator for
Windows CE may look like this:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME WindowsCE)
set(CMAKE_SYSTEM_VERSION 8.0)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0
set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310)
The :variable:`CMAKE_GENERATOR_PLATFORM` tells the generator which SDK to use.
Further :variable:`CMAKE_SYSTEM_VERSION` tells the generator what version of
Windows CE to use. Currently version 8.0 (Windows Embedded Compact 2013) is
supported out of the box. Other versions may require one to set
:variable:`CMAKE_GENERATOR_TOOLSET` to the correct value.
Cross Compiling for Windows 10 Universal Applications
-----------------------------------------------------
A toolchain file to configure a Visual Studio generator for a
Windows 10 Universal Application may look like this:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 10.0)
A Windows 10 Universal Application targets both Windows Store and
Windows Phone. Specify the :variable:`CMAKE_SYSTEM_VERSION` variable
to be ``10.0`` to build with the latest available Windows 10 SDK.
Specify a more specific version (e.g. ``10.0.10240.0`` for RTM)
to build with the corresponding SDK.
Cross Compiling for Windows Phone
---------------------------------
A toolchain file to configure a Visual Studio generator for
Windows Phone may look like this:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME WindowsPhone)
set(CMAKE_SYSTEM_VERSION 8.1)
Cross Compiling for Windows Store
---------------------------------
A toolchain file to configure a Visual Studio generator for
Windows Store may look like this:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 8.1)
.. _`Cross Compiling for Android`:
Cross Compiling for Android
---------------------------
A toolchain file may configure cross-compiling for Android by setting the
:variable:`CMAKE_SYSTEM_NAME` variable to ``Android``. Further configuration
is specific to the Android development environment to be used.
For :ref:`Visual Studio Generators`, CMake expects :ref:`NVIDIA Nsight Tegra
Visual Studio Edition <Cross Compiling for Android with NVIDIA Nsight Tegra
Visual Studio Edition>` to be installed. See that section for further
configuration details.
For :ref:`Makefile Generators` and the :generator:`Ninja` generator,
CMake expects one of these environments:
* :ref:`NDK <Cross Compiling for Android with the NDK>`
* :ref:`Standalone Toolchain <Cross Compiling for Android with a Standalone Toolchain>`
CMake uses the following steps to select one of the environments:
* If the :variable:`CMAKE_ANDROID_NDK` variable is set, the NDK at the
specified location will be used.
* Else, if the :variable:`CMAKE_ANDROID_STANDALONE_TOOLCHAIN` variable
is set, the Standalone Toolchain at the specified location will be used.
* Else, if the :variable:`CMAKE_SYSROOT` variable is set to a directory
of the form ``<ndk>/platforms/android-<api>/arch-<arch>``, the ``<ndk>``
part will be used as the value of :variable:`CMAKE_ANDROID_NDK` and the
NDK will be used.
* Else, if the :variable:`CMAKE_SYSROOT` variable is set to a directory of the
form ``<standalone-toolchain>/sysroot``, the ``<standalone-toolchain>`` part
will be used as the value of :variable:`CMAKE_ANDROID_STANDALONE_TOOLCHAIN`
and the Standalone Toolchain will be used.
* Else, if a cmake variable ``ANDROID_NDK`` is set it will be used
as the value of :variable:`CMAKE_ANDROID_NDK`, and the NDK will be used.
* Else, if a cmake variable ``ANDROID_STANDALONE_TOOLCHAIN`` is set, it will be
used as the value of :variable:`CMAKE_ANDROID_STANDALONE_TOOLCHAIN`, and the
Standalone Toolchain will be used.
* Else, if an environment variable ``ANDROID_NDK_ROOT`` or
``ANDROID_NDK`` is set, it will be used as the value of
:variable:`CMAKE_ANDROID_NDK`, and the NDK will be used.
* Else, if an environment variable ``ANDROID_STANDALONE_TOOLCHAIN`` is
set then it will be used as the value of
:variable:`CMAKE_ANDROID_STANDALONE_TOOLCHAIN`, and the Standalone
Toolchain will be used.
* Else, an error diagnostic will be issued that neither the NDK or
Standalone Toolchain can be found.
.. _`Cross Compiling for Android with the NDK`:
Cross Compiling for Android with the NDK
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A toolchain file may configure :ref:`Makefile Generators` or the
:generator:`Ninja` generator to target Android for cross-compiling.
Configure use of an Android NDK with the following variables:
:variable:`CMAKE_SYSTEM_NAME`
Set to ``Android``. Must be specified to enable cross compiling
for Android.
:variable:`CMAKE_SYSTEM_VERSION`
Set to the Android API level. If not specified, the value is
determined as follows:
* If the :variable:`CMAKE_ANDROID_API` variable is set, its value
is used as the API level.
* If the :variable:`CMAKE_SYSROOT` variable is set, the API level is
detected from the NDK directory structure containing the sysroot.
* Otherwise, the latest API level available in the NDK is used.
:variable:`CMAKE_ANDROID_ARCH_ABI`
Set to the Android ABI (architecture). If not specified, this
variable will default to ``armeabi``.
The :variable:`CMAKE_ANDROID_ARCH` variable will be computed
from ``CMAKE_ANDROID_ARCH_ABI`` automatically.
Also see the :variable:`CMAKE_ANDROID_ARM_MODE` and
:variable:`CMAKE_ANDROID_ARM_NEON` variables.
:variable:`CMAKE_ANDROID_NDK`
Set to the absolute path to the Android NDK root directory.
A ``${CMAKE_ANDROID_NDK}/platforms`` directory must exist.
If not specified, a default for this variable will be chosen
as specified :ref:`above <Cross Compiling for Android>`.
:variable:`CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`
Set to a true value to use the deprecated per-api-level headers
instead of the unified headers. If not specified, the default will
be false unless using a NDK that does not provide unified headers.
:variable:`CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION`
On NDK r19 or above, this variable must be unset or set to ``clang``.
On NDK r18 or below, set this to the version of the NDK toolchain to
be selected as the compiler. If not specified, the default will be
the latest available GCC toolchain.
:variable:`CMAKE_ANDROID_STL_TYPE`
Set to specify which C++ standard library to use. If not specified,
a default will be selected as described in the variable documentation.
The following variables will be computed and provided automatically:
:variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX`
The absolute path prefix to the binutils in the NDK toolchain.
:variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX`
The host platform suffix of the binutils in the NDK toolchain.
For example, a toolchain file might contain:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 21) # API level
set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
set(CMAKE_ANDROID_NDK /path/to/android-ndk)
set(CMAKE_ANDROID_STL_TYPE gnustl_static)
Alternatively one may specify the values without a toolchain file:
.. code-block:: console
$ cmake ../src \
-DCMAKE_SYSTEM_NAME=Android \
-DCMAKE_SYSTEM_VERSION=21 \
-DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \
-DCMAKE_ANDROID_NDK=/path/to/android-ndk \
-DCMAKE_ANDROID_STL_TYPE=gnustl_static
.. _`Cross Compiling for Android with a Standalone Toolchain`:
Cross Compiling for Android with a Standalone Toolchain
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A toolchain file may configure :ref:`Makefile Generators` or the
:generator:`Ninja` generator to target Android for cross-compiling
using a standalone toolchain.
Configure use of an Android standalone toolchain with the following variables:
:variable:`CMAKE_SYSTEM_NAME`
Set to ``Android``. Must be specified to enable cross compiling
for Android.
:variable:`CMAKE_ANDROID_STANDALONE_TOOLCHAIN`
Set to the absolute path to the standalone toolchain root directory.
A ``${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot`` directory
must exist.
If not specified, a default for this variable will be chosen
as specified :ref:`above <Cross Compiling for Android>`.
:variable:`CMAKE_ANDROID_ARM_MODE`
When the standalone toolchain targets ARM, optionally set this to ``ON``
to target 32-bit ARM instead of 16-bit Thumb.
See variable documentation for details.
:variable:`CMAKE_ANDROID_ARM_NEON`
When the standalone toolchain targets ARM v7, optionally set thisto ``ON``
to target ARM NEON devices. See variable documentation for details.
The following variables will be computed and provided automatically:
:variable:`CMAKE_SYSTEM_VERSION`
The Android API level detected from the standalone toolchain.
:variable:`CMAKE_ANDROID_ARCH_ABI`
The Android ABI detected from the standalone toolchain.
:variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX`
The absolute path prefix to the ``binutils`` in the standalone toolchain.
:variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX`
The host platform suffix of the ``binutils`` in the standalone toolchain.
For example, a toolchain file might contain:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /path/to/android-toolchain)
Alternatively one may specify the values without a toolchain file:
.. code-block:: console
$ cmake ../src \
-DCMAKE_SYSTEM_NAME=Android \
-DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/path/to/android-toolchain
.. _`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition`:
Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A toolchain file to configure one of the :ref:`Visual Studio Generators`
to build using NVIDIA Nsight Tegra targeting Android may look like this:
.. code-block:: cmake
set(CMAKE_SYSTEM_NAME Android)
The :variable:`CMAKE_GENERATOR_TOOLSET` may be set to select
the Nsight Tegra "Toolchain Version" value.
See also target properties:
* :prop_tgt:`ANDROID_ANT_ADDITIONAL_OPTIONS`
* :prop_tgt:`ANDROID_API_MIN`
* :prop_tgt:`ANDROID_API`
* :prop_tgt:`ANDROID_ARCH`
* :prop_tgt:`ANDROID_ASSETS_DIRECTORIES`
* :prop_tgt:`ANDROID_GUI`
* :prop_tgt:`ANDROID_JAR_DEPENDENCIES`
* :prop_tgt:`ANDROID_JAR_DIRECTORIES`
* :prop_tgt:`ANDROID_JAVA_SOURCE_DIR`
* :prop_tgt:`ANDROID_NATIVE_LIB_DEPENDENCIES`
* :prop_tgt:`ANDROID_NATIVE_LIB_DIRECTORIES`
* :prop_tgt:`ANDROID_PROCESS_MAX`
* :prop_tgt:`ANDROID_PROGUARD_CONFIG_PATH`
* :prop_tgt:`ANDROID_PROGUARD`
* :prop_tgt:`ANDROID_SECURE_PROPS_PATH`
* :prop_tgt:`ANDROID_SKIP_ANT_STEP`
* :prop_tgt:`ANDROID_STL_TYPE`
.. _`Cross Compiling for iOS, tvOS, or watchOS`:
Cross Compiling for iOS, tvOS, or watchOS
-----------------------------------------
For cross-compiling to iOS, tvOS, or watchOS, the :generator:`Xcode`
generator is recommended. The :generator:`Unix Makefiles` or
:generator:`Ninja` generators can also be used, but they require the
project to handle more areas like target CPU selection and code signing.
Any of the three systems can be targeted by setting the
:variable:`CMAKE_SYSTEM_NAME` variable to a value from the table below.
By default, the latest Device SDK is chosen. As for all Apple platforms,
a different SDK (e.g. a simulator) can be selected by setting the
:variable:`CMAKE_OSX_SYSROOT` variable, although this should rarely be
necessary (see :ref:`Switching Between Device and Simulator` below).
A list of available SDKs can be obtained by running ``xcodebuild -showsdks``.
======= ================= ==================== ================
OS CMAKE_SYSTEM_NAME Device SDK (default) Simulator SDK
======= ================= ==================== ================
iOS iOS iphoneos iphonesimulator
tvOS tvOS appletvos appletvsimulator
watchOS watchOS watchos watchsimulator
======= ================= ==================== ================
For example, to create a CMake configuration for iOS, the following
command is sufficient:
.. code-block:: console
cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS
Variable :variable:`CMAKE_OSX_ARCHITECTURES` can be used to set architectures
for both device and simulator. Variable :variable:`CMAKE_OSX_DEPLOYMENT_TARGET`
can be used to set an iOS/tvOS/watchOS deployment target.
Next configuration will install fat 5 architectures iOS library
and add the ``-miphoneos-version-min=9.3``/``-mios-simulator-version-min=9.3``
flags to the compiler:
.. code-block:: console
$ cmake -S. -B_builds -GXcode \
-DCMAKE_SYSTEM_NAME=iOS \
"-DCMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64;i386;x86_64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 \
-DCMAKE_INSTALL_PREFIX=`pwd`/_install \
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
-DCMAKE_IOS_INSTALL_COMBINED=YES
Example:
.. code-block:: cmake
# CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(foo)
add_library(foo foo.cpp)
install(TARGETS foo DESTINATION lib)
Install:
.. code-block:: console
$ cmake --build _builds --config Release --target install
Check library:
.. code-block:: console
$ lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 armv7s x86_64 arm64
.. code-block:: console
$ otool -l _install/lib/libfoo.a | grep -A2 LC_VERSION_MIN_IPHONEOS
cmd LC_VERSION_MIN_IPHONEOS
cmdsize 16
version 9.3
Code Signing
^^^^^^^^^^^^
Some build artifacts for the embedded Apple platforms require mandatory
code signing. If the :generator:`Xcode` generator is being used and
code signing is required or desired, the development team ID can be
specified via the ``CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM`` CMake variable.
This team ID will then be included in the generated Xcode project.
By default, CMake avoids the need for code signing during the internal
configuration phase (i.e compiler ID and feature detection).
.. _`Switching Between Device and Simulator`:
Switching Between Device and Simulator
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When configuring for any of the embedded platforms, one can target either
real devices or the simulator. Both have their own separate SDK, but CMake
only supports specifying a single SDK for the configuration phase. This
means the developer must select one or the other at configuration time.
When using the :generator:`Xcode` generator, this is less of a limitation
because Xcode still allows you to build for either a device or a simulator,
even though configuration was only performed for one of the two. From
within the Xcode IDE, builds are performed for the selected "destination"
platform. When building from the command line, the desired sdk can be
specified directly by passing a ``-sdk`` option to the underlying build
tool (``xcodebuild``). For example:
.. code-block:: console
$ cmake --build ... -- -sdk iphonesimulator
Please note that checks made during configuration were performed against
the configure-time SDK and might not hold true for other SDKs. Commands
like :command:`find_package`, :command:`find_library`, etc. store and use
details only for the configured SDK/platform, so they can be problematic
if wanting to switch between device and simulator builds. You can follow
the next rules to make device + simulator configuration work:
- Use explicit ``-l`` linker flag,
e.g. ``target_link_libraries(foo PUBLIC "-lz")``
- Use explicit ``-framework`` linker flag,
e.g. ``target_link_libraries(foo PUBLIC "-framework CoreFoundation")``
- Use :command:`find_package` only for libraries installed with
:variable:`CMAKE_IOS_INSTALL_COMBINED` feature

688
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cmake-variables.7.rst Normal file
View File

@ -0,0 +1,688 @@
.. cmake-manual-description: CMake Variables Reference
cmake-variables(7)
******************
.. only:: html
.. contents::
This page documents variables that are provided by CMake
or have meaning to CMake when set by project code.
For general information on variables, see the
:ref:`Variables <CMake Language Variables>`
section in the cmake-language manual.
.. include:: ID_RESERVE.txt
Variables that Provide Information
==================================
.. toctree::
:maxdepth: 1
/variable/CMAKE_AR
/variable/CMAKE_ARGC
/variable/CMAKE_ARGV0
/variable/CMAKE_BINARY_DIR
/variable/CMAKE_BUILD_TOOL
/variable/CMAKE_CACHEFILE_DIR
/variable/CMAKE_CACHE_MAJOR_VERSION
/variable/CMAKE_CACHE_MINOR_VERSION
/variable/CMAKE_CACHE_PATCH_VERSION
/variable/CMAKE_CFG_INTDIR
/variable/CMAKE_COMMAND
/variable/CMAKE_CPACK_COMMAND
/variable/CMAKE_CROSSCOMPILING
/variable/CMAKE_CROSSCOMPILING_EMULATOR
/variable/CMAKE_CTEST_COMMAND
/variable/CMAKE_CURRENT_BINARY_DIR
/variable/CMAKE_CURRENT_FUNCTION
/variable/CMAKE_CURRENT_FUNCTION_LIST_DIR
/variable/CMAKE_CURRENT_FUNCTION_LIST_FILE
/variable/CMAKE_CURRENT_FUNCTION_LIST_LINE
/variable/CMAKE_CURRENT_LIST_DIR
/variable/CMAKE_CURRENT_LIST_FILE
/variable/CMAKE_CURRENT_LIST_LINE
/variable/CMAKE_CURRENT_SOURCE_DIR
/variable/CMAKE_DEBUG_TARGET_PROPERTIES
/variable/CMAKE_DIRECTORY_LABELS
/variable/CMAKE_DL_LIBS
/variable/CMAKE_DOTNET_TARGET_FRAMEWORK
/variable/CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION
/variable/CMAKE_EDIT_COMMAND
/variable/CMAKE_EXECUTABLE_SUFFIX
/variable/CMAKE_EXTRA_GENERATOR
/variable/CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES
/variable/CMAKE_FIND_DEBUG_MODE
/variable/CMAKE_FIND_PACKAGE_NAME
/variable/CMAKE_FIND_PACKAGE_SORT_DIRECTION
/variable/CMAKE_FIND_PACKAGE_SORT_ORDER
/variable/CMAKE_GENERATOR
/variable/CMAKE_GENERATOR_INSTANCE
/variable/CMAKE_GENERATOR_PLATFORM
/variable/CMAKE_GENERATOR_TOOLSET
/variable/CMAKE_IMPORT_LIBRARY_PREFIX
/variable/CMAKE_IMPORT_LIBRARY_SUFFIX
/variable/CMAKE_JOB_POOL_COMPILE
/variable/CMAKE_JOB_POOL_LINK
/variable/CMAKE_JOB_POOL_PRECOMPILE_HEADER
/variable/CMAKE_JOB_POOLS
/variable/CMAKE_LANG_COMPILER_AR
/variable/CMAKE_LANG_COMPILER_RANLIB
/variable/CMAKE_LANG_LINK_LIBRARY_SUFFIX
/variable/CMAKE_LINK_LIBRARY_SUFFIX
/variable/CMAKE_LINK_SEARCH_END_STATIC
/variable/CMAKE_LINK_SEARCH_START_STATIC
/variable/CMAKE_MAJOR_VERSION
/variable/CMAKE_MAKE_PROGRAM
/variable/CMAKE_MATCH_COUNT
/variable/CMAKE_MATCH_n
/variable/CMAKE_MINIMUM_REQUIRED_VERSION
/variable/CMAKE_MINOR_VERSION
/variable/CMAKE_NETRC
/variable/CMAKE_NETRC_FILE
/variable/CMAKE_PARENT_LIST_FILE
/variable/CMAKE_PATCH_VERSION
/variable/CMAKE_PROJECT_DESCRIPTION
/variable/CMAKE_PROJECT_HOMEPAGE_URL
/variable/CMAKE_PROJECT_NAME
/variable/CMAKE_PROJECT_VERSION
/variable/CMAKE_PROJECT_VERSION_MAJOR
/variable/CMAKE_PROJECT_VERSION_MINOR
/variable/CMAKE_PROJECT_VERSION_PATCH
/variable/CMAKE_PROJECT_VERSION_TWEAK
/variable/CMAKE_RANLIB
/variable/CMAKE_ROOT
/variable/CMAKE_RULE_MESSAGES
/variable/CMAKE_SCRIPT_MODE_FILE
/variable/CMAKE_SHARED_LIBRARY_PREFIX
/variable/CMAKE_SHARED_LIBRARY_SUFFIX
/variable/CMAKE_SHARED_MODULE_PREFIX
/variable/CMAKE_SHARED_MODULE_SUFFIX
/variable/CMAKE_SIZEOF_VOID_P
/variable/CMAKE_SKIP_INSTALL_RULES
/variable/CMAKE_SKIP_RPATH
/variable/CMAKE_SOURCE_DIR
/variable/CMAKE_STATIC_LIBRARY_PREFIX
/variable/CMAKE_STATIC_LIBRARY_SUFFIX
/variable/CMAKE_Swift_MODULE_DIRECTORY
/variable/CMAKE_Swift_NUM_THREADS
/variable/CMAKE_TOOLCHAIN_FILE
/variable/CMAKE_TWEAK_VERSION
/variable/CMAKE_VERBOSE_MAKEFILE
/variable/CMAKE_VERSION
/variable/CMAKE_VS_DEVENV_COMMAND
/variable/CMAKE_VS_MSBUILD_COMMAND
/variable/CMAKE_VS_NsightTegra_VERSION
/variable/CMAKE_VS_PLATFORM_NAME
/variable/CMAKE_VS_PLATFORM_NAME_DEFAULT
/variable/CMAKE_VS_PLATFORM_TOOLSET
/variable/CMAKE_VS_PLATFORM_TOOLSET_CUDA
/variable/CMAKE_VS_PLATFORM_TOOLSET_CUDA_CUSTOM_DIR
/variable/CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE
/variable/CMAKE_VS_PLATFORM_TOOLSET_VERSION
/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
/variable/CMAKE_XCODE_GENERATE_SCHEME
/variable/CMAKE_XCODE_PLATFORM_TOOLSET
/variable/PROJECT-NAME_BINARY_DIR
/variable/PROJECT-NAME_DESCRIPTION
/variable/PROJECT-NAME_HOMEPAGE_URL
/variable/PROJECT-NAME_SOURCE_DIR
/variable/PROJECT-NAME_VERSION
/variable/PROJECT-NAME_VERSION_MAJOR
/variable/PROJECT-NAME_VERSION_MINOR
/variable/PROJECT-NAME_VERSION_PATCH
/variable/PROJECT-NAME_VERSION_TWEAK
/variable/PROJECT_BINARY_DIR
/variable/PROJECT_DESCRIPTION
/variable/PROJECT_HOMEPAGE_URL
/variable/PROJECT_NAME
/variable/PROJECT_SOURCE_DIR
/variable/PROJECT_VERSION
/variable/PROJECT_VERSION_MAJOR
/variable/PROJECT_VERSION_MINOR
/variable/PROJECT_VERSION_PATCH
/variable/PROJECT_VERSION_TWEAK
Variables that Change Behavior
==============================
.. toctree::
:maxdepth: 1
/variable/BUILD_SHARED_LIBS
/variable/CMAKE_ABSOLUTE_DESTINATION_FILES
/variable/CMAKE_APPBUNDLE_PATH
/variable/CMAKE_AUTOMOC_RELAXED_MODE
/variable/CMAKE_BACKWARDS_COMPATIBILITY
/variable/CMAKE_BUILD_TYPE
/variable/CMAKE_CODEBLOCKS_COMPILER_ID
/variable/CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES
/variable/CMAKE_CODELITE_USE_TARGETS
/variable/CMAKE_COLOR_MAKEFILE
/variable/CMAKE_CONFIGURATION_TYPES
/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY
/variable/CMAKE_DISABLE_FIND_PACKAGE_PackageName
/variable/CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
/variable/CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
/variable/CMAKE_ECLIPSE_MAKE_ARGUMENTS
/variable/CMAKE_ECLIPSE_RESOURCE_ENCODING
/variable/CMAKE_ECLIPSE_VERSION
/variable/CMAKE_ERROR_DEPRECATED
/variable/CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
/variable/CMAKE_EXECUTE_PROCESS_COMMAND_ECHO
/variable/CMAKE_EXPORT_COMPILE_COMMANDS
/variable/CMAKE_EXPORT_PACKAGE_REGISTRY
/variable/CMAKE_EXPORT_NO_PACKAGE_REGISTRY
/variable/CMAKE_FIND_APPBUNDLE
/variable/CMAKE_FIND_FRAMEWORK
/variable/CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
/variable/CMAKE_FIND_LIBRARY_PREFIXES
/variable/CMAKE_FIND_LIBRARY_SUFFIXES
/variable/CMAKE_FIND_NO_INSTALL_PREFIX
/variable/CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
/variable/CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY
/variable/CMAKE_FIND_PACKAGE_PREFER_CONFIG
/variable/CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS
/variable/CMAKE_FIND_PACKAGE_WARN_NO_MODULE
/variable/CMAKE_FIND_ROOT_PATH
/variable/CMAKE_FIND_ROOT_PATH_MODE_INCLUDE
/variable/CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
/variable/CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
/variable/CMAKE_FIND_ROOT_PATH_MODE_PROGRAM
/variable/CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH
/variable/CMAKE_FIND_USE_CMAKE_PATH
/variable/CMAKE_FIND_USE_CMAKE_SYSTEM_PATH
/variable/CMAKE_FIND_USE_PACKAGE_REGISTRY
/variable/CMAKE_FIND_USE_PACKAGE_ROOT_PATH
/variable/CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH
/variable/CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY
/variable/CMAKE_FRAMEWORK_PATH
/variable/CMAKE_IGNORE_PATH
/variable/CMAKE_INCLUDE_DIRECTORIES_BEFORE
/variable/CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE
/variable/CMAKE_INCLUDE_PATH
/variable/CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
/variable/CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
/variable/CMAKE_INSTALL_MESSAGE
/variable/CMAKE_INSTALL_PREFIX
/variable/CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
/variable/CMAKE_LIBRARY_PATH
/variable/CMAKE_LINK_DIRECTORIES_BEFORE
/variable/CMAKE_MFC_FLAG
/variable/CMAKE_MAXIMUM_RECURSION_DEPTH
/variable/CMAKE_MESSAGE_CONTEXT
/variable/CMAKE_MESSAGE_CONTEXT_SHOW
/variable/CMAKE_MESSAGE_INDENT
/variable/CMAKE_MESSAGE_LOG_LEVEL
/variable/CMAKE_MODULE_PATH
/variable/CMAKE_POLICY_DEFAULT_CMPNNNN
/variable/CMAKE_POLICY_WARNING_CMPNNNN
/variable/CMAKE_PREFIX_PATH
/variable/CMAKE_PROGRAM_PATH
/variable/CMAKE_PROJECT_INCLUDE
/variable/CMAKE_PROJECT_INCLUDE_BEFORE
/variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE
/variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE_BEFORE
/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY
/variable/CMAKE_STAGING_PREFIX
/variable/CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS
/variable/CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE
/variable/CMAKE_SUPPRESS_REGENERATION
/variable/CMAKE_SYSROOT
/variable/CMAKE_SYSROOT_COMPILE
/variable/CMAKE_SYSROOT_LINK
/variable/CMAKE_SYSTEM_APPBUNDLE_PATH
/variable/CMAKE_SYSTEM_FRAMEWORK_PATH
/variable/CMAKE_SYSTEM_IGNORE_PATH
/variable/CMAKE_SYSTEM_INCLUDE_PATH
/variable/CMAKE_SYSTEM_LIBRARY_PATH
/variable/CMAKE_SYSTEM_PREFIX_PATH
/variable/CMAKE_SYSTEM_PROGRAM_PATH
/variable/CMAKE_USER_MAKE_RULES_OVERRIDE
/variable/CMAKE_WARN_DEPRECATED
/variable/CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
/variable/CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY
/variable/CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER
/variable/CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
/variable/CMAKE_XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING
/variable/CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
/variable/CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
/variable/CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
/variable/CMAKE_XCODE_SCHEME_ENVIRONMENT
/variable/CMAKE_XCODE_SCHEME_GUARD_MALLOC
/variable/CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
/variable/CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES
/variable/CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE
/variable/CMAKE_XCODE_SCHEME_MALLOC_STACK
/variable/CMAKE_XCODE_SCHEME_THREAD_SANITIZER
/variable/CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP
/variable/CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
/variable/CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
/variable/CMAKE_XCODE_SCHEME_WORKING_DIRECTORY
/variable/CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS
/variable/PackageName_ROOT
Variables that Describe the System
==================================
.. toctree::
:maxdepth: 1
/variable/ANDROID
/variable/APPLE
/variable/BORLAND
/variable/CMAKE_CL_64
/variable/CMAKE_COMPILER_2005
/variable/CMAKE_HOST_APPLE
/variable/CMAKE_HOST_SOLARIS
/variable/CMAKE_HOST_SYSTEM
/variable/CMAKE_HOST_SYSTEM_NAME
/variable/CMAKE_HOST_SYSTEM_PROCESSOR
/variable/CMAKE_HOST_SYSTEM_VERSION
/variable/CMAKE_HOST_UNIX
/variable/CMAKE_HOST_WIN32
/variable/CMAKE_LIBRARY_ARCHITECTURE
/variable/CMAKE_LIBRARY_ARCHITECTURE_REGEX
/variable/CMAKE_OBJECT_PATH_MAX
/variable/CMAKE_SYSTEM
/variable/CMAKE_SYSTEM_NAME
/variable/CMAKE_SYSTEM_PROCESSOR
/variable/CMAKE_SYSTEM_VERSION
/variable/CYGWIN
/variable/GHS-MULTI
/variable/IOS
/variable/MINGW
/variable/MSVC
/variable/MSVC10
/variable/MSVC11
/variable/MSVC12
/variable/MSVC14
/variable/MSVC60
/variable/MSVC70
/variable/MSVC71
/variable/MSVC80
/variable/MSVC90
/variable/MSVC_IDE
/variable/MSVC_TOOLSET_VERSION
/variable/MSVC_VERSION
/variable/MSYS
/variable/UNIX
/variable/WIN32
/variable/WINCE
/variable/WINDOWS_PHONE
/variable/WINDOWS_STORE
/variable/XCODE
/variable/XCODE_VERSION
Variables that Control the Build
================================
.. toctree::
:maxdepth: 1
/variable/CMAKE_AIX_EXPORT_ALL_SYMBOLS
/variable/CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS
/variable/CMAKE_ANDROID_API
/variable/CMAKE_ANDROID_API_MIN
/variable/CMAKE_ANDROID_ARCH
/variable/CMAKE_ANDROID_ARCH_ABI
/variable/CMAKE_ANDROID_ARM_MODE
/variable/CMAKE_ANDROID_ARM_NEON
/variable/CMAKE_ANDROID_ASSETS_DIRECTORIES
/variable/CMAKE_ANDROID_GUI
/variable/CMAKE_ANDROID_JAR_DEPENDENCIES
/variable/CMAKE_ANDROID_JAR_DIRECTORIES
/variable/CMAKE_ANDROID_JAVA_SOURCE_DIR
/variable/CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES
/variable/CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES
/variable/CMAKE_ANDROID_NDK
/variable/CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
/variable/CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG
/variable/CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
/variable/CMAKE_ANDROID_PROCESS_MAX
/variable/CMAKE_ANDROID_PROGUARD
/variable/CMAKE_ANDROID_PROGUARD_CONFIG_PATH
/variable/CMAKE_ANDROID_SECURE_PROPS_PATH
/variable/CMAKE_ANDROID_SKIP_ANT_STEP
/variable/CMAKE_ANDROID_STANDALONE_TOOLCHAIN
/variable/CMAKE_ANDROID_STL_TYPE
/variable/CMAKE_ARCHIVE_OUTPUT_DIRECTORY
/variable/CMAKE_ARCHIVE_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_AUTOGEN_ORIGIN_DEPENDS
/variable/CMAKE_AUTOGEN_PARALLEL
/variable/CMAKE_AUTOGEN_VERBOSE
/variable/CMAKE_AUTOMOC
/variable/CMAKE_AUTOMOC_COMPILER_PREDEFINES
/variable/CMAKE_AUTOMOC_DEPEND_FILTERS
/variable/CMAKE_AUTOMOC_MACRO_NAMES
/variable/CMAKE_AUTOMOC_MOC_OPTIONS
/variable/CMAKE_AUTOMOC_PATH_PREFIX
/variable/CMAKE_AUTORCC
/variable/CMAKE_AUTORCC_OPTIONS
/variable/CMAKE_AUTOUIC
/variable/CMAKE_AUTOUIC_OPTIONS
/variable/CMAKE_AUTOUIC_SEARCH_PATHS
/variable/CMAKE_BUILD_RPATH
/variable/CMAKE_BUILD_RPATH_USE_ORIGIN
/variable/CMAKE_BUILD_WITH_INSTALL_NAME_DIR
/variable/CMAKE_BUILD_WITH_INSTALL_RPATH
/variable/CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY
/variable/CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_CONFIG_POSTFIX
/variable/CMAKE_CROSS_CONFIGS
/variable/CMAKE_CTEST_ARGUMENTS
/variable/CMAKE_CUDA_SEPARABLE_COMPILATION
/variable/CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS
/variable/CMAKE_CUDA_RUNTIME_LIBRARY
/variable/CMAKE_DEBUG_POSTFIX
/variable/CMAKE_DEFAULT_BUILD_TYPE
/variable/CMAKE_DEFAULT_CONFIGS
/variable/CMAKE_DISABLE_PRECOMPILE_HEADERS
/variable/CMAKE_ENABLE_EXPORTS
/variable/CMAKE_EXE_LINKER_FLAGS
/variable/CMAKE_EXE_LINKER_FLAGS_CONFIG
/variable/CMAKE_EXE_LINKER_FLAGS_CONFIG_INIT
/variable/CMAKE_EXE_LINKER_FLAGS_INIT
/variable/CMAKE_FOLDER
/variable/CMAKE_FRAMEWORK
/variable/CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_CONFIG
/variable/CMAKE_Fortran_FORMAT
/variable/CMAKE_Fortran_MODULE_DIRECTORY
/variable/CMAKE_Fortran_PREPROCESS
/variable/CMAKE_GHS_NO_SOURCE_GROUP_FILE
/variable/CMAKE_GLOBAL_AUTOGEN_TARGET
/variable/CMAKE_GLOBAL_AUTOGEN_TARGET_NAME
/variable/CMAKE_GLOBAL_AUTORCC_TARGET
/variable/CMAKE_GLOBAL_AUTORCC_TARGET_NAME
/variable/CMAKE_GNUtoMS
/variable/CMAKE_INCLUDE_CURRENT_DIR
/variable/CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE
/variable/CMAKE_INSTALL_NAME_DIR
/variable/CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH
/variable/CMAKE_INSTALL_RPATH
/variable/CMAKE_INSTALL_RPATH_USE_LINK_PATH
/variable/CMAKE_INTERPROCEDURAL_OPTIMIZATION
/variable/CMAKE_INTERPROCEDURAL_OPTIMIZATION_CONFIG
/variable/CMAKE_IOS_INSTALL_COMBINED
/variable/CMAKE_LANG_CLANG_TIDY
/variable/CMAKE_LANG_COMPILER_LAUNCHER
/variable/CMAKE_LANG_CPPCHECK
/variable/CMAKE_LANG_CPPLINT
/variable/CMAKE_LANG_INCLUDE_WHAT_YOU_USE
/variable/CMAKE_LANG_LINK_LIBRARY_FILE_FLAG
/variable/CMAKE_LANG_LINK_LIBRARY_FLAG
/variable/CMAKE_LANG_VISIBILITY_PRESET
/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY
/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_LIBRARY_PATH_FLAG
/variable/CMAKE_LINK_DEF_FILE_FLAG
/variable/CMAKE_LINK_DEPENDS_NO_SHARED
/variable/CMAKE_LINK_INTERFACE_LIBRARIES
/variable/CMAKE_LINK_LIBRARY_FILE_FLAG
/variable/CMAKE_LINK_LIBRARY_FLAG
/variable/CMAKE_LINK_WHAT_YOU_USE
/variable/CMAKE_MACOSX_BUNDLE
/variable/CMAKE_MACOSX_RPATH
/variable/CMAKE_MAP_IMPORTED_CONFIG_CONFIG
/variable/CMAKE_MODULE_LINKER_FLAGS
/variable/CMAKE_MODULE_LINKER_FLAGS_CONFIG
/variable/CMAKE_MODULE_LINKER_FLAGS_CONFIG_INIT
/variable/CMAKE_MODULE_LINKER_FLAGS_INIT
/variable/CMAKE_MSVCIDE_RUN_PATH
/variable/CMAKE_MSVC_RUNTIME_LIBRARY
/variable/CMAKE_NINJA_OUTPUT_PATH_PREFIX
/variable/CMAKE_NO_BUILTIN_CHRPATH
/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED
/variable/CMAKE_OSX_ARCHITECTURES
/variable/CMAKE_OSX_DEPLOYMENT_TARGET
/variable/CMAKE_OSX_SYSROOT
/variable/CMAKE_PCH_WARN_INVALID
/variable/CMAKE_PDB_OUTPUT_DIRECTORY
/variable/CMAKE_PDB_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_POSITION_INDEPENDENT_CODE
/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY
/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_SHARED_LINKER_FLAGS
/variable/CMAKE_SHARED_LINKER_FLAGS_CONFIG
/variable/CMAKE_SHARED_LINKER_FLAGS_CONFIG_INIT
/variable/CMAKE_SHARED_LINKER_FLAGS_INIT
/variable/CMAKE_SKIP_BUILD_RPATH
/variable/CMAKE_SKIP_INSTALL_RPATH
/variable/CMAKE_STATIC_LINKER_FLAGS
/variable/CMAKE_STATIC_LINKER_FLAGS_CONFIG
/variable/CMAKE_STATIC_LINKER_FLAGS_CONFIG_INIT
/variable/CMAKE_STATIC_LINKER_FLAGS_INIT
/variable/CMAKE_TRY_COMPILE_CONFIGURATION
/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
/variable/CMAKE_TRY_COMPILE_TARGET_TYPE
/variable/CMAKE_UNITY_BUILD
/variable/CMAKE_UNITY_BUILD_BATCH_SIZE
/variable/CMAKE_USE_RELATIVE_PATHS
/variable/CMAKE_VISIBILITY_INLINES_HIDDEN
/variable/CMAKE_VS_GLOBALS
/variable/CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD
/variable/CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD
/variable/CMAKE_VS_JUST_MY_CODE_DEBUGGING
/variable/CMAKE_VS_SDK_EXCLUDE_DIRECTORIES
/variable/CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES
/variable/CMAKE_VS_SDK_INCLUDE_DIRECTORIES
/variable/CMAKE_VS_SDK_LIBRARY_DIRECTORIES
/variable/CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES
/variable/CMAKE_VS_SDK_REFERENCE_DIRECTORIES
/variable/CMAKE_VS_SDK_SOURCE_DIRECTORIES
/variable/CMAKE_VS_WINRT_BY_DEFAULT
/variable/CMAKE_WIN32_EXECUTABLE
/variable/CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute
/variable/EXECUTABLE_OUTPUT_PATH
/variable/LIBRARY_OUTPUT_PATH
Variables for Languages
=======================
.. toctree::
:maxdepth: 1
/variable/CMAKE_COMPILER_IS_GNUCC
/variable/CMAKE_COMPILER_IS_GNUCXX
/variable/CMAKE_COMPILER_IS_GNUG77
/variable/CMAKE_CUDA_ARCHITECTURES
/variable/CMAKE_CUDA_COMPILE_FEATURES
/variable/CMAKE_CUDA_HOST_COMPILER
/variable/CMAKE_CUDA_EXTENSIONS
/variable/CMAKE_CUDA_STANDARD
/variable/CMAKE_CUDA_STANDARD_REQUIRED
/variable/CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
/variable/CMAKE_CXX_COMPILE_FEATURES
/variable/CMAKE_CXX_EXTENSIONS
/variable/CMAKE_CXX_STANDARD
/variable/CMAKE_CXX_STANDARD_REQUIRED
/variable/CMAKE_C_COMPILE_FEATURES
/variable/CMAKE_C_EXTENSIONS
/variable/CMAKE_C_STANDARD
/variable/CMAKE_C_STANDARD_REQUIRED
/variable/CMAKE_Fortran_MODDIR_DEFAULT
/variable/CMAKE_Fortran_MODDIR_FLAG
/variable/CMAKE_Fortran_MODOUT_FLAG
/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_MACHINE
/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_PREFIX
/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_SUFFIX
/variable/CMAKE_LANG_ARCHIVE_APPEND
/variable/CMAKE_LANG_ARCHIVE_CREATE
/variable/CMAKE_LANG_ARCHIVE_FINISH
/variable/CMAKE_LANG_COMPILER
/variable/CMAKE_LANG_COMPILER_EXTERNAL_TOOLCHAIN
/variable/CMAKE_LANG_COMPILER_ID
/variable/CMAKE_LANG_COMPILER_LOADED
/variable/CMAKE_LANG_COMPILER_PREDEFINES_COMMAND
/variable/CMAKE_LANG_COMPILER_TARGET
/variable/CMAKE_LANG_COMPILER_VERSION
/variable/CMAKE_LANG_COMPILE_OBJECT
/variable/CMAKE_LANG_CREATE_SHARED_LIBRARY
/variable/CMAKE_LANG_CREATE_SHARED_MODULE
/variable/CMAKE_LANG_CREATE_STATIC_LIBRARY
/variable/CMAKE_LANG_FLAGS
/variable/CMAKE_LANG_FLAGS_CONFIG
/variable/CMAKE_LANG_FLAGS_CONFIG_INIT
/variable/CMAKE_LANG_FLAGS_DEBUG
/variable/CMAKE_LANG_FLAGS_DEBUG_INIT
/variable/CMAKE_LANG_FLAGS_INIT
/variable/CMAKE_LANG_FLAGS_MINSIZEREL
/variable/CMAKE_LANG_FLAGS_MINSIZEREL_INIT
/variable/CMAKE_LANG_FLAGS_RELEASE
/variable/CMAKE_LANG_FLAGS_RELEASE_INIT
/variable/CMAKE_LANG_FLAGS_RELWITHDEBINFO
/variable/CMAKE_LANG_FLAGS_RELWITHDEBINFO_INIT
/variable/CMAKE_LANG_IGNORE_EXTENSIONS
/variable/CMAKE_LANG_IMPLICIT_INCLUDE_DIRECTORIES
/variable/CMAKE_LANG_IMPLICIT_LINK_DIRECTORIES
/variable/CMAKE_LANG_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES
/variable/CMAKE_LANG_IMPLICIT_LINK_LIBRARIES
/variable/CMAKE_LANG_LIBRARY_ARCHITECTURE
/variable/CMAKE_LANG_LINKER_PREFERENCE
/variable/CMAKE_LANG_LINKER_PREFERENCE_PROPAGATES
/variable/CMAKE_LANG_LINKER_WRAPPER_FLAG
/variable/CMAKE_LANG_LINKER_WRAPPER_FLAG_SEP
/variable/CMAKE_LANG_LINK_EXECUTABLE
/variable/CMAKE_LANG_OUTPUT_EXTENSION
/variable/CMAKE_LANG_SIMULATE_ID
/variable/CMAKE_LANG_SIMULATE_VERSION
/variable/CMAKE_LANG_SIZEOF_DATA_PTR
/variable/CMAKE_LANG_SOURCE_FILE_EXTENSIONS
/variable/CMAKE_LANG_STANDARD_INCLUDE_DIRECTORIES
/variable/CMAKE_LANG_STANDARD_LIBRARIES
/variable/CMAKE_OBJC_EXTENSIONS
/variable/CMAKE_OBJC_STANDARD
/variable/CMAKE_OBJC_STANDARD_REQUIRED
/variable/CMAKE_OBJCXX_EXTENSIONS
/variable/CMAKE_OBJCXX_STANDARD
/variable/CMAKE_OBJCXX_STANDARD_REQUIRED
/variable/CMAKE_Swift_LANGUAGE_VERSION
/variable/CMAKE_USER_MAKE_RULES_OVERRIDE_LANG
Variables for CTest
===================
.. toctree::
:maxdepth: 1
/variable/CTEST_BINARY_DIRECTORY
/variable/CTEST_BUILD_COMMAND
/variable/CTEST_BUILD_NAME
/variable/CTEST_BZR_COMMAND
/variable/CTEST_BZR_UPDATE_OPTIONS
/variable/CTEST_CHANGE_ID
/variable/CTEST_CHECKOUT_COMMAND
/variable/CTEST_CONFIGURATION_TYPE
/variable/CTEST_CONFIGURE_COMMAND
/variable/CTEST_COVERAGE_COMMAND
/variable/CTEST_COVERAGE_EXTRA_FLAGS
/variable/CTEST_CURL_OPTIONS
/variable/CTEST_CUSTOM_COVERAGE_EXCLUDE
/variable/CTEST_CUSTOM_ERROR_EXCEPTION
/variable/CTEST_CUSTOM_ERROR_MATCH
/variable/CTEST_CUSTOM_ERROR_POST_CONTEXT
/variable/CTEST_CUSTOM_ERROR_PRE_CONTEXT
/variable/CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE
/variable/CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS
/variable/CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS
/variable/CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE
/variable/CTEST_CUSTOM_MEMCHECK_IGNORE
/variable/CTEST_CUSTOM_POST_MEMCHECK
/variable/CTEST_CUSTOM_POST_TEST
/variable/CTEST_CUSTOM_PRE_MEMCHECK
/variable/CTEST_CUSTOM_PRE_TEST
/variable/CTEST_CUSTOM_TESTS_IGNORE
/variable/CTEST_CUSTOM_WARNING_EXCEPTION
/variable/CTEST_CUSTOM_WARNING_MATCH
/variable/CTEST_CVS_CHECKOUT
/variable/CTEST_CVS_COMMAND
/variable/CTEST_CVS_UPDATE_OPTIONS
/variable/CTEST_DROP_LOCATION
/variable/CTEST_DROP_METHOD
/variable/CTEST_DROP_SITE
/variable/CTEST_DROP_SITE_CDASH
/variable/CTEST_DROP_SITE_PASSWORD
/variable/CTEST_DROP_SITE_USER
/variable/CTEST_EXTRA_COVERAGE_GLOB
/variable/CTEST_GIT_COMMAND
/variable/CTEST_GIT_INIT_SUBMODULES
/variable/CTEST_GIT_UPDATE_CUSTOM
/variable/CTEST_GIT_UPDATE_OPTIONS
/variable/CTEST_HG_COMMAND
/variable/CTEST_HG_UPDATE_OPTIONS
/variable/CTEST_LABELS_FOR_SUBPROJECTS
/variable/CTEST_MEMORYCHECK_COMMAND
/variable/CTEST_MEMORYCHECK_COMMAND_OPTIONS
/variable/CTEST_MEMORYCHECK_SANITIZER_OPTIONS
/variable/CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
/variable/CTEST_MEMORYCHECK_TYPE
/variable/CTEST_NIGHTLY_START_TIME
/variable/CTEST_P4_CLIENT
/variable/CTEST_P4_COMMAND
/variable/CTEST_P4_OPTIONS
/variable/CTEST_P4_UPDATE_OPTIONS
/variable/CTEST_RESOURCE_SPEC_FILE
/variable/CTEST_RUN_CURRENT_SCRIPT
/variable/CTEST_SCP_COMMAND
/variable/CTEST_SITE
/variable/CTEST_SUBMIT_URL
/variable/CTEST_SOURCE_DIRECTORY
/variable/CTEST_SVN_COMMAND
/variable/CTEST_SVN_OPTIONS
/variable/CTEST_SVN_UPDATE_OPTIONS
/variable/CTEST_TEST_LOAD
/variable/CTEST_TEST_TIMEOUT
/variable/CTEST_TRIGGER_SITE
/variable/CTEST_UPDATE_COMMAND
/variable/CTEST_UPDATE_OPTIONS
/variable/CTEST_UPDATE_VERSION_ONLY
/variable/CTEST_UPDATE_VERSION_OVERRIDE
/variable/CTEST_USE_LAUNCHERS
Variables for CPack
===================
.. toctree::
:maxdepth: 1
/variable/CPACK_ABSOLUTE_DESTINATION_FILES
/variable/CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY
/variable/CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
/variable/CPACK_INCLUDE_TOPLEVEL_DIRECTORY
/variable/CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
/variable/CPACK_PACKAGING_INSTALL_PREFIX
/variable/CPACK_SET_DESTDIR
/variable/CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
Variable Expansion Operators
============================
.. toctree::
:maxdepth: 1
/variable/CACHE
/variable/ENV
Internal Variables
==================
CMake has many internal variables. Most of them are undocumented.
Some of them, however, were at some point described as normal
variables, and therefore may be encountered in legacy code. They
are subject to change, and not recommended for use in project code.
.. toctree::
:maxdepth: 1
/variable/CMAKE_HOME_DIRECTORY
/variable/CMAKE_INTERNAL_PLATFORM_ABI
/variable/CMAKE_LANG_COMPILER_ABI
/variable/CMAKE_LANG_COMPILER_ARCHITECTURE_ID
/variable/CMAKE_LANG_COMPILER_VERSION_INTERNAL
/variable/CMAKE_LANG_PLATFORM_ID
/variable/CMAKE_NOT_USING_CONFIG_FLAGS
/variable/CMAKE_VS_INTEL_Fortran_PROJECT_VERSION

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

@ -0,0 +1,804 @@
.. 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

29
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cpack-generators.7.rst Normal file
View File

@ -0,0 +1,29 @@
.. cmake-manual-description: CPack Generator Reference
cpack-generators(7)
*******************
.. only:: html
.. contents::
Generators
==========
.. toctree::
:maxdepth: 1
/cpack_gen/archive
/cpack_gen/bundle
/cpack_gen/cygwin
/cpack_gen/deb
/cpack_gen/dmg
/cpack_gen/external
/cpack_gen/freebsd
/cpack_gen/ifw
/cpack_gen/nsis
/cpack_gen/nuget
/cpack_gen/packagemaker
/cpack_gen/productbuild
/cpack_gen/rpm
/cpack_gen/wix

113
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/cpack.1.rst Normal file
View File

@ -0,0 +1,113 @@
.. cmake-manual-description: CPack Command-Line Reference
cpack(1)
********
Synopsis
========
.. parsed-literal::
cpack [<options>]
Description
===========
The **cpack** executable is the CMake packaging program. It generates
installers and source packages in a variety of formats.
For each installer or package format, **cpack** has a specific backend,
called "generator". A generator is responsible for generating the required
inputs and invoking the specific package creation tools. These installer
or package generators are not to be confused with the makefile generators
of the :manual:`cmake <cmake(1)>` command.
All supported generators are specified in the :manual:`cpack-generators
<cpack-generators(7)>` manual. The command ``cpack --help`` prints a
list of generators supported for the target platform. Which of them are
to be used can be selected through the :variable:`CPACK_GENERATOR` variable
or through the command-line option ``-G``.
The **cpack** program is steered by a configuration file written in the
:manual:`CMake language <cmake-language(7)>`. Unless chosen differently
through the command-line option ``--config``, the file ``CPackConfig.cmake``
in the current directory is used.
In the standard CMake workflow, the file ``CPackConfig.cmake`` is generated
by the :manual:`cmake <cmake(1)>` executable, provided the :module:`CPack`
module is included by the project's ``CMakeLists.txt`` file.
Options
=======
``-G <generators>``
``<generators>`` is a :ref:`semicolon-separated list <CMake Language Lists>`
of generator names. ``cpack`` will iterate through this list and produce
package(s) in that generator's format according to the details provided in
the ``CPackConfig.cmake`` configuration file. If this option is not given,
the :variable:`CPACK_GENERATOR` variable determines the default set of
generators that will be used.
``-C <configs>``
Specify the project configuration(s) to be packaged (e.g. ``Debug``,
``Release``, etc.), where ``<configs>`` is a
:ref:`semicolon-separated list <CMake Language Lists>`.
When the CMake project uses a multi-configuration
generator such as Xcode or Visual Studio, this option is needed to tell
``cpack`` which built executables to include in the package.
The user is responsible for ensuring that the configuration(s) listed
have already been built before invoking ``cpack``.
``-D <var>=<value>``
Set a CPack variable. This will override any value set for ``<var>`` in the
input file read by ``cpack``.
``--config <configFile>``
Specify the configuration file read by ``cpack`` to provide the packaging
details. By default, ``CPackConfig.cmake`` in the current directory will
be used.
``--verbose, -V``
Run ``cpack`` with verbose output. This can be used to show more details
from the package generation tools and is suitable for project developers.
``--debug``
Run ``cpack`` with debug output. This option is intended mainly for the
developers of ``cpack`` itself and is not normally needed by project
developers.
``--trace``
Put the underlying cmake scripts in trace mode.
``--trace-expand``
Put the underlying cmake scripts in expanded trace mode.
``-P <packageName>``
Override/define the value of the :variable:`CPACK_PACKAGE_NAME` variable used
for packaging. Any value set for this variable in the ``CPackConfig.cmake``
file will then be ignored.
``-R <packageVersion>``
Override/define the value of the :variable:`CPACK_PACKAGE_VERSION`
variable used for packaging. It will override a value set in the
``CPackConfig.cmake`` file or one automatically computed from
:variable:`CPACK_PACKAGE_VERSION_MAJOR`,
:variable:`CPACK_PACKAGE_VERSION_MINOR` and
:variable:`CPACK_PACKAGE_VERSION_PATCH`.
``-B <packageDirectory>``
Override/define :variable:`CPACK_PACKAGE_DIRECTORY`, which controls the
directory where CPack will perform its packaging work. The resultant
package(s) will be created at this location by default and a
``_CPack_Packages`` subdirectory will also be created below this directory to
use as a working area during package creation.
``--vendor <vendorName>``
Override/define :variable:`CPACK_PACKAGE_VENDOR`.
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

1593
6.5.1/_tools/cmake/share/cmake-3.18/Help/manual/ctest.1.rst Normal file
View File

File diff suppressed because it is too large Load Diff