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

qt 6.5.3

Browse Source
This commit is contained in:
kleuter
2023-11-01 21:39:10 +01:00
parent 5c4154eda2
commit 94b1c5907b
3387 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
6.5.3/_tools/cmake/share/cmake-3.27/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.3/_tools/cmake/share/cmake-3.27/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.

171
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/OPTIONS_BUILD.txt Normal file
View File

@ -0,0 +1,171 @@
.. option:: -S <path-to-source>
Path to root directory of the CMake project to build.
.. option:: -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.
.. option:: -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.
.. option:: -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>``.
It's important to note that the order of ``-C`` and ``-D`` arguments is
significant. They will be carried out in the order they are listed, with the
last argument taking precedence over the previous ones. For example, if you
specify ``-DCMAKE_BUILD_TYPE=Debug``, followed by a ``-C`` argument with a
file that calls:
.. code-block:: cmake
set(CMAKE_BUILD_TYPE "Release" CACHE STRING "" FORCE)
then the ``-C`` argument will take precedence, and ``CMAKE_BUILD_TYPE`` will
be set to ``Release``. However, if the ``-D`` argument comes after the ``-C``
argument, it will be set to ``Debug``.
If a ``set(... CACHE ...)`` call in the ``-C`` file does not use ``FORCE``,
and a ``-D`` argument sets the same variable, the ``-D`` argument will take
precedence regardless of order because of the nature of non-``FORCE``
``set(... CACHE ...)`` calls.
.. option:: -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.
.. option:: -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.
.. option:: -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.
.. option:: -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.
.. option:: --toolchain <path-to-file>
Specify the cross compiling toolchain file, equivalent to setting
:variable:`CMAKE_TOOLCHAIN_FILE` variable.
.. option:: --install-prefix <directory>
Specify the installation directory, used by the
:variable:`CMAKE_INSTALL_PREFIX` variable. Must be an absolute path.
.. option:: -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.
.. option:: -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.
.. option:: -Wdeprecated
Enable deprecated functionality warnings.
Enable warnings for usage of deprecated functionality, that are meant
for the author of the ``CMakeLists.txt`` files.
.. option:: -Wno-deprecated
Suppress deprecated functionality warnings.
Suppress warnings for usage of deprecated functionality, that are meant
for the author of the ``CMakeLists.txt`` files.
.. option:: -Werror=<what>
Treat CMake warnings as errors. ``<what>`` must be one of the following:
``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.
``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.
.. option:: -Wno-error=<what>
Do not treat CMake warnings as errors. ``<what>`` must be one of the following:
``dev``
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.
``deprecated``
Make warnings for usage of deprecated macros and functions, that are meant
for the author of the ``CMakeLists.txt`` files, not errors.

154
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/OPTIONS_HELP.txt Normal file
View File

@ -0,0 +1,154 @@
.. |file| replace:: The output is printed to a named ``<file>`` if given.
.. option:: -version [<file>], --version [<file>], /V [<file>]
Show program name/version banner and exit.
|file|
.. option:: -h, -H, --help, -help, -usage, /?
Print usage information and exit.
Usage describes the basic command line interface and its options.
.. option:: --help-full [<file>]
Print all help manuals and exit.
All manuals are printed in a human-readable text format.
|file|
.. option:: --help-manual <man> [<file>]
Print one help manual and exit.
The specified manual is printed in a human-readable text format.
|file|
.. option:: --help-manual-list [<file>]
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|
.. option:: --help-command <cmd> [<file>]
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|
.. option:: --help-command-list [<file>]
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|
.. option:: --help-commands [<file>]
Print cmake-commands manual and exit.
The :manual:`cmake-commands(7)` manual is printed in a
human-readable text format.
|file|
.. option:: --help-module <mod> [<file>]
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|
.. option:: --help-module-list [<file>]
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|
.. option:: --help-modules [<file>]
Print cmake-modules manual and exit.
The :manual:`cmake-modules(7)` manual is printed in a human-readable
text format.
|file|
.. option:: --help-policy <cmp> [<file>]
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|
.. option:: --help-policy-list [<file>]
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|
.. option:: --help-policies [<file>]
Print cmake-policies manual and exit.
The :manual:`cmake-policies(7)` manual is printed in a
human-readable text format.
|file|
.. option:: --help-property <prop> [<file>]
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|
.. option:: --help-property-list [<file>]
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|
.. option:: --help-properties [<file>]
Print cmake-properties manual and exit.
The :manual:`cmake-properties(7)` manual is printed in a
human-readable text format.
|file|
.. option:: --help-variable <var> [<file>]
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|
.. option:: --help-variable-list [<file>]
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|
.. option:: --help-variables [<file>]
Print cmake-variables manual and exit.
The :manual:`cmake-variables(7)` manual is printed in a
human-readable text format.
|file|

40
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/ccmake.1.rst Normal file
View File

@ -0,0 +1,40 @@
.. cmake-manual-description: CMake Curses Dialog Command-Line Reference
ccmake(1)
*********
Synopsis
========
.. parsed-literal::
ccmake [<options>] -B <path-to-build> [-S <path-to-source>]
ccmake [<options>] <path-to-source | path-to-existing-build>
Description
===========
The :program:`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
=======
.. program:: ccmake
.. include:: OPTIONS_BUILD.txt
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

1115
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-buildsystem.7.rst Normal file
View File

File diff suppressed because it is too large Load Diff

177
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-commands.7.rst Normal file
View File

@ -0,0 +1,177 @@
.. cmake-manual-description: CMake Language Command Reference
cmake-commands(7)
*****************
.. only:: html
.. contents::
Scripting Commands
==================
These commands are always available.
.. toctree::
:maxdepth: 1
/command/block
/command/break
/command/cmake_host_system_information
/command/cmake_language
/command/cmake_minimum_required
/command/cmake_parse_arguments
/command/cmake_path
/command/cmake_policy
/command/configure_file
/command/continue
/command/else
/command/elseif
/command/endblock
/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/cmake_file_api
/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

306
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-compile-features.7.rst Normal file
View File

@ -0,0 +1,306 @@
.. 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`:
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``).
.. include:: ../prop_gbl/CMAKE_LANG_STD_FLAGS.txt
Availability of Compiler Extensions
-----------------------------------
The :prop_tgt:`<LANG>_EXTENSIONS` target property defaults to the compiler's
default (see :variable:`CMAKE_<LANG>_EXTENSIONS_DEFAULT`). Note that because
most compilers enable extensions by default, this may expose portability bugs
in user code or in the headers of third-party dependencies.
:prop_tgt:`<LANG>_EXTENSIONS` used to default to ``ON``. See :policy:`CMP0128`.
Optional Compile Features
=========================
Compile features may be preferred if available, without creating a hard
requirement. This can be achieved by *not* specifying features with
:command:`target_compile_features` and instead checking the compiler
capabilities with preprocessor conditions in project code.
In this use-case, the project may wish to establish a particular language
standard if available from the compiler, and use preprocessor conditions
to detect the features actually available. A language standard may be
established by `Requiring Language Standards`_ using
:command:`target_compile_features` with meta-features like ``cxx_std_11``,
or by setting the :prop_tgt:`CXX_STANDARD` target property or
:variable:`CMAKE_CXX_STANDARD` variable.
See also policy :policy:`CMP0120` and legacy documentation on
:ref:`Example Usage <WCDH Example Usage>` of the deprecated
:module:`WriteCompilerDetectionHeader` module.
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 may be possible to write an abstraction ``interface.h`` header
containing something like:
.. code-block:: c++
#ifdef HAVE_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+.
* ``Fujitsu``: Fujitsu HPC compiler 4.0+.
* ``PGI``: PGI version 12.10+.
* ``NVHPC``: NVIDIA HPC compilers version 11.0+.
* ``TI``: Texas Instruments compiler.
* ``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++.
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:
* ``Clang``: Clang compiler 5.0+.
* ``NVIDIA``: NVIDIA nvcc compiler 7.5+.
.. _`Language Standard Flags`:
Language Standard Flags
=======================
In order to satisfy requirements specified by the
:command:`target_compile_features` command or the
:variable:`CMAKE_<LANG>_STANDARD` variable, CMake may pass a
language standard flag to the compiler, such as ``-std=c++11``.
For :ref:`Visual Studio Generators`, CMake cannot precisely control
the placement of the language standard flag on the compiler command line.
For :ref:`Ninja Generators`, :ref:`Makefile Generators`, and
:generator:`Xcode`, CMake places the language standard flag just after
the language-wide flags from :variable:`CMAKE_<LANG>_FLAGS`
and :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>`.
.. versionchanged:: 3.26
The language standard flag is placed before flags specified by other
abstractions such as the :command:`target_compile_options` command.
Prior to CMake 3.26, the language standard flag was placed after them.

334
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-configure-log.7.rst Normal file
View File

@ -0,0 +1,334 @@
.. cmake-manual-description: CMake Configure Log
cmake-configure-log(7)
**********************
.. versionadded:: 3.26
.. only:: html
.. contents::
Introduction
============
CMake writes a running log, known as the *configure log*,
of certain events that occur during the Configure step.
The configure log does *not* contain a log of all output, errors,
or messages printed while configuring a project. It is a log of
detailed information about specific events, such as toolchain inspection
by :command:`try_compile`, meant for use in debugging the configuration
of a build tree.
For human use, this version of CMake writes the configure log to the file::
${CMAKE_BINARY_DIR}/CMakeFiles/CMakeConfigureLog.yaml
However, the *location and name of the log file may change* in future
versions of CMake. Tools that read the configure log should get its
location using a :ref:`configureLog <file-api configureLog>` query to
the :manual:`cmake-file-api(7)`.
See the `Log Versioning`_ section below for details.
Log Structure
=============
The configure log is designed to be both machine- and human-readable.
The log file is a YAML document stream containing zero or more YAML
documents separated by document markers. Each document begins
with a ``---`` document marker line, contains a single YAML mapping
that logs events from one CMake "configure" step, and, if the configure
step finished normally, ends with a ``...`` document marker line:
.. code-block:: yaml
---
events:
-
kind: "try_compile-v1"
# (other fields omitted)
-
kind: "try_compile-v1"
# (other fields omitted)
...
A new document is appended to the log every time CMake configures
the build tree and logs new events.
The keys of the each document root mapping are:
``events``
A YAML block sequence of nodes corresponding to events logged during
one CMake "configure" step. Each event is a YAML node containing one
of the `Event Kinds`_ documented below.
Log Versioning
--------------
Each of the `Event Kinds`_ is versioned independently. The set of
keys an event's log entry provides is specific to its major version.
When an event is logged, the latest version of its event kind that is
known to the running version of CMake is always written to the log.
Tools reading the configure log must ignore event kinds and versions
they do not understand:
* A future version of CMake may introduce a new event kind or version.
* If an existing build tree is re-configured with a different version of
CMake, the log may contain different versions of the same event kind.
* If :manual:`cmake-file-api(7)` queries request one or more
:ref:`configureLog <file-api configureLog>` object versions,
the log may contain multiple entries for the same event, each
with a different version of its event kind.
IDEs should write a :manual:`cmake-file-api(7)` query requesting a
specific :ref:`configureLog <file-api configureLog>` object version,
before running CMake, and then read the configure log only as described
by the file-api reply.
Text Block Encoding
-------------------
In order to make the log human-readable, text blocks are always
represented using YAML literal block scalars (``|``).
Since literal block scalars do not support escaping, backslashes
and non-printable characters are encoded at the application layer:
* ``\\`` encodes a backslash.
* ``\xXX`` encodes a byte using two hexadecimal digits, ``XX``.
.. _`configure-log event kinds`:
Event Kinds
===========
Every event kind is represented by a YAML mapping of the form:
.. code-block:: yaml
kind: "<kind>-v<major>"
backtrace:
- "<file>:<line> (<function>)"
checks:
- "Checking for something"
#...event-specific keys...
The keys common to all events are:
``kind``
A string identifying the event kind and major version.
``backtrace``
A YAML block sequence reporting the call stack of CMake source
locations at which the event occurred, from most-recent to
least-recent. Each node is a string specifying one location
formatted as ``<file>:<line> (<function>)``.
``checks``
An optional key that is present when the event occurred with
at least one pending :command:`message(CHECK_START)`. Its value
is a YAML block sequence reporting the stack of pending checks,
from most-recent to least-recent. Each node is a string containing
a pending check message.
Additional mapping keys are specific to each (versioned) event kind,
described below.
.. _`message configure-log event`:
Event Kind ``message``
----------------------
The :command:`message(CONFIGURE_LOG)` command logs ``message`` events.
There is only one ``message`` event major version, version 1.
.. _`message-v1 event`:
``message-v1`` Event
^^^^^^^^^^^^^^^^^^^^
A ``message-v1`` event is a YAML mapping:
.. code-block:: yaml
kind: "message-v1"
backtrace:
- "CMakeLists.txt:123 (message)"
checks:
- "Checking for something"
message: |
# ...
The keys specific to ``message-v1`` mappings are:
``message``
A YAML literal block scalar containing the message text,
represented using our `Text Block Encoding`_.
.. _`try_compile configure-log event`:
Event Kind ``try_compile``
--------------------------
The :command:`try_compile` command logs ``try_compile`` events.
There is only one ``try_compile`` event major version, version 1.
.. _`try_compile-v1 event`:
``try_compile-v1`` Event
^^^^^^^^^^^^^^^^^^^^^^^^
A ``try_compile-v1`` event is a YAML mapping:
.. code-block:: yaml
kind: "try_compile-v1"
backtrace:
- "CMakeLists.txt:123 (try_compile)"
checks:
- "Checking for something"
description: "Explicit LOG_DESCRIPTION"
directories:
source: "/path/to/.../TryCompile-01234"
binary: "/path/to/.../TryCompile-01234"
cmakeVariables:
SOME_VARIABLE: "Some Value"
buildResult:
variable: "COMPILE_RESULT"
cached: true
stdout: |
# ...
exitCode: 0
The keys specific to ``try_compile-v1`` mappings are:
``description``
An optional key that is present when the ``LOG_DESCRIPTION <text>`` option
was used. Its value is a string containing the description ``<text>``.
``directories``
A mapping describing the directories associated with the
compilation attempt. It has the following keys:
``source``
String specifying the source directory of the
:command:`try_compile` project.
``binary``
String specifying the binary directory of the
:command:`try_compile` project.
For non-project invocations, this is often the same as
the source directory.
``cmakeVariables``
An optional key that is present when CMake propagates variables
into the test project, either automatically or due to the
:variable:`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable.
Its value is a mapping from variable names to their values.
``buildResult``
A mapping describing the result of compiling the test code.
It has the following keys:
``variable``
A string specifying the name of the CMake variable
storing the result of trying to build the test project.
``cached``
A boolean indicating whether the above result ``variable``
is stored in the CMake cache.
``stdout``
A YAML literal block scalar containing the output from building
the test project, represented using our `Text Block Encoding`_.
This contains build output from both stdout and stderr.
``exitCode``
An integer specifying the build tool exit code from trying
to build the test project.
.. _`try_run configure-log event`:
Event Kind ``try_run``
----------------------
The :command:`try_run` command logs ``try_run`` events.
There is only one ``try_run`` event major version, version 1.
.. _`try_run-v1 event`:
``try_run-v1`` Event
^^^^^^^^^^^^^^^^^^^^
A ``try_run-v1`` event is a YAML mapping:
.. code-block:: yaml
kind: "try_run-v1"
backtrace:
- "CMakeLists.txt:456 (try_run)"
checks:
- "Checking for something"
description: "Explicit LOG_DESCRIPTION"
directories:
source: "/path/to/.../TryCompile-56789"
binary: "/path/to/.../TryCompile-56789"
buildResult:
variable: "COMPILE_RESULT"
cached: true
stdout: |
# ...
exitCode: 0
runResult:
variable: "RUN_RESULT"
cached: true
stdout: |
# ...
stderr: |
# ...
exitCode: 0
The keys specific to ``try_run-v1`` mappings include those
documented by the `try_compile-v1 event`_, plus:
``runResult``
A mapping describing the result of running the test code.
It has the following keys:
``variable``
A string specifying the name of the CMake variable
storing the result of trying to run the test executable.
``cached``
A boolean indicating whether the above result ``variable``
is stored in the CMake cache.
``stdout``
An optional key that is present when the test project built successfully.
Its value is a YAML literal block scalar containing output from running
the test executable, represented using our `Text Block Encoding`_.
If ``RUN_OUTPUT_VARIABLE`` was used, stdout and stderr are captured
together, so this will contain both. Otherwise, this will contain
only the stdout output.
``stderr``
An optional key that is present when the test project built successfully
and the ``RUN_OUTPUT_VARIABLE`` option was not used.
Its value is a YAML literal block scalar containing output from running
the test executable, represented using our `Text Block Encoding`_.
If ``RUN_OUTPUT_VARIABLE`` was used, stdout and stderr are captured
together in the ``stdout`` key, and this key will not be present.
Otherwise, this will contain the stderr output.
``exitCode``
An optional key that is present when the test project built successfully.
Its value is an integer specifying the exit code, or a string containing
an error message, from trying to run the test executable.

579
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-developer.7.rst Normal file
View File

@ -0,0 +1,579 @@
.. 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.
Accessing Windows Registry
==========================
CMake offers some facilities to access the registry on ``Windows`` platforms.
Query Windows Registry
----------------------
.. versionadded:: 3.24
The :command:`cmake_host_system_information` command offers the possibility to
query the registry on the local computer. See
:ref:`cmake_host_system(QUERY_WINDOWS_REGISTRY) <Query Windows registry>` for
more information.
.. _`Find Using Windows Registry`:
Find Using Windows Registry
---------------------------
.. versionchanged:: 3.24
Options ``HINTS`` and ``PATHS`` of :command:`find_file`,
:command:`find_library`, :command:`find_path`, :command:`find_program`, and
:command:`find_package` commands offer the possibility, on ``Windows``
platform, to query the registry.
The formal syntax, as specified using
`BNF <https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form>`_ notation with
the regular extensions, for registry query is the following:
.. raw:: latex
\begin{small}
.. productionlist::
registry_query: '[' `sep_definition`? `root_key`
: ((`key_separator` `sub_key`)? (`value_separator` `value_name`_)?)? ']'
sep_definition: '{' `value_separator` '}'
root_key: 'HKLM' | 'HKEY_LOCAL_MACHINE' | 'HKCU' | 'HKEY_CURRENT_USER' |
: 'HKCR' | 'HKEY_CLASSES_ROOT' | 'HKCC' | 'HKEY_CURRENT_CONFIG' |
: 'HKU' | 'HKEY_USERS'
sub_key: `element` (`key_separator` `element`)*
key_separator: '/' | '\\'
value_separator: `element` | ';'
value_name: `element` | '(default)'
element: `character`\+
character: <any character except `key_separator` and `value_separator`>
.. raw:: latex
\end{small}
The :token:`sep_definition` optional item offers the possibility to specify
the string used to separate the :token:`sub_key` from the :token:`value_name`
item. If not specified, the character ``;`` is used. Multiple
:token:`registry_query` items can be specified as part of a path.
.. code-block:: cmake
# example using default separator
find_file(... PATHS "/root/[HKLM/Stuff;InstallDir]/lib[HKLM\\\\Stuff;Architecture]")
# example using different specified separators
find_library(... HINTS "/root/[{|}HKCU/Stuff|InstallDir]/lib[{@@}HKCU\\\\Stuff@@Architecture]")
If the :token:`value_name` item is not specified or has the special name
``(default)``, the content of the default value, if any, will be returned. The
supported types for the :token:`value_name` are:
* ``REG_SZ``.
* ``REG_EXPAND_SZ``. The returned data is expanded.
* ``REG_DWORD``.
* ``REG_QWORD``.
When the registry query failed, typically because the key does not exist or
the data type is not supported, the string ``/REGISTRY-NOTFOUND`` is substituted
to the ``[]`` query expression.
.. _`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 is
available, 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_``, which (unless otherwise noted) must match exactly the name
of the ``FindXxx.cmake`` file, including upper/lowercase.
This prefix on the variable names ensures that they do not conflict with
variables of other Find modules. The same pattern should also be followed
for any macros, functions and imported targets defined by the Find module.
``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 (note that this also means
this variable should not be used as the result variable of a
:command:`find_path` command - see ``Xxx_INCLUDE_DIR`` below for that).
``Xxx_LIBRARIES``
The libraries to use with the module. These may be CMake targets, full
absolute paths to a library binary or the name of a library that the
linker must find in its search path. This should not be a cache entry
(note that this also means this variable should not be used as the
result variable of a :command:`find_library` command - see
``Xxx_LIBRARY`` below for that).
``Xxx_DEFINITIONS``
The compile definitions to use when compiling code that uses the module.
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``
The full absolute path to an executable. In this case, ``Xxx`` might not
be the name of the module, it might be the name of the tool (usually
converted to all uppercase), assuming that tool has such a well-known name
that it is unlikely that another tool with the same name exists. It would
be appropriate to use this as the result variable of a
:command:`find_program` command.
``Xxx_YYY_EXECUTABLE``
Similar to ``Xxx_EXECUTABLE`` except here the ``Xxx`` is always the module
name and ``YYY`` is the tool name (again, usually fully uppercase).
Prefer this form if the tool name is not very widely known or has the
potential to clash with another tool. For greater consistency, also
prefer this form if the module provides more than one executable.
``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 the module.
``Xxx_VERSION_VV``
Variables of this form specify whether the ``Xxx`` module being provided
is version ``VV`` of the module. There should not be more than one
variable of this form set to true for a given module. For example, a
module ``Barry`` might have evolved over many years and gone through a
number of different major versions. Version 3 of the ``Barry`` module
might set the variable ``Barry_VERSION_3`` to true, whereas an older
version of the module might set ``Barry_VERSION_2`` to true instead.
It would be an error for both ``Barry_VERSION_3`` and ``Barry_VERSION_2``
to both be set to true.
``Xxx_WRAP_YY``
When a variable of this form is set to false, it indicates that the
relevant wrapping command should not be used. The wrapping command
depends on the module, it may be implied by the module name or it might
be specified by the ``YY`` part of the variable.
``Xxx_Yy_FOUND``
For variables of this form, ``Yy`` is the name of a component for the
module. It should match exactly one of the valid component names that
may be passed to the :command:`find_package` command for the module.
If a variable of this form is set to false, it means that the ``Yy``
component of module ``Xxx`` was not found or is not available.
Variables of this form would typically be used for optional components
so that the caller can check whether an optional component is available.
``Xxx_FOUND``
When the :command:`find_package` command returns to the caller, this
variable will be set to true if the module was deemed to have been found
successfully.
``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
:command:`find_package_handle_standard_args` to inform the user about the
problem. Use this instead of calling :command:`message` directly to
report a reason for failing to find the module or package.
``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.
They are intended for use by Find modules to specify and cache the locations
of specific files or directories. Users are typically able to set and edit
these variables to control the behavior of Find modules (like entering the
path to a library manually):
``Xxx_LIBRARY``
The path of the library. Use this form only when the module provides a
single library. It is appropriate to use this as the result variable
in a :command:`find_library` command.
``Xxx_Yy_LIBRARY``
The path of library ``Yy`` provided by the module ``Xxx``. Use this form
when the module provides more than one library or where other modules may
also provide a library of the same name. It is also appropriate to use
this form as the result variable in a :command:`find_library` command.
``Xxx_INCLUDE_DIR``
When the module provides only a single library, this variable can be used
to specify where to find headers for using the library (or more accurately,
the path that consumers of the library should add to their header search
path). It would be appropriate to use this as the result variable in a
:command:`find_path` command.
``Xxx_Yy_INCLUDE_DIR``
If the module provides more than one library or where other modules may
also provide a library of the same name, this form is recommended for
specifying where to find headers for using library ``Yy`` provided by
the module. Again, it would be appropriate to use this as the result
variable in a :command:`find_path` command.
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``. The :module:`SelectLibraryConfigurations` module
can be helpful for such cases.
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}
)
Alternatively, if the library is available with multiple configurations, you can
use :module:`SelectLibraryConfigurations` to automatically set the
``Foo_LIBRARY`` variable instead:
.. code-block:: cmake
find_library(Foo_LIBRARY_RELEASE
NAMES foo
PATHS ${PC_Foo_LIBRARY_DIRS}/Release
)
find_library(Foo_LIBRARY_DEBUG
NAMES foo
PATHS ${PC_Foo_LIBRARY_DIRS}/Debug
)
include(SelectLibraryConfigurations)
select_library_configurations(Foo)
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 :program:`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})

115
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-env-variables.7.rst Normal file
View File

@ -0,0 +1,115 @@
.. 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_APPBUNDLE_PATH
/envvar/CMAKE_FRAMEWORK_PATH
/envvar/CMAKE_INCLUDE_PATH
/envvar/CMAKE_LIBRARY_PATH
/envvar/CMAKE_MAXIMUM_RECURSION_DEPTH
/envvar/CMAKE_PREFIX_PATH
/envvar/CMAKE_PROGRAM_PATH
/envvar/SSL_CERT_DIR
/envvar/SSL_CERT_FILE
Environment Variables that Control the Build
============================================
.. toctree::
:maxdepth: 1
/envvar/ADSP_ROOT
/envvar/CMAKE_APPLE_SILICON_PROCESSOR
/envvar/CMAKE_BUILD_PARALLEL_LEVEL
/envvar/CMAKE_BUILD_TYPE
/envvar/CMAKE_COLOR_DIAGNOSTICS
/envvar/CMAKE_CONFIGURATION_TYPES
/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_INSTALL_MODE
/envvar/CMAKE_LANG_COMPILER_LAUNCHER
/envvar/CMAKE_LANG_IMPLICIT_LINK_DIRECTORIES_EXCLUDE
/envvar/CMAKE_LANG_LINKER_LAUNCHER
/envvar/CMAKE_MSVCIDE_RUN_PATH
/envvar/CMAKE_NO_VERBOSE
/envvar/CMAKE_OSX_ARCHITECTURES
/envvar/CMAKE_TOOLCHAIN_FILE
/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/CUDAARCHS
/envvar/CUDACXX
/envvar/CUDAFLAGS
/envvar/CUDAHOSTCXX
/envvar/CXX
/envvar/CXXFLAGS
/envvar/FC
/envvar/FFLAGS
/envvar/HIPCXX
/envvar/HIPFLAGS
/envvar/ISPC
/envvar/ISPCFLAGS
/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_NO_TESTS_ACTION
/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

1679
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-file-api.7.rst Normal file
View File

File diff suppressed because it is too large Load Diff

2392
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-generator-expressions.7.rst Normal file
View File

File diff suppressed because it is too large Load Diff

129
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-generators.7.rst Normal file
View File

@ -0,0 +1,129 @@
.. 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
:option:`--help <cmake --help>` output lists available generators on the
current platform. Use its :option:`-G <cmake -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`:
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
/generator/Visual Studio 17 2022
Other Generators
^^^^^^^^^^^^^^^^
.. toctree::
:maxdepth: 1
/generator/Green Hills MULTI
/generator/Xcode
.. _`Extra Generators`:
Extra Generators
================
.. deprecated:: 3.27
Support for "Extra Generators" is deprecated and will be removed from
a future version of CMake. IDEs may use the :manual:`cmake-file-api(7)`
to view CMake-generated project build trees.
Some of the `CMake Generators`_ listed in the :manual:`cmake(1)`
command-line tool :option:`--help <cmake --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

60
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-gui.1.rst Normal file
View File

@ -0,0 +1,60 @@
.. cmake-manual-description: CMake GUI Command-Line Reference
cmake-gui(1)
************
Synopsis
========
.. parsed-literal::
cmake-gui [<options>]
cmake-gui [<options>] -B <path-to-build> [-S <path-to-source>]
cmake-gui [<options>] <path-to-source | path-to-existing-build>
cmake-gui [<options>] --browse-manual [<filename>]
Description
===========
The :program:`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
=======
.. program:: cmake-gui
.. option:: -S <path-to-source>
Path to root directory of the CMake project to build.
.. option:: -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.
.. option:: --preset=<preset-name>
Name of the preset to use from the project's
:manual:`presets <cmake-presets(7)>` files, if it has them.
.. option:: --browse-manual [<filename>]
Open the CMake reference manual in a browser and immediately exit. If
``<filename>`` is specified, open that file within the reference manual
instead of ``index.html``.
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

684
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-language.7.rst Normal file
View File

@ -0,0 +1,684 @@
.. 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 :option:`-P <cmake -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: https://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.
.. ATTENTION 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.
.. ATTENTION 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.
")
.. ATTENTION 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 specified
variable or cache entry, or if neither is set, by the empty string.
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>}``,
and is replaced by the value of the specified cache entry without
checking for a normal variable of the same name. If the cache
entry does not exist, it is replaced by the empty string.
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 variables
always need to be referenced as ``$ENV{<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:
Block Scope
The :command:`block` command may create a new scope for variable bindings.
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 :option:`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>}``, using the
:variable:`ENV` operator.
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.
See the :option:`cmake -E env <cmake-E env>` command-line
tool to run a command in a modified environment.
Inspection
See the :option:`cmake -E environment <cmake-E environment>` command-line
tool to display all current environment variables.
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"
In general, lists do not support elements containing ``;`` characters.
To avoid problems, consider the following advice:
* The interfaces of many CMake commands, variables, and properties accept
semicolon-separated lists. Avoid passing lists with elements containing
semicolons to these interfaces unless they document either direct support
or some way to escape or encode semicolons.
* When constructing a list, substitute an otherwise-unused placeholder
for ``;`` in elements when. Then substitute ``;`` for the placeholder
when processing list elements.
For example, the following code uses ``|`` in place of ``;`` characters:
.. code-block:: cmake
set(mylist a "b|c")
foreach(entry IN LISTS mylist)
string(REPLACE "|" ";" entry "${entry}")
# use "${entry}" normally
endforeach()
The :module:`ExternalProject` module's ``LIST_SEPARATOR`` option is an
example of an interface built using this approach.
* In lists of :manual:`generator expressions <cmake-generator-expressions(7)>`,
use the :genex:`$<SEMICOLON>` generator expression.
* In command calls, use `Quoted Argument`_ syntax whenever possible.
The called command will receive the content of the argument with
semicolons preserved. An `Unquoted Argument`_ will be split on
semicolons.
* In :command:`function` implementations, avoid ``ARGV`` and ``ARGN``,
which do not distinguish semicolons in values from those separating values.
Instead, prefer using named positional arguments and the ``ARGC`` and
``ARGV#`` variables.
When using :command:`cmake_parse_arguments` to parse arguments, prefer
its ``PARSE_ARGV`` signature, which uses the ``ARGV#`` variables.
Note that this approach does not apply to :command:`macro` implementations
because they reference arguments using placeholders, not real variables.

324
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-modules.7.rst Normal file
View File

@ -0,0 +1,324 @@
.. 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/AndroidTestUtilities
/module/BundleUtilities
/module/CheckCCompilerFlag
/module/CheckCompilerFlag
/module/CheckCSourceCompiles
/module/CheckCSourceRuns
/module/CheckCXXCompilerFlag
/module/CheckCXXSourceCompiles
/module/CheckCXXSourceRuns
/module/CheckCXXSymbolExists
/module/CheckFortranCompilerFlag
/module/CheckFortranFunctionExists
/module/CheckFortranSourceCompiles
/module/CheckFortranSourceRuns
/module/CheckFunctionExists
/module/CheckIncludeFileCXX
/module/CheckIncludeFile
/module/CheckIncludeFiles
/module/CheckIPOSupported
/module/CheckLanguage
/module/CheckLibraryExists
/module/CheckLinkerFlag
/module/CheckOBJCCompilerFlag
/module/CheckOBJCSourceCompiles
/module/CheckOBJCSourceRuns
/module/CheckOBJCXXCompilerFlag
/module/CheckOBJCXXSourceCompiles
/module/CheckOBJCXXSourceRuns
/module/CheckPIESupported
/module/CheckPrototypeDefinition
/module/CheckSourceCompiles
/module/CheckSourceRuns
/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/CPack
/module/CPackComponent
/module/CPackIFW
/module/CPackIFWConfigureFile
/module/CSharpUtilities
/module/CTest
/module/CTestCoverageCollectGCOV
/module/CTestScriptMode
/module/CTestUseLaunchers
/module/Dart
/module/DeployQt4
/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/UseJava
/module/UseSWIG
/module/UsewxWidgets
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/FindBacktrace
/module/FindBISON
/module/FindBLAS
/module/FindBoost
/module/FindBullet
/module/FindBZip2
/module/FindCABLE
/module/FindCoin3D
/module/FindCUDAToolkit
/module/FindCups
/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/FindFLTK
/module/FindFLTK2
/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/FindGTK
/module/FindGTK2
/module/FindHDF5
/module/FindHg
/module/FindHSPELL
/module/FindHTMLHelp
/module/FindIce
/module/FindIconv
/module/FindIcotool
/module/FindICU
/module/FindImageMagick
/module/FindIntl
/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/FindLua
/module/FindLua50
/module/FindLua51
/module/FindMatlab
/module/FindMFC
/module/FindMotif
/module/FindMPEG
/module/FindMPEG2
/module/FindMPI
/module/FindMsys
/module/FindODBC
/module/FindOpenACC
/module/FindOpenAL
/module/FindOpenCL
/module/FindOpenGL
/module/FindOpenMP
/module/FindOpenSceneGraph
/module/FindOpenSP
/module/FindOpenSSL
/module/FindOpenThreads
/module/Findosg
/module/Findosg_functions
/module/FindosgAnimation
/module/FindosgDB
/module/FindosgFX
/module/FindosgGA
/module/FindosgIntrospection
/module/FindosgManipulator
/module/FindosgParticle
/module/FindosgPresentation
/module/FindosgProducer
/module/FindosgQt
/module/FindosgShadow
/module/FindosgSim
/module/FindosgTerrain
/module/FindosgText
/module/FindosgUtil
/module/FindosgViewer
/module/FindosgVolume
/module/FindosgWidget
/module/FindPatch
/module/FindPerl
/module/FindPerlLibs
/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
/module/FindSDL_image
/module/FindSDL_gfx
/module/FindSDL_mixer
/module/FindSDL_net
/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/FindVulkan
/module/FindWget
/module/FindWish
/module/FindwxWidgets
/module/FindX11
/module/FindXalanC
/module/FindXCTest
/module/FindXercesC
/module/FindXMLRPC
/module/FindZLIB
Deprecated Modules
^^^^^^^^^^^^^^^^^^^
Deprecated Utility Modules
==========================
.. toctree::
:maxdepth: 1
/module/AddFileDependencies
/module/CMakeDetermineVSServicePack
/module/CMakeExpandImportedTargets
/module/CMakeForceCompiler
/module/CMakeParseArguments
/module/Documentation
/module/MacroAddFileDependencies
/module/TestCXXAcceptsFlag
/module/UseJavaClassFilelist
/module/UseJavaSymlinks
/module/UsePkgConfig
/module/Use_wxWindows
/module/WriteBasicConfigVersionFile
/module/WriteCompilerDetectionHeader
Deprecated Find Modules
=======================
.. toctree::
:maxdepth: 1
/module/FindCUDA
/module/FindITK
/module/FindPythonInterp
/module/FindPythonLibs
/module/FindQt
/module/FindUnixCommands
/module/FindVTK
/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/CPackProductBuild
/module/CPackRPM
/module/CPackWIX

721
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-packages.7.rst Normal file
View File

@ -0,0 +1,721 @@
.. 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``. Likewise, setting the
:variable:`CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>` to ``TRUE`` will make the
package REQUIRED.
.. _`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(_ClimbingStats_supported_components Plot Table)
foreach(_comp ${ClimbingStats_FIND_COMPONENTS})
if (NOT ";${_ClimbingStats_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.

401
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-policies.7.rst Normal file
View File

@ -0,0 +1,401 @@
.. 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.27
=================================
.. toctree::
:maxdepth: 1
CMP0151: AUTOMOC include directory is a system include directory by default. </policy/CMP0151>
CMP0150: ExternalProject_Add and FetchContent_Declare treat relative git repository paths as being relative to parent project's remote. </policy/CMP0150>
CMP0149: Visual Studio generators select latest Windows SDK by default. </policy/CMP0149>
CMP0148: The FindPythonInterp and FindPythonLibs modules are removed. </policy/CMP0148>
CMP0147: Visual Studio generators build custom commands in parallel. </policy/CMP0147>
CMP0146: The FindCUDA module is removed. </policy/CMP0146>
CMP0145: The Dart and FindDart modules are removed. </policy/CMP0145>
CMP0144: find_package uses upper-case PACKAGENAME_ROOT variables. </policy/CMP0144>
Policies Introduced by CMake 3.26
=================================
.. toctree::
:maxdepth: 1
CMP0143: USE_FOLDERS global property is treated as ON by default. </policy/CMP0143>
Policies Introduced by CMake 3.25
=================================
.. toctree::
:maxdepth: 1
CMP0142: The Xcode generator does not append per-config suffixes to library search paths. </policy/CMP0142>
CMP0141: MSVC debug information format flags are selected by an abstraction. </policy/CMP0141>
CMP0140: The return() command checks its arguments. </policy/CMP0140>
Policies Introduced by CMake 3.24
=================================
.. toctree::
:maxdepth: 1
CMP0139: The if() command supports path comparisons using PATH_EQUAL operator. </policy/CMP0139>
CMP0138: CheckIPOSupported uses flags from calling project. </policy/CMP0138>
CMP0137: try_compile() passes platform variables in project mode. </policy/CMP0137>
CMP0136: Watcom runtime library flags are selected by an abstraction. </policy/CMP0136>
CMP0135: ExternalProject ignores timestamps in archives by default for the URL download method. </policy/CMP0135>
CMP0134: Fallback to "HOST" Windows registry view when "TARGET" view is not usable. </policy/CMP0134>
CMP0133: The CPack module disables SLA by default in the CPack DragNDrop Generator. </policy/CMP0133>
CMP0132: Do not set compiler environment variables on first run. </policy/CMP0132>
CMP0131: LINK_LIBRARIES supports the LINK_ONLY generator expression. </policy/CMP0131>
CMP0130: while() diagnoses condition evaluation errors. </policy/CMP0130>
Policies Introduced by CMake 3.23
=================================
.. toctree::
:maxdepth: 1
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU. </policy/CMP0129>
Policies Introduced by CMake 3.22
=================================
.. toctree::
:maxdepth: 1
CMP0128: Selection of language standard and extension flags improved. </policy/CMP0128>
CMP0127: cmake_dependent_option() supports full Condition Syntax. </policy/CMP0127>
Policies Introduced by CMake 3.21
=================================
.. toctree::
:maxdepth: 1
CMP0126: set(CACHE) does not remove a normal variable of the same name. </policy/CMP0126>
CMP0125: find_(path|file|library|program) have consistent behavior for cache variables. </policy/CMP0125>
CMP0124: foreach() loop variables are only available in the loop scope. </policy/CMP0124>
CMP0123: ARMClang cpu/arch compile and link flags must be set explicitly. </policy/CMP0123>
CMP0122: UseSWIG use standard library name conventions for csharp language. </policy/CMP0122>
CMP0121: The list command detects invalid indices. </policy/CMP0121>
Policies Introduced by CMake 3.20
=================================
.. toctree::
:maxdepth: 1
CMP0120: The WriteCompilerDetectionHeader module is removed. </policy/CMP0120>
CMP0119: LANGUAGE source file property explicitly compiles as language. </policy/CMP0119>
CMP0118: The GENERATED source file property is now visible in all directories. </policy/CMP0118>
CMP0117: MSVC RTTI flag /GR is not added to CMAKE_CXX_FLAGS by default. </policy/CMP0117>
CMP0116: Ninja generators transform DEPFILEs from add_custom_command(). </policy/CMP0116>
CMP0115: Source file extensions must be explicit. </policy/CMP0115>
Policies Introduced by CMake 3.19
=================================
.. toctree::
:maxdepth: 1
CMP0114: ExternalProject step targets fully adopt their steps. </policy/CMP0114>
CMP0113: Makefile generators do not repeat custom commands from target dependencies. </policy/CMP0113>
CMP0112: Target file component generator expressions do not add target dependencies. </policy/CMP0112>
CMP0111: An imported target missing its location property fails during generation. </policy/CMP0111>
CMP0110: add_test() supports arbitrary characters in test names. </policy/CMP0110>
CMP0109: find_program() requires permission to execute but not to read. </policy/CMP0109>
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>

1267
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-presets.7.rst Normal file
View File

File diff suppressed because it is too large Load Diff

647
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-properties.7.rst Normal file
View File

@ -0,0 +1,647 @@
.. 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/AUTOUIC_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/IMPORTED_TARGETS
/prop_dir/INCLUDE_DIRECTORIES
/prop_dir/INCLUDE_REGULAR_EXPRESSION
/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/SYSTEM
/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
/prop_tgt/ARCHIVE_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/ARCHIVE_OUTPUT_NAME
/prop_tgt/ARCHIVE_OUTPUT_NAME_CONFIG
/prop_tgt/AUTOGEN_BUILD_DIR
/prop_tgt/AUTOGEN_ORIGIN_DEPENDS
/prop_tgt/AUTOGEN_PARALLEL
/prop_tgt/AUTOGEN_TARGET_DEPENDS
/prop_tgt/AUTOGEN_USE_SYSTEM_INCLUDE
/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
/prop_tgt/BUNDLE_EXTENSION
/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/COMPILE_WARNING_AS_ERROR
/prop_tgt/CONFIG_OUTPUT_NAME
/prop_tgt/CONFIG_POSTFIX
/prop_tgt/CROSSCOMPILING_EMULATOR
/prop_tgt/CUDA_ARCHITECTURES
/prop_tgt/CUDA_CUBIN_COMPILATION
/prop_tgt/CUDA_EXTENSIONS
/prop_tgt/CUDA_FATBIN_COMPILATION
/prop_tgt/CUDA_OPTIX_COMPILATION
/prop_tgt/CUDA_PTX_COMPILATION
/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS
/prop_tgt/CUDA_RUNTIME_LIBRARY
/prop_tgt/CUDA_SEPARABLE_COMPILATION
/prop_tgt/CUDA_STANDARD
/prop_tgt/CUDA_STANDARD_REQUIRED
/prop_tgt/CXX_EXTENSIONS
/prop_tgt/CXX_MODULE_DIRS
/prop_tgt/CXX_MODULE_DIRS_NAME
/prop_tgt/CXX_MODULE_SET
/prop_tgt/CXX_MODULE_SET_NAME
/prop_tgt/CXX_MODULE_SETS
/prop_tgt/CXX_SCAN_FOR_MODULES
/prop_tgt/CXX_STANDARD
/prop_tgt/CXX_STANDARD_REQUIRED
/prop_tgt/DEBUG_POSTFIX
/prop_tgt/DEFINE_SYMBOL
/prop_tgt/DEPLOYMENT_ADDITIONAL_FILES
/prop_tgt/DEPLOYMENT_REMOTE_DIRECTORY
/prop_tgt/DEPRECATION
/prop_tgt/DISABLE_PRECOMPILE_HEADERS
/prop_tgt/DLL_NAME_WITH_SOVERSION
/prop_tgt/DOTNET_SDK
/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
/prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD_CONFIG
/prop_tgt/EXPORT_COMPILE_COMMANDS
/prop_tgt/EXPORT_NAME
/prop_tgt/EXPORT_NO_SYSTEM
/prop_tgt/EXPORT_PROPERTIES
/prop_tgt/FOLDER
/prop_tgt/Fortran_BUILDING_INSTRINSIC_MODULES
/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/HEADER_DIRS
/prop_tgt/HEADER_DIRS_NAME
/prop_tgt/HEADER_SET
/prop_tgt/HEADER_SET_NAME
/prop_tgt/HEADER_SETS
/prop_tgt/HIP_ARCHITECTURES
/prop_tgt/HIP_EXTENSIONS
/prop_tgt/HIP_STANDARD
/prop_tgt/HIP_STANDARD_REQUIRED
/prop_tgt/IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
/prop_tgt/IMPORTED
/prop_tgt/IMPORTED_COMMON_LANGUAGE_RUNTIME
/prop_tgt/IMPORTED_CONFIGURATIONS
/prop_tgt/IMPORTED_GLOBAL
/prop_tgt/IMPORTED_IMPLIB
/prop_tgt/IMPORTED_IMPLIB_CONFIG
/prop_tgt/IMPORTED_LIBNAME
/prop_tgt/IMPORTED_LIBNAME_CONFIG
/prop_tgt/IMPORTED_LINK_DEPENDENT_LIBRARIES
/prop_tgt/IMPORTED_LINK_DEPENDENT_LIBRARIES_CONFIG
/prop_tgt/IMPORTED_LINK_INTERFACE_LANGUAGES
/prop_tgt/IMPORTED_LINK_INTERFACE_LANGUAGES_CONFIG
/prop_tgt/IMPORTED_LINK_INTERFACE_LIBRARIES
/prop_tgt/IMPORTED_LINK_INTERFACE_LIBRARIES_CONFIG
/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY
/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY_CONFIG
/prop_tgt/IMPORTED_LOCATION
/prop_tgt/IMPORTED_LOCATION_CONFIG
/prop_tgt/IMPORTED_NO_SONAME
/prop_tgt/IMPORTED_NO_SONAME_CONFIG
/prop_tgt/IMPORTED_NO_SYSTEM
/prop_tgt/IMPORTED_OBJECTS
/prop_tgt/IMPORTED_OBJECTS_CONFIG
/prop_tgt/IMPORTED_SONAME
/prop_tgt/IMPORTED_SONAME_CONFIG
/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_AUTOMOC_MACRO_NAMES
/prop_tgt/INTERFACE_AUTOUIC_OPTIONS
/prop_tgt/INTERFACE_COMPILE_DEFINITIONS
/prop_tgt/INTERFACE_COMPILE_FEATURES
/prop_tgt/INTERFACE_COMPILE_OPTIONS
/prop_tgt/INTERFACE_CXX_MODULE_SETS
/prop_tgt/INTERFACE_HEADER_SETS
/prop_tgt/INTERFACE_HEADER_SETS_TO_VERIFY
/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES
/prop_tgt/INTERFACE_LINK_DEPENDS
/prop_tgt/INTERFACE_LINK_DIRECTORIES
/prop_tgt/INTERFACE_LINK_LIBRARIES
/prop_tgt/INTERFACE_LINK_LIBRARIES_DIRECT
/prop_tgt/INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
/prop_tgt/INTERFACE_LINK_OPTIONS
/prop_tgt/INTERFACE_POSITION_INDEPENDENT_CODE
/prop_tgt/INTERFACE_PRECOMPILE_HEADERS
/prop_tgt/INTERFACE_SOURCES
/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
/prop_tgt/INTERPROCEDURAL_OPTIMIZATION
/prop_tgt/INTERPROCEDURAL_OPTIMIZATION_CONFIG
/prop_tgt/IOS_INSTALL_COMBINED
/prop_tgt/ISPC_HEADER_DIRECTORY
/prop_tgt/ISPC_HEADER_SUFFIX
/prop_tgt/ISPC_INSTRUCTION_SETS
/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_CLANG_TIDY_EXPORT_FIXES_DIR
/prop_tgt/LANG_COMPILER_LAUNCHER
/prop_tgt/LANG_CPPCHECK
/prop_tgt/LANG_CPPLINT
/prop_tgt/LANG_EXTENSIONS
/prop_tgt/LANG_INCLUDE_WHAT_YOU_USE
/prop_tgt/LANG_LINKER_LAUNCHER
/prop_tgt/LANG_STANDARD
/prop_tgt/LANG_STANDARD_REQUIRED
/prop_tgt/LANG_VISIBILITY_PRESET
/prop_tgt/LIBRARY_OUTPUT_DIRECTORY
/prop_tgt/LIBRARY_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/LIBRARY_OUTPUT_NAME
/prop_tgt/LIBRARY_OUTPUT_NAME_CONFIG
/prop_tgt/LINK_DEPENDS
/prop_tgt/LINK_DEPENDS_NO_SHARED
/prop_tgt/LINK_DIRECTORIES
/prop_tgt/LINK_FLAGS
/prop_tgt/LINK_FLAGS_CONFIG
/prop_tgt/LINK_INTERFACE_LIBRARIES
/prop_tgt/LINK_INTERFACE_LIBRARIES_CONFIG
/prop_tgt/LINK_INTERFACE_MULTIPLICITY
/prop_tgt/LINK_INTERFACE_MULTIPLICITY_CONFIG
/prop_tgt/LINK_LIBRARIES
/prop_tgt/LINK_LIBRARIES_ONLY_TARGETS
/prop_tgt/LINK_LIBRARY_OVERRIDE
/prop_tgt/LINK_LIBRARY_OVERRIDE_LIBRARY
/prop_tgt/LINK_OPTIONS
/prop_tgt/LINK_SEARCH_END_STATIC
/prop_tgt/LINK_SEARCH_START_STATIC
/prop_tgt/LINK_WHAT_YOU_USE
/prop_tgt/LINKER_LANGUAGE
/prop_tgt/LOCATION
/prop_tgt/LOCATION_CONFIG
/prop_tgt/MACHO_COMPATIBILITY_VERSION
/prop_tgt/MACHO_CURRENT_VERSION
/prop_tgt/MACOSX_BUNDLE
/prop_tgt/MACOSX_BUNDLE_INFO_PLIST
/prop_tgt/MACOSX_FRAMEWORK_INFO_PLIST
/prop_tgt/MACOSX_RPATH
/prop_tgt/MANUALLY_ADDED_DEPENDENCIES
/prop_tgt/MAP_IMPORTED_CONFIG_CONFIG
/prop_tgt/MSVC_DEBUG_INFORMATION_FORMAT
/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/OPTIMIZE_DEPENDENCIES
/prop_tgt/OSX_ARCHITECTURES
/prop_tgt/OSX_ARCHITECTURES_CONFIG
/prop_tgt/OUTPUT_NAME
/prop_tgt/OUTPUT_NAME_CONFIG
/prop_tgt/PCH_INSTANTIATE_TEMPLATES
/prop_tgt/PCH_WARN_INVALID
/prop_tgt/PDB_NAME
/prop_tgt/PDB_NAME_CONFIG
/prop_tgt/PDB_OUTPUT_DIRECTORY
/prop_tgt/PDB_OUTPUT_DIRECTORY_CONFIG
/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
/prop_tgt/RUNTIME_OUTPUT_DIRECTORY_CONFIG
/prop_tgt/RUNTIME_OUTPUT_NAME
/prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG
/prop_tgt/SKIP_BUILD_RPATH
/prop_tgt/SOURCE_DIR
/prop_tgt/SOURCES
/prop_tgt/SOVERSION
/prop_tgt/STATIC_LIBRARY_FLAGS
/prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG
/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/SYSTEM
/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/UNITY_BUILD_UNIQUE_ID
/prop_tgt/VERIFY_INTERFACE_HEADER_SETS
/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_DOCUMENTATION_FILE
/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_STARTUP_OBJECT
/prop_tgt/VS_DOTNET_TARGET_FRAMEWORK_VERSION
/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_COMPILE_BATCHING
/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/WATCOM_RUNTIME_LIBRARY
/prop_tgt/WIN32_EXECUTABLE
/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS
/prop_tgt/XCODE_ATTRIBUTE_an-attribute
/prop_tgt/XCODE_EMBED_FRAMEWORKS_CODE_SIGN_ON_COPY
/prop_tgt/XCODE_EMBED_FRAMEWORKS_REMOVE_HEADERS_ON_COPY
/prop_tgt/XCODE_EMBED_type
/prop_tgt/XCODE_EMBED_type_CODE_SIGN_ON_COPY
/prop_tgt/XCODE_EMBED_type_PATH
/prop_tgt/XCODE_EMBED_type_REMOVE_HEADERS_ON_COPY
/prop_tgt/XCODE_EXPLICIT_FILE_TYPE
/prop_tgt/XCODE_GENERATE_SCHEME
/prop_tgt/XCODE_LINK_BUILD_PHASE_MODE
/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_ENABLE_GPU_API_VALIDATION
/prop_tgt/XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE
/prop_tgt/XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION
/prop_tgt/XCODE_SCHEME_ENVIRONMENT
/prop_tgt/XCODE_SCHEME_EXECUTABLE
/prop_tgt/XCODE_SCHEME_GUARD_MALLOC
/prop_tgt/XCODE_SCHEME_LAUNCH_CONFIGURATION
/prop_tgt/XCODE_SCHEME_LAUNCH_MODE
/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/XCODE_XCCONFIG
/prop_tgt/XCTEST
.. _`Test Properties`:
Properties on Tests
===================
.. toctree::
:maxdepth: 1
/prop_test/ATTACHED_FILES
/prop_test/ATTACHED_FILES_ON_FAIL
/prop_test/COST
/prop_test/DEPENDS
/prop_test/DISABLED
/prop_test/ENVIRONMENT
/prop_test/ENVIRONMENT_MODIFICATION
/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/TIMEOUT_SIGNAL_GRACE_PERIOD
/prop_test/TIMEOUT_SIGNAL_NAME
/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/CXX_SCAN_FOR_MODULES
/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_LINTING
/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/INTERPROCEDURAL_OPTIMIZATION
/prop_dir/INTERPROCEDURAL_OPTIMIZATION_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

262
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-qt.7.rst Normal file
View File

@ -0,0 +1,262 @@
.. 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 <https://contribute.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.
.. _`Qt AUTOMOC`:
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
file which is compiled into the target, named either
``<AUTOGEN_BUILD_DIR>/mocs_compilation.cpp`` or
``<AUTOGEN_BUILD_DIR>/mocs_compilation_$<CONFIG>.cpp``.
* 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)

7
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-server.7.rst Normal file
View File

@ -0,0 +1,7 @@
.. cmake-manual-description: CMake Server
cmake-server(7)
***************
The :manual:`cmake(1)` server mode has been removed since CMake 3.20.
Clients should use the :manual:`cmake-file-api(7)` instead.

703
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-toolchains.7.rst Normal file
View File

@ -0,0 +1,703 @@
.. 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.
.. versionadded:: 3.19
One may use :manual:`cmake-presets(7)` to specify toolchain files.
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`
The full path to the compiler used for ``<LANG>``
:variable:`CMAKE_<LANG>_COMPILER_ID`
The compiler identifier used by CMake
:variable:`CMAKE_<LANG>_COMPILER_VERSION`
The version of the compiler.
:variable:`CMAKE_<LANG>_FLAGS`
The variables and the configuration-specific equivalents contain flags that
will be added to the compile command when compiling a file of a particular
language.
CMake needs a way to determine which compiler to use to invoke the linker.
This is determined by the :prop_sf:`LANGUAGE` property of source files of the
:manual:`target <cmake-buildsystem(7)>`, 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:`CheckSourceCompiles`, :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
:option:`--toolchain path/to/file <cmake --toolchain>` or
:option:`-DCMAKE_TOOLCHAIN_FILE=path/to/file <cmake -D>`, 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)
Where:
:variable:`CMAKE_SYSTEM_NAME`
is the CMake-identifier of the target platform to build for.
:variable:`CMAKE_SYSTEM_PROCESSOR`
is the CMake-identifier of the target architecture.
:variable:`CMAKE_SYSROOT`
is optional, and may be specified if a sysroot is available.
: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.
:variable:`CMAKE_<LANG>_COMPILER`
variable 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 :ref:`Visual Studio Generators` 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`` or higher.
CMake selects a Windows SDK as described by documentation of the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.
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 ADSP SHARC/Blackfin`:
Cross Compiling for ADSP SHARC/Blackfin
---------------------------------------
Cross-compiling for ADSP SHARC or Blackfin can be configured
by setting the :variable:`CMAKE_SYSTEM_NAME` variable to ``ADSP``
and the :variable:`CMAKE_SYSTEM_PROCESSOR` variable
to the "part number", excluding the ``ADSP-`` prefix,
for example, ``21594``, ``SC589``, etc.
This value is case insensitive.
CMake will automatically search for CCES or VDSP++ installs
in their default install locations
and select the most recent version found.
CCES will be selected over VDSP++ if both are installed.
Custom install paths can be set via the :variable:`CMAKE_ADSP_ROOT` variable
or the :envvar:`ADSP_ROOT` environment variable.
The compiler (``cc21k`` vs. ``ccblkfn``) is selected automatically
based on the :variable:`CMAKE_SYSTEM_PROCESSOR` value provided.
.. _`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>` or the :ref:`Visual Studio tools for Android
<Cross Compiling for Android with the NDK>` to be installed. See those sections
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.
.. versionadded:: 3.20
If an Android NDK is selected, its version number is reported
in the :variable:`CMAKE_ANDROID_NDK_VERSION` variable.
.. _`Cross Compiling for Android with the NDK`:
Cross Compiling for Android with the NDK
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A toolchain file may configure :ref:`Makefile Generators`,
:ref:`Ninja Generators`, or :ref:`Visual Studio Generators` 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 the first supported ABI in the list of
``armeabi``, ``armeabi-v7a`` and ``arm64-v8a``.
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.
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

786
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake-variables.7.rst Normal file
View File

@ -0,0 +1,786 @@
.. 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_CACHE_MAJOR_VERSION
/variable/CMAKE_CACHE_MINOR_VERSION
/variable/CMAKE_CACHE_PATCH_VERSION
/variable/CMAKE_CACHEFILE_DIR
/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_SDK
/variable/CMAKE_DOTNET_TARGET_FRAMEWORK
/variable/CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION
/variable/CMAKE_EDIT_COMMAND
/variable/CMAKE_EXECUTABLE_SUFFIX
/variable/CMAKE_EXECUTABLE_SUFFIX_LANG
/variable/CMAKE_EXTRA_GENERATOR
/variable/CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES
/variable/CMAKE_FIND_DEBUG_MODE
/variable/CMAKE_FIND_PACKAGE_NAME
/variable/CMAKE_FIND_PACKAGE_REDIRECTS_DIR
/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_FRONTEND_VARIANT
/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_NUGET_PACKAGE_RESTORE
/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_TARGET_FRAMEWORK_IDENTIFIER
/variable/CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION
/variable/CMAKE_VS_TARGET_FRAMEWORK_VERSION
/variable/CMAKE_VS_VERSION_BUILD_NUMBER
/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM
/variable/CMAKE_XCODE_BUILD_SYSTEM
/variable/CMAKE_XCODE_PLATFORM_TOOLSET
/variable/PROJECT-NAME_BINARY_DIR
/variable/PROJECT-NAME_DESCRIPTION
/variable/PROJECT-NAME_HOMEPAGE_URL
/variable/PROJECT-NAME_IS_TOP_LEVEL
/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_IS_TOP_LEVEL
/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_ADD_CUSTOM_COMMAND_DEPENDS_EXPLICIT_ONLY
/variable/CMAKE_APPBUNDLE_PATH
/variable/CMAKE_AUTOMOC_RELAXED_MODE
/variable/CMAKE_BACKWARDS_COMPATIBILITY
/variable/CMAKE_BUILD_TYPE
/variable/CMAKE_CLANG_VFS_OVERLAY
/variable/CMAKE_CODEBLOCKS_COMPILER_ID
/variable/CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES
/variable/CMAKE_CODELITE_USE_TARGETS
/variable/CMAKE_COLOR_DIAGNOSTICS
/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_TARGETS_GLOBAL
/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_INSTALL_PREFIX
/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_IGNORE_PREFIX_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_KATE_FILES_MODE
/variable/CMAKE_KATE_MAKE_ARGUMENTS
/variable/CMAKE_LIBRARY_PATH
/variable/CMAKE_LINK_DIRECTORIES_BEFORE
/variable/CMAKE_LINK_LIBRARIES_ONLY_TARGETS
/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_MFC_FLAG
/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_PROJECT_TOP_LEVEL_INCLUDES
/variable/CMAKE_REQUIRE_FIND_PACKAGE_PackageName
/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_IGNORE_PREFIX_PATH
/variable/CMAKE_SYSTEM_INCLUDE_PATH
/variable/CMAKE_SYSTEM_LIBRARY_PATH
/variable/CMAKE_SYSTEM_PREFIX_PATH
/variable/CMAKE_SYSTEM_PROGRAM_PATH
/variable/CMAKE_TLS_CAINFO
/variable/CMAKE_TLS_VERIFY
/variable/CMAKE_USER_MAKE_RULES_OVERRIDE
/variable/CMAKE_WARN_DEPRECATED
/variable/CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
/variable/CMAKE_XCODE_GENERATE_SCHEME
/variable/CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY
/variable/CMAKE_XCODE_LINK_BUILD_PHASE_MODE
/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_ENABLE_GPU_API_VALIDATION
/variable/CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE
/variable/CMAKE_XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION
/variable/CMAKE_XCODE_SCHEME_ENVIRONMENT
/variable/CMAKE_XCODE_SCHEME_GUARD_MALLOC
/variable/CMAKE_XCODE_SCHEME_LAUNCH_CONFIGURATION
/variable/CMAKE_XCODE_SCHEME_LAUNCH_MODE
/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/CMAKE_XCODE_XCCONFIG
/variable/PackageName_ROOT
Variables that Describe the System
==================================
.. toctree::
:maxdepth: 1
/variable/ANDROID
/variable/APPLE
/variable/BORLAND
/variable/BSD
/variable/CMAKE_ANDROID_NDK_VERSION
/variable/CMAKE_CL_64
/variable/CMAKE_COMPILER_2005
/variable/CMAKE_HOST_APPLE
/variable/CMAKE_HOST_BSD
/variable/CMAKE_HOST_LINUX
/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/GHSMULTI
/variable/IOS
/variable/LINUX
/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_ADSP_ROOT
/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_EXCEPTIONS
/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_RTTI
/variable/CMAKE_ANDROID_SECURE_PROPS_PATH
/variable/CMAKE_ANDROID_SKIP_ANT_STEP
/variable/CMAKE_ANDROID_STANDALONE_TOOLCHAIN
/variable/CMAKE_ANDROID_STL_TYPE
/variable/CMAKE_APPLE_SILICON_PROCESSOR
/variable/CMAKE_ARCHIVE_OUTPUT_DIRECTORY
/variable/CMAKE_ARCHIVE_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_AUTOGEN_ORIGIN_DEPENDS
/variable/CMAKE_AUTOGEN_PARALLEL
/variable/CMAKE_AUTOGEN_USE_SYSTEM_INCLUDE
/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_AUTOMOC_EXECUTABLE
/variable/CMAKE_AUTORCC
/variable/CMAKE_AUTORCC_OPTIONS
/variable/CMAKE_AUTORCC_EXECUTABLE
/variable/CMAKE_AUTOUIC
/variable/CMAKE_AUTOUIC_OPTIONS
/variable/CMAKE_AUTOUIC_SEARCH_PATHS
/variable/CMAKE_AUTOUIC_EXECUTABLE
/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_COMPILE_WARNING_AS_ERROR
/variable/CMAKE_CONFIG_POSTFIX
/variable/CMAKE_CROSS_CONFIGS
/variable/CMAKE_CTEST_ARGUMENTS
/variable/CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS
/variable/CMAKE_CUDA_RUNTIME_LIBRARY
/variable/CMAKE_CUDA_SEPARABLE_COMPILATION
/variable/CMAKE_CXX_SCAN_FOR_MODULES
/variable/CMAKE_DEBUG_POSTFIX
/variable/CMAKE_DEFAULT_BUILD_TYPE
/variable/CMAKE_DEFAULT_CONFIGS
/variable/CMAKE_DEPENDS_USE_COMPILER
/variable/CMAKE_DISABLE_PRECOMPILE_HEADERS
/variable/CMAKE_DLL_NAME_WITH_SOVERSION
/variable/CMAKE_ENABLE_EXPORTS
/variable/CMAKE_EXECUTABLE_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_Fortran_FORMAT
/variable/CMAKE_Fortran_MODULE_DIRECTORY
/variable/CMAKE_Fortran_PREPROCESS
/variable/CMAKE_FRAMEWORK
/variable/CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_CONFIG
/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_CLANG_TIDY_EXPORT_FIXES_DIR
/variable/CMAKE_LANG_COMPILER_LAUNCHER
/variable/CMAKE_LANG_CPPCHECK
/variable/CMAKE_LANG_CPPLINT
/variable/CMAKE_LANG_INCLUDE_WHAT_YOU_USE
/variable/CMAKE_LANG_LINK_GROUP_USING_FEATURE
/variable/CMAKE_LANG_LINK_GROUP_USING_FEATURE_SUPPORTED
/variable/CMAKE_LANG_LINK_LIBRARY_FILE_FLAG
/variable/CMAKE_LANG_LINK_LIBRARY_FLAG
/variable/CMAKE_LANG_LINK_LIBRARY_USING_FEATURE
/variable/CMAKE_LANG_LINK_LIBRARY_USING_FEATURE_SUPPORTED
/variable/CMAKE_LANG_LINK_WHAT_YOU_USE_FLAG
/variable/CMAKE_LANG_LINKER_LAUNCHER
/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_DEPENDS_USE_LINKER
/variable/CMAKE_LINK_GROUP_USING_FEATURE
/variable/CMAKE_LINK_GROUP_USING_FEATURE_SUPPORTED
/variable/CMAKE_LINK_INTERFACE_LIBRARIES
/variable/CMAKE_LINK_LIBRARY_FILE_FLAG
/variable/CMAKE_LINK_LIBRARY_FLAG
/variable/CMAKE_LINK_LIBRARY_USING_FEATURE
/variable/CMAKE_LINK_LIBRARY_USING_FEATURE_SUPPORTED
/variable/CMAKE_LINK_WHAT_YOU_USE
/variable/CMAKE_LINK_WHAT_YOU_USE_CHECK
/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_MSVC_DEBUG_INFORMATION_FORMAT
/variable/CMAKE_MSVC_RUNTIME_LIBRARY
/variable/CMAKE_MSVCIDE_RUN_PATH
/variable/CMAKE_NINJA_OUTPUT_PATH_PREFIX
/variable/CMAKE_NO_BUILTIN_CHRPATH
/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED
/variable/CMAKE_OPTIMIZE_DEPENDENCIES
/variable/CMAKE_OSX_ARCHITECTURES
/variable/CMAKE_OSX_DEPLOYMENT_TARGET
/variable/CMAKE_OSX_SYSROOT
/variable/CMAKE_PCH_INSTANTIATE_TEMPLATES
/variable/CMAKE_PCH_WARN_INVALID
/variable/CMAKE_PDB_OUTPUT_DIRECTORY
/variable/CMAKE_PDB_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_PLATFORM_NO_VERSIONED_SONAME
/variable/CMAKE_POSITION_INDEPENDENT_CODE
/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY
/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_SHARED_LIBRARY_ENABLE_EXPORTS
/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_TASKING_TOOLSET
/variable/CMAKE_TRY_COMPILE_CONFIGURATION
/variable/CMAKE_TRY_COMPILE_NO_PLATFORM_VARIABLES
/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
/variable/CMAKE_TRY_COMPILE_TARGET_TYPE
/variable/CMAKE_UNITY_BUILD
/variable/CMAKE_UNITY_BUILD_BATCH_SIZE
/variable/CMAKE_UNITY_BUILD_UNIQUE_ID
/variable/CMAKE_USE_RELATIVE_PATHS
/variable/CMAKE_VERIFY_INTERFACE_HEADER_SETS
/variable/CMAKE_VISIBILITY_INLINES_HIDDEN
/variable/CMAKE_VS_DEBUGGER_COMMAND
/variable/CMAKE_VS_DEBUGGER_COMMAND_ARGUMENTS
/variable/CMAKE_VS_DEBUGGER_ENVIRONMENT
/variable/CMAKE_VS_DEBUGGER_WORKING_DIRECTORY
/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_NO_COMPILE_BATCHING
/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_WATCOM_RUNTIME_LIBRARY
/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_C_COMPILE_FEATURES
/variable/CMAKE_C_EXTENSIONS
/variable/CMAKE_C_STANDARD
/variable/CMAKE_C_STANDARD_REQUIRED
/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_EXTENSIONS
/variable/CMAKE_CUDA_HOST_COMPILER
/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_Fortran_MODDIR_DEFAULT
/variable/CMAKE_Fortran_MODDIR_FLAG
/variable/CMAKE_Fortran_MODOUT_FLAG
/variable/CMAKE_HIP_ARCHITECTURES
/variable/CMAKE_HIP_EXTENSIONS
/variable/CMAKE_HIP_STANDARD
/variable/CMAKE_HIP_STANDARD_REQUIRED
/variable/CMAKE_ISPC_HEADER_DIRECTORY
/variable/CMAKE_ISPC_HEADER_SUFFIX
/variable/CMAKE_ISPC_INSTRUCTION_SETS
/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_BYTE_ORDER
/variable/CMAKE_LANG_COMPILE_OBJECT
/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_CREATE_SHARED_LIBRARY
/variable/CMAKE_LANG_CREATE_SHARED_MODULE
/variable/CMAKE_LANG_CREATE_STATIC_LIBRARY
/variable/CMAKE_LANG_EXTENSIONS
/variable/CMAKE_LANG_EXTENSIONS_DEFAULT
/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_LINK_EXECUTABLE
/variable/CMAKE_LANG_LINKER_WRAPPER_FLAG
/variable/CMAKE_LANG_LINKER_WRAPPER_FLAG_SEP
/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
/variable/CMAKE_LANG_STANDARD_DEFAULT
/variable/CMAKE_LANG_STANDARD_INCLUDE_DIRECTORIES
/variable/CMAKE_LANG_STANDARD_LIBRARIES
/variable/CMAKE_LANG_STANDARD_REQUIRED
/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_TEST_OUTPUT_TRUNCATION
/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_SCRIPT_DIRECTORY
/variable/CTEST_SITE
/variable/CTEST_SOURCE_DIRECTORY
/variable/CTEST_SUBMIT_INACTIVITY_TIMEOUT
/variable/CTEST_SUBMIT_URL
/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_CUSTOM_INSTALL_VARIABLES
/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_LINKER_PREFERENCE
/variable/CMAKE_LANG_LINKER_PREFERENCE_PROPAGATES
/variable/CMAKE_LANG_PLATFORM_ID
/variable/CMAKE_NOT_USING_CONFIG_FLAGS
/variable/CMAKE_VS_INTEL_Fortran_PROJECT_VERSION

1399
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cmake.1.rst Normal file
View File

File diff suppressed because it is too large Load Diff

30
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cpack-generators.7.rst Normal file
View File

@ -0,0 +1,30 @@
.. 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/innosetup
/cpack_gen/ifw
/cpack_gen/nsis
/cpack_gen/nuget
/cpack_gen/packagemaker
/cpack_gen/productbuild
/cpack_gen/rpm
/cpack_gen/wix

135
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/cpack.1.rst Normal file
View File

@ -0,0 +1,135 @@
.. cmake-manual-description: CPack Command-Line Reference
cpack(1)
********
Synopsis
========
.. parsed-literal::
cpack [<options>]
Description
===========
The :program:`cpack` executable is the CMake packaging program. It generates
installers and source packages in a variety of formats.
For each installer or package format, :program:`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 :option:`-G <cpack -G>`.
The :program:`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 :option:`--config <cpack --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
=======
.. program:: cpack
.. option:: -G <generators>
``<generators>`` is a :ref:`semicolon-separated list <CMake Language Lists>`
of generator names. :program:`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.
.. option:: -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
:program:`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 :program:`cpack`.
.. option:: -D <var>=<value>
Set a CPack variable. This will override any value set for ``<var>`` in the
input file read by :program:`cpack`.
.. option:: --config <configFile>
Specify the configuration file read by :program:`cpack` to provide the packaging
details. By default, ``CPackConfig.cmake`` in the current directory will
be used.
.. option:: -V, --verbose
Run :program:`cpack` with verbose output. This can be used to show more details
from the package generation tools and is suitable for project developers.
.. option:: --debug
Run :program:`cpack` with debug output. This option is intended mainly for the
developers of :program:`cpack` itself and is not normally needed by project
developers.
.. option:: --trace
Put the underlying cmake scripts in trace mode.
.. option:: --trace-expand
Put the underlying cmake scripts in expanded trace mode.
.. option:: -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.
.. option:: -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`.
.. option:: -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.
.. option:: --vendor <vendorName>
Override/define :variable:`CPACK_PACKAGE_VENDOR`.
.. option:: --preset <presetName>
Use a preset from :manual:`cmake-presets(7)`.
.. option:: --list-presets
List presets from :manual:`cmake-presets(7)`.
.. include:: OPTIONS_HELP.txt
See Also
========
.. include:: LINKS.txt

1826
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/ctest.1.rst Normal file
View File

File diff suppressed because it is too large Load Diff

106
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/presets/example.json Normal file
View File

@ -0,0 +1,106 @@
{
"version": 6,
"cmakeMinimumRequired": {
"major": 3,
"minor": 23,
"patch": 0
},
"include": [
"otherThings.json",
"moreThings.json"
],
"configurePresets": [
{
"name": "default",
"displayName": "Default Config",
"description": "Default build using Ninja generator",
"generator": "Ninja",
"binaryDir": "${sourceDir}/build/default",
"cacheVariables": {
"FIRST_CACHE_VARIABLE": {
"type": "BOOL",
"value": "OFF"
},
"SECOND_CACHE_VARIABLE": "ON"
},
"environment": {
"MY_ENVIRONMENT_VARIABLE": "Test",
"PATH": "$env{HOME}/ninja/bin:$penv{PATH}"
},
"vendor": {
"example.com/ExampleIDE/1.0": {
"autoFormat": true
}
}
},
{
"name": "ninja-multi",
"inherits": "default",
"displayName": "Ninja Multi-Config",
"description": "Default build using Ninja Multi-Config generator",
"generator": "Ninja Multi-Config"
},
{
"name": "windows-only",
"inherits": "default",
"displayName": "Windows-only configuration",
"description": "This build is only available on Windows",
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Windows"
}
}
],
"buildPresets": [
{
"name": "default",
"configurePreset": "default"
}
],
"testPresets": [
{
"name": "default",
"configurePreset": "default",
"output": {"outputOnFailure": true},
"execution": {"noTestsAction": "error", "stopOnFailure": true}
}
],
"packagePresets": [
{
"name": "default",
"configurePreset": "default",
"generators": [
"TGZ"
]
}
],
"workflowPresets": [
{
"name": "default",
"steps": [
{
"type": "configure",
"name": "default"
},
{
"type": "build",
"name": "default"
},
{
"type": "test",
"name": "default"
},
{
"type": "package",
"name": "default"
}
]
}
],
"vendor": {
"example.com/ExampleIDE/1.0": {
"autoFormat": false
}
}
}

1880
6.5.3/_tools/cmake/share/cmake-3.27/Help/manual/presets/schema.json Normal file
View File

File diff suppressed because it is too large Load Diff