code:
.\" Man page generated from reStructuredText.
.
.
.nr rst2man-indent-level 0
.
.de1 rstReportMargin
\\$1 \\n[an-margin]
level \\n[rst2man-indent-level]
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
-
\\n[rst2man-indent0]
\\n[rst2man-indent1]
\\n[rst2man-indent2]
..
.de1 INDENT
.\" .rstReportMargin pre:
. RS \\$1
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
. nr rst2man-indent-level +1
.\" .rstReportMargin post:
..
.de UNINDENT
. RE
.\" indent \\n[an-margin]
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
.nr rst2man-indent-level -1
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.TH "CMAKE-QT" "7" "Mar 04, 2024" "3.29.0" "CMake"
.SH NAME
cmake-qt \- CMake Qt Features Reference
.SH INTRODUCTION
.sp
CMake can find and use Qt 4, Qt 5 and Qt 6 libraries. The Qt 4 libraries are
found by the \fI\%FindQt4\fP find\-module shipped with CMake, whereas the
Qt 5 and Qt 6 libraries are found using \(dqConfig\-file Packages\(dq shipped with
Qt 5 and Qt 6. See \fI\%cmake\-packages(7)\fP for more information about CMake
packages, and see \fI\%the Qt cmake manual\fP for your Qt version.
.sp
Qt 4, Qt 5 and Qt 6 may be used together in the same
\fI\%CMake buildsystem\fP:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
cmake_minimum_required(VERSION 3.16 FATAL_ERROR)

project(Qt4_5_6)

set(CMAKE_AUTOMOC ON)

find_package(Qt6 COMPONENTS Widgets DBus REQUIRED)
add_executable(publisher publisher.cpp)
target_link_libraries(publisher Qt6::Widgets Qt6::DBus)

find_package(Qt5 COMPONENTS Gui DBus REQUIRED)
add_executable(subscriber1 subscriber1.cpp)
target_link_libraries(subscriber1 Qt5::Gui Qt5::DBus)

find_package(Qt4 REQUIRED)
add_executable(subscriber2 subscriber2.cpp)
target_link_libraries(subscriber2 Qt4::QtGui Qt4::QtDBus)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
A CMake target may not link to more than one Qt version.  A diagnostic is issued
if this is attempted or results from transitive target dependency evaluation.
.SH QT BUILD TOOLS
.sp
Qt relies on some bundled tools for code generation, such as \fBmoc\fP for
meta\-object code generation, \fBuic\fP for widget layout and population,
and \fBrcc\fP for virtual file system content generation.  These tools may be
automatically invoked by \fI\%cmake(1)\fP if the appropriate conditions
are met.  The automatic tool invocation may be used with Qt version 4 to 6.
.SS AUTOMOC
.sp
The \fI\%AUTOMOC\fP target property controls whether \fI\%cmake(1)\fP
inspects the C++ files in the target to determine if they require \fBmoc\fP to
be run, and to create rules to execute \fBmoc\fP at the appropriate time.
.sp
If a macro from \fI\%AUTOMOC_MACRO_NAMES\fP is found in a header file,
\fBmoc\fP will be run on the file.  The result will be put into a file named
according to \fBmoc_<basename>.cpp\fP\&.
If the macro is found in a C++ implementation
file, the moc output will be put into a file named according to
\fB<basename>.moc\fP, following the Qt conventions.  The \fB<basename>.moc\fP must
be included by the user in the C++ implementation file with a preprocessor
\fB#include\fP\&.
.sp
Included \fBmoc_*.cpp\fP and \fB*.moc\fP files will be generated in the
\fB<AUTOGEN_BUILD_DIR>/include\fP directory which is
automatically added to the target\(aqs \fI\%INCLUDE_DIRECTORIES\fP\&.
.INDENT 0.0
.IP \(bu 2
This differs from CMake 3.7 and below; see their documentation for details.
.IP \(bu 2
For \fI\%multi configuration generators\fP,
the include directory is \fB<AUTOGEN_BUILD_DIR>/include_<CONFIG>\fP\&.
.IP \(bu 2
See \fI\%AUTOGEN_BUILD_DIR\fP\&.
.UNINDENT
.sp
Not included \fBmoc_<basename>.cpp\fP 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
\fB<AUTOGEN_BUILD_DIR>/mocs_compilation.cpp\fP or
\fB<AUTOGEN_BUILD_DIR>/mocs_compilation_$<CONFIG>.cpp\fP\&.
.INDENT 0.0
.IP \(bu 2
See \fI\%AUTOGEN_BUILD_DIR\fP\&.
.UNINDENT
.sp
The \fBmoc\fP command line will consume the \fI\%COMPILE_DEFINITIONS\fP and
\fI\%INCLUDE_DIRECTORIES\fP target properties from the target it is being
invoked for, and for the appropriate build configuration.
.sp
The \fI\%AUTOMOC\fP target property may be pre\-set for all
following targets by setting the \fI\%CMAKE_AUTOMOC\fP variable.  The
\fI\%AUTOMOC_MOC_OPTIONS\fP target property may be populated to set
options to pass to \fBmoc\fP\&. The \fI\%CMAKE_AUTOMOC_MOC_OPTIONS\fP
variable may be populated to pre\-set the options for all following targets.
.sp
Additional macro names to search for can be added to
\fI\%AUTOMOC_MACRO_NAMES\fP\&.
.sp
Additional \fBmoc\fP dependency file names can be extracted from source code
by using \fI\%AUTOMOC_DEPEND_FILTERS\fP\&.
.sp
Source C++ files can be excluded from \fI\%AUTOMOC\fP processing by
enabling \fI\%SKIP_AUTOMOC\fP or the broader \fI\%SKIP_AUTOGEN\fP\&.
.SS AUTOUIC
.sp
The \fI\%AUTOUIC\fP target property controls whether \fI\%cmake(1)\fP
inspects the C++ files in the target to determine if they require \fBuic\fP to
be run, and to create rules to execute \fBuic\fP at the appropriate time.
.sp
If a preprocessor \fB#include\fP directive is found which matches
\fB<path>ui_<basename>.h\fP, and a \fB<basename>.ui\fP file exists,
then \fBuic\fP will be executed to generate the appropriate file.
The \fB<basename>.ui\fP file is searched for in the following places
.INDENT 0.0
.IP 1. 3
\fB<source_dir>/<basename>.ui\fP
.IP 2. 3
\fB<source_dir>/<path><basename>.ui\fP
.IP 3. 3
\fB<AUTOUIC_SEARCH_PATHS>/<basename>.ui\fP
.IP 4. 3
\fB<AUTOUIC_SEARCH_PATHS>/<path><basename>.ui\fP
.UNINDENT
.sp
where \fB<source_dir>\fP is the directory of the C++ file and
\fI\%AUTOUIC_SEARCH_PATHS\fP is a list of additional search paths.
.sp
The generated generated \fBui_*.h\fP files are placed in the
\fB<AUTOGEN_BUILD_DIR>/include\fP directory which is
automatically added to the target\(aqs \fI\%INCLUDE_DIRECTORIES\fP\&.
.INDENT 0.0
.IP \(bu 2
This differs from CMake 3.7 and below; see their documentation for details.
.IP \(bu 2
For \fI\%multi configuration generators\fP,
the include directory is \fB<AUTOGEN_BUILD_DIR>/include_<CONFIG>\fP\&.
.IP \(bu 2
See \fI\%AUTOGEN_BUILD_DIR\fP\&.
.UNINDENT
.sp
The \fI\%AUTOUIC\fP target property may be pre\-set for all following
targets by setting the \fI\%CMAKE_AUTOUIC\fP variable.  The
\fI\%AUTOUIC_OPTIONS\fP target property may be populated to set options
to pass to \fBuic\fP\&.  The \fI\%CMAKE_AUTOUIC_OPTIONS\fP variable may be
populated to pre\-set the options for all following targets.  The
\fI\%AUTOUIC_OPTIONS\fP source file property may be set on the
\fB<basename>.ui\fP file to set particular options for the file.  This
overrides options from the \fI\%AUTOUIC_OPTIONS\fP target property.
.sp
A target may populate the \fI\%INTERFACE_AUTOUIC_OPTIONS\fP target
property with options that should be used when invoking \fBuic\fP\&.  This must be
consistent with the \fI\%AUTOUIC_OPTIONS\fP target property content of the
depender target.  The \fI\%CMAKE_DEBUG_TARGET_PROPERTIES\fP variable may
be used to track the origin target of such
\fI\%INTERFACE_AUTOUIC_OPTIONS\fP\&.  This means that a library which
provides an alternative translation system for Qt may specify options which
should be used when running \fBuic\fP:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
add_library(KI18n klocalizedstring.cpp)
target_link_libraries(KI18n Qt6::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}
)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
A consuming project linking to the target exported from upstream automatically
uses appropriate options when \fBuic\fP is run by \fI\%AUTOUIC\fP, as a
result of linking with the \fI\%IMPORTED\fP target:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(CMAKE_AUTOUIC ON)
# Uses a libwidget.ui file:
add_library(LibWidget libwidget.cpp)
target_link_libraries(LibWidget
  KF5::KI18n
  Qt5::Widgets
)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Source files can be excluded from \fI\%AUTOUIC\fP processing by
enabling \fI\%SKIP_AUTOUIC\fP or the broader \fI\%SKIP_AUTOGEN\fP\&.
.SS AUTORCC
.sp
The \fI\%AUTORCC\fP target property controls whether \fI\%cmake(1)\fP
creates rules to execute \fBrcc\fP at the appropriate time on source files
which have the suffix \fB\&.qrc\fP\&.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
add_executable(myexe main.cpp resource_file.qrc)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
The \fI\%AUTORCC\fP target property may be pre\-set for all following targets
by setting the \fI\%CMAKE_AUTORCC\fP variable.  The
\fI\%AUTORCC_OPTIONS\fP target property may be populated to set options
to pass to \fBrcc\fP\&.  The \fI\%CMAKE_AUTORCC_OPTIONS\fP variable may be
populated to pre\-set the options for all following targets.  The
\fI\%AUTORCC_OPTIONS\fP source file property may be set on the
\fB<name>.qrc\fP file to set particular options for the file.  This
overrides options from the \fI\%AUTORCC_OPTIONS\fP target property.
.sp
Source files can be excluded from \fI\%AUTORCC\fP processing by
enabling \fI\%SKIP_AUTORCC\fP or the broader \fI\%SKIP_AUTOGEN\fP\&.
.SH THE <ORIGIN>_AUTOGEN TARGET
.sp
The \fBmoc\fP and \fBuic\fP tools are executed as part of a synthesized
\fI\%The <ORIGIN>_autogen target\fP \fI\%custom target\fP generated by
CMake.  By default that \fI\%The <ORIGIN>_autogen target\fP target inherits the dependencies
of the \fB<ORIGIN>\fP target (see \fI\%AUTOGEN_ORIGIN_DEPENDS\fP).
Target dependencies may be added to the \fI\%The <ORIGIN>_autogen target\fP target by adding
them to the \fI\%AUTOGEN_TARGET_DEPENDS\fP target property.
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
If Qt 5.15 or later is used and the generator is either \fI\%Ninja\fP or
\fI\%Makefile Generators\fP, see \fI\%The <ORIGIN>_autogen_timestamp_deps target\fP\&.
.UNINDENT
.UNINDENT
.SH THE <ORIGIN>_AUTOGEN_TIMESTAMP_DEPS TARGET
.sp
If Qt 5.15 or later is used and the generator is either \fI\%Ninja\fP or
\fI\%Makefile Generators\fP, the \fB<ORIGIN>_autogen_timestamp_deps\fP target is
also created in addition to the \fI\%The <ORIGIN>_autogen target\fP target.  This target
does not have any sources or commands to execute, but it has dependencies that
were previously inherited by the pre\-Qt 5.15 \fI\%The <ORIGIN>_autogen target\fP target.
These dependencies will serve as a list of order\-only dependencies for the
custom command, without forcing the custom command to re\-execute.
.SH VISUAL STUDIO GENERATORS
.sp
When using the \fI\%Visual Studio generators\fP, CMake
generates a \fBPRE_BUILD\fP \fI\%custom command\fP
instead of the \fI\%The <ORIGIN>_autogen target\fP
\fI\%custom target\fP (for \fI\%AUTOMOC\fP and
\fI\%AUTOUIC\fP).  This isn\(aqt always possible though and an
\fI\%The <ORIGIN>_autogen target\fP \fI\%custom target\fP is used,
when either
.INDENT 0.0
.IP \(bu 2
the \fB<ORIGIN>\fP target depends on \fI\%GENERATED\fP files which aren\(aqt
excluded from \fI\%AUTOMOC\fP and \fI\%AUTOUIC\fP by
\fI\%SKIP_AUTOMOC\fP, \fI\%SKIP_AUTOUIC\fP, \fI\%SKIP_AUTOGEN\fP
or \fI\%CMP0071\fP
.IP \(bu 2
\fI\%AUTOGEN_TARGET_DEPENDS\fP lists a source file
.IP \(bu 2
\fI\%CMAKE_GLOBAL_AUTOGEN_TARGET\fP is enabled
.UNINDENT
.SH QTMAIN.LIB ON WINDOWS
.sp
The Qt 4 and 5 \fI\%IMPORTED\fP 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 \fI\%WIN32_EXECUTABLE\fP enabled.
.sp
To disable this behavior, enable the \fBQt5_NO_LINK_QTMAIN\fP target property for
Qt 5 based targets or \fBQT4_NO_LINK_QTMAIN\fP target property for Qt 4 based
targets.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
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)
.ft P
.fi
.UNINDENT
.UNINDENT
.SH COPYRIGHT
2000-2024 Kitware, Inc. and Contributors
.\" Generated by docutils manpage writer.
.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
.\" Man page generated from reStructuredText.
.
.
.nr rst2man-indent-level 0
.
.de1 rstReportMargin
\\$1 \\n[an-margin]
level \\n[rst2man-indent-level]
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
-
\\n[rst2man-indent0]
\\n[rst2man-indent1]
\\n[rst2man-indent2]
..
.de1 INDENT
.\" .rstReportMargin pre:
. RS \\$1
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
. nr rst2man-indent-level +1
.\" .rstReportMargin post:
..
.de UNINDENT
. RE
.\" indent \\n[an-margin]
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
.nr rst2man-indent-level -1
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.TH "CMAKE-SERVER" "7" "Mar 04, 2024" "3.29.0" "CMake"
.SH NAME
cmake-server \- CMake Server
.sp
The \fI\%cmake(1)\fP server mode has been removed since CMake 3.20.
Clients should use the \fI\%cmake\-file\-api(7)\fP instead.
.SH COPYRIGHT
2000-2024 Kitware, Inc. and Contributors
.\" Generated by docutils manpage writer.
.


code:
.\" Man page generated from reStructuredText.
.
.
.nr rst2man-indent-level 0
.
.de1 rstReportMargin
\\$1 \\n[an-margin]
level \\n[rst2man-indent-level]
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
-
\\n[rst2man-indent0]
\\n[rst2man-indent1]
\\n[rst2man-indent2]
..
.de1 INDENT
.\" .rstReportMargin pre:
. RS \\$1
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
. nr rst2man-indent-level +1
.\" .rstReportMargin post:
..
.de UNINDENT
. RE
.\" indent \\n[an-margin]
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
.nr rst2man-indent-level -1
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.TH "CMAKE-TOOLCHAINS" "7" "Mar 04, 2024" "3.29.0" "CMake"
.SH NAME
cmake-toolchains \- CMake Toolchains Reference
.SH INTRODUCTION
.sp
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.
.sp
New in version 3.19: One may use \fI\%cmake\-presets(7)\fP to specify toolchain files.

.SH LANGUAGES
.sp
Languages are enabled by the \fI\%project()\fP command.  Language\-specific
built\-in variables, such as
\fI\%CMAKE_CXX_COMPILER\fP,
\fI\%CMAKE_CXX_COMPILER_ID\fP etc are set by
invoking the \fI\%project()\fP command.  If no project command
is in the top\-level CMakeLists file, one will be implicitly generated. By default
the enabled languages are \fBC\fP and \fBCXX\fP:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
project(C_Only C)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
A special value of \fBNONE\fP can also be used with the \fI\%project()\fP command
to enable no languages:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
project(MyProject NONE)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
The \fI\%enable_language()\fP command can be used to enable languages after the
\fI\%project()\fP command:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
enable_language(CXX)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
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.
.sp
The \fI\%ENABLED_LANGUAGES\fP global property contains the languages which
are currently enabled.
.SH VARIABLES AND PROPERTIES
.sp
Several variables relate to the language components of a toolchain which are
enabled:
.INDENT 0.0
.TP
.B \fI\%CMAKE_<LANG>_COMPILER\fP
The full path to the compiler used for \fB<LANG>\fP
.TP
.B \fI\%CMAKE_<LANG>_COMPILER_ID\fP
The compiler identifier used by CMake
.TP
.B \fI\%CMAKE_<LANG>_COMPILER_VERSION\fP
The version of the compiler.
.TP
.B \fI\%CMAKE_<LANG>_FLAGS\fP
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.
.UNINDENT
.sp
CMake needs a way to determine which compiler to use to invoke the linker.
This is determined by the \fI\%LANGUAGE\fP property of source files of the
\fI\%target\fP, and in the case of static libraries,
the \fBLANGUAGE\fP of the dependent libraries. The choice CMake makes may be overridden
with the \fI\%LINKER_LANGUAGE\fP target property.
.SH TOOLCHAIN FEATURES
.sp
CMake provides the \fI\%try_compile()\fP command and wrapper macros such as
\fI\%CheckSourceCompiles\fP, \fI\%CheckCXXSymbolExists\fP and
\fI\%CheckIncludeFile\fP 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.
.sp
Some toolchain features have built\-in handling in CMake, and do not require
compile\-tests. For example, \fI\%POSITION_INDEPENDENT_CODE\fP allows
specifying that a target should be built as position\-independent code, if
the compiler supports that feature. The \fI\%<LANG>_VISIBILITY_PRESET\fP
and \fI\%VISIBILITY_INLINES_HIDDEN\fP target properties add flags for
hidden visibility, if supported by the compiler.
.SH CROSS COMPILING
.sp
If \fI\%cmake(1)\fP is invoked with the command line parameter
\fI\%\-\-toolchain path/to/file\fP or
\fI\%\-DCMAKE_TOOLCHAIN_FILE=path/to/file\fP, the
file will be loaded early to set values for the compilers.
The \fI\%CMAKE_CROSSCOMPILING\fP variable is set to true when CMake is
cross\-compiling.
.sp
Note that using the \fI\%CMAKE_SOURCE_DIR\fP or \fI\%CMAKE_BINARY_DIR\fP
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 \fI\%try_compile()\fP).  In most
cases, where there is a need to evaluate paths inside a toolchain file, the more
appropriate variable to use would be \fI\%CMAKE_CURRENT_LIST_DIR\fP, since
it always has an unambiguous, predictable value.
.SS Cross Compiling for Linux
.sp
A typical cross\-compiling toolchain for Linux has content such
as:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
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)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Where:
.INDENT 0.0
.TP
.B \fI\%CMAKE_SYSTEM_NAME\fP
is the CMake\-identifier of the target platform to build for.
.TP
.B \fI\%CMAKE_SYSTEM_PROCESSOR\fP
is the CMake\-identifier of the target architecture.
.TP
.B \fI\%CMAKE_SYSROOT\fP
is optional, and may be specified if a sysroot is available.
.TP
.B \fI\%CMAKE_STAGING_PREFIX\fP
is also optional. It may be used to specify a path on the host to install to.
The \fI\%CMAKE_INSTALL_PREFIX\fP is always the runtime installation
location, even when cross\-compiling.
.TP
.B \fI\%CMAKE_<LANG>_COMPILER\fP
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
\fI\%CMAKE_TRY_COMPILE_TARGET_TYPE\fP variable to \fBSTATIC_LIBRARY\fP to
tell CMake not to try to link executables during its checks.
.UNINDENT
.sp
CMake \fBfind_*\fP commands will look in the sysroot, and the \fI\%CMAKE_FIND_ROOT_PATH\fP
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 \fBCMAKE_FIND_ROOT_PATH_MODE_*\fP variables.
.SS Cross Compiling for the Cray Linux Environment
.sp
Cross compiling for compute nodes in the Cray Linux Environment can be done
without needing a separate toolchain file.  Specifying
\fB\-DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment\fP 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\(aqs \fBPrgEnv\-*\fP modules if present and loaded.
.sp
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 \fBCRAYPE_LINK_TYPE\fP environment variable to
\fBdynamic\fP\&.
.sp
Running CMake without specifying \fI\%CMAKE_SYSTEM_NAME\fP will
run the configure step in host mode assuming a standard Linux environment.
If not overridden, the \fBPrgEnv\-*\fP 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 \fBPrgEnv\-*\fP module or explicitly tell CMake to use the
system compilers in \fB/usr/bin\fP instead of the Cray wrappers.  If instead
targeting a compute node is desired, just specify the
\fI\%CMAKE_SYSTEM_NAME\fP as mentioned above.
.SS Cross Compiling using Clang
.sp
Some compilers such as Clang are inherently cross compilers.
The \fI\%CMAKE_<LANG>_COMPILER_TARGET\fP can be set to pass a
value to those supported compilers when compiling:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
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})
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
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
\fI\%CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN\fP variable can be set in a
toolchain file to pass the path to the compiler driver.
.SS Cross Compiling for QNX
.sp
As the Clang compiler the QNX QCC compile is inherently a cross compiler.
And the \fI\%CMAKE_<LANG>_COMPILER_TARGET\fP can be set to pass a
value to those supported compilers when compiling:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
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})
.ft P
.fi
.UNINDENT
.UNINDENT
.SS Cross Compiling for Windows CE
.sp
Cross compiling for Windows CE requires the corresponding SDK being
installed on your system.  These SDKs are usually installed under
\fBC:/Program Files (x86)/Windows CE Tools/SDKs\fP\&.
.sp
A toolchain file to configure a Visual Studio generator for
Windows CE may look like this:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
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)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
The \fI\%CMAKE_GENERATOR_PLATFORM\fP tells the generator which SDK to use.
Further \fI\%CMAKE_SYSTEM_VERSION\fP 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
\fI\%CMAKE_GENERATOR_TOOLSET\fP to the correct value.
.SS Cross Compiling for Windows 10 Universal Applications
.sp
A toolchain file to configure \fI\%Visual Studio Generators\fP for a
Windows 10 Universal Application may look like this:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 10.0)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
A Windows 10 Universal Application targets both Windows Store and
Windows Phone.  Specify the \fI\%CMAKE_SYSTEM_VERSION\fP variable
to be \fB10.0\fP or higher.
.sp
CMake selects a Windows SDK as described by documentation of the
\fI\%CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION\fP variable.
.SS Cross Compiling for Windows Phone
.sp
A toolchain file to configure a Visual Studio generator for
Windows Phone may look like this:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(CMAKE_SYSTEM_NAME WindowsPhone)
set(CMAKE_SYSTEM_VERSION 8.1)
.ft P
.fi
.UNINDENT
.UNINDENT
.SS Cross Compiling for Windows Store
.sp
A toolchain file to configure a Visual Studio generator for
Windows Store may look like this:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 8.1)
.ft P
.fi
.UNINDENT
.UNINDENT
.SS Cross Compiling for ADSP SHARC/Blackfin
.sp
Cross\-compiling for ADSP SHARC or Blackfin can be configured
by setting the \fI\%CMAKE_SYSTEM_NAME\fP variable to \fBADSP\fP
and the \fI\%CMAKE_SYSTEM_PROCESSOR\fP variable
to the \(dqpart number\(dq, excluding the \fBADSP\-\fP prefix,
for example, \fB21594\fP, \fBSC589\fP, etc.
This value is case insensitive.
.sp
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 \fI\%CMAKE_ADSP_ROOT\fP variable
or the \fI\%ADSP_ROOT\fP environment variable.
.sp
The compiler (\fBcc21k\fP vs. \fBccblkfn\fP) is selected automatically
based on the \fI\%CMAKE_SYSTEM_PROCESSOR\fP value provided.
.SS Cross Compiling for Android
.sp
A toolchain file may configure cross\-compiling for Android by setting the
\fI\%CMAKE_SYSTEM_NAME\fP variable to \fBAndroid\fP\&.  Further configuration
is specific to the Android development environment to be used.
.sp
For \fI\%Visual Studio Generators\fP, CMake expects \fI\%NVIDIA Nsight Tegra
Visual Studio Edition\fP or the \fI\%Visual Studio tools for Android\fP to be installed. See those sections
for further configuration details.
.sp
For \fI\%Makefile Generators\fP and the \fI\%Ninja\fP generator,
CMake expects one of these environments:
.INDENT 0.0
.IP \(bu 2
\fI\%NDK\fP
.IP \(bu 2
\fI\%Standalone Toolchain\fP
.UNINDENT
.sp
CMake uses the following steps to select one of the environments:
.INDENT 0.0
.IP \(bu 2
If the \fI\%CMAKE_ANDROID_NDK\fP variable is set, the NDK at the
specified location will be used.
.IP \(bu 2
Else, if the \fI\%CMAKE_ANDROID_STANDALONE_TOOLCHAIN\fP variable
is set, the Standalone Toolchain at the specified location will be used.
.IP \(bu 2
Else, if the \fI\%CMAKE_SYSROOT\fP variable is set to a directory
of the form \fB<ndk>/platforms/android\-<api>/arch\-<arch>\fP, the \fB<ndk>\fP
part will be used as the value of \fI\%CMAKE_ANDROID_NDK\fP and the
NDK will be used.
.IP \(bu 2
Else, if the \fI\%CMAKE_SYSROOT\fP variable is set to a directory of the
form \fB<standalone\-toolchain>/sysroot\fP, the \fB<standalone\-toolchain>\fP part
will be used as the value of \fI\%CMAKE_ANDROID_STANDALONE_TOOLCHAIN\fP
and the Standalone Toolchain will be used.
.IP \(bu 2
Else, if a cmake variable \fBANDROID_NDK\fP is set it will be used
as the value of \fI\%CMAKE_ANDROID_NDK\fP, and the NDK will be used.
.IP \(bu 2
Else, if a cmake variable \fBANDROID_STANDALONE_TOOLCHAIN\fP is set, it will be
used as the value of \fI\%CMAKE_ANDROID_STANDALONE_TOOLCHAIN\fP, and the
Standalone Toolchain will be used.
.IP \(bu 2
Else, if an environment variable \fBANDROID_NDK_ROOT\fP or
\fBANDROID_NDK\fP is set, it will be used as the value of
\fI\%CMAKE_ANDROID_NDK\fP, and the NDK will be used.
.IP \(bu 2
Else, if an environment variable \fBANDROID_STANDALONE_TOOLCHAIN\fP is
set then it will be used as the value of
\fI\%CMAKE_ANDROID_STANDALONE_TOOLCHAIN\fP, and the Standalone
Toolchain will be used.
.IP \(bu 2
Else, an error diagnostic will be issued that neither the NDK or
Standalone Toolchain can be found.
.UNINDENT
.sp
New in version 3.20: If an Android NDK is selected, its version number is reported
in the \fI\%CMAKE_ANDROID_NDK_VERSION\fP variable.

.SS Cross Compiling for Android with the NDK
.sp
A toolchain file may configure \fI\%Makefile Generators\fP,
\fI\%Ninja Generators\fP, or \fI\%Visual Studio Generators\fP to target
Android for cross\-compiling.
.sp
Configure use of an Android NDK with the following variables:
.INDENT 0.0
.TP
.B \fI\%CMAKE_SYSTEM_NAME\fP
Set to \fBAndroid\fP\&.  Must be specified to enable cross compiling
for Android.
.TP
.B \fI\%CMAKE_SYSTEM_VERSION\fP
Set to the Android API level.  If not specified, the value is
determined as follows:
.INDENT 7.0
.IP \(bu 2
If the \fI\%CMAKE_ANDROID_API\fP variable is set, its value
is used as the API level.
.IP \(bu 2
If the \fI\%CMAKE_SYSROOT\fP variable is set, the API level is
detected from the NDK directory structure containing the sysroot.
.IP \(bu 2
Otherwise, the latest API level available in the NDK is used.
.UNINDENT
.TP
.B \fI\%CMAKE_ANDROID_ARCH_ABI\fP
Set to the Android ABI (architecture).  If not specified, this
variable will default to the first supported ABI in the list of
\fBarmeabi\fP, \fBarmeabi\-v7a\fP and \fBarm64\-v8a\fP\&.
The \fI\%CMAKE_ANDROID_ARCH\fP variable will be computed
from \fBCMAKE_ANDROID_ARCH_ABI\fP automatically.
Also see the \fI\%CMAKE_ANDROID_ARM_MODE\fP and
\fI\%CMAKE_ANDROID_ARM_NEON\fP variables.
.TP
.B \fI\%CMAKE_ANDROID_NDK\fP
Set to the absolute path to the Android NDK root directory.
If not specified, a default for this variable will be chosen
as specified \fI\%above\fP\&.
.TP
.B \fI\%CMAKE_ANDROID_NDK_DEPRECATED_HEADERS\fP
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.
.TP
.B \fI\%CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION\fP
On NDK r19 or above, this variable must be unset or set to \fBclang\fP\&.
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.
.TP
.B \fI\%CMAKE_ANDROID_STL_TYPE\fP
Set to specify which C++ standard library to use.  If not specified,
a default will be selected as described in the variable documentation.
.UNINDENT
.sp
The following variables will be computed and provided automatically:
.INDENT 0.0
.TP
.B \fI\%CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX\fP
The absolute path prefix to the binutils in the NDK toolchain.
.TP
.B \fI\%CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX\fP
The host platform suffix of the binutils in the NDK toolchain.
.UNINDENT
.sp
For example, a toolchain file might contain:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
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)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Alternatively one may specify the values without a toolchain file:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ cmake ../src \e
  \-DCMAKE_SYSTEM_NAME=Android \e
  \-DCMAKE_SYSTEM_VERSION=21 \e
  \-DCMAKE_ANDROID_ARCH_ABI=arm64\-v8a \e
  \-DCMAKE_ANDROID_NDK=/path/to/android\-ndk \e
  \-DCMAKE_ANDROID_STL_TYPE=gnustl_static
.ft P
.fi
.UNINDENT
.UNINDENT
.SS Cross Compiling for Android with a Standalone Toolchain
.sp
A toolchain file may configure \fI\%Makefile Generators\fP or the
\fI\%Ninja\fP generator to target Android for cross\-compiling
using a standalone toolchain.
.sp
Configure use of an Android standalone toolchain with the following variables:
.INDENT 0.0
.TP
.B \fI\%CMAKE_SYSTEM_NAME\fP
Set to \fBAndroid\fP\&.  Must be specified to enable cross compiling
for Android.
.TP
.B \fI\%CMAKE_ANDROID_STANDALONE_TOOLCHAIN\fP
Set to the absolute path to the standalone toolchain root directory.
A \fB${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot\fP directory
must exist.
If not specified, a default for this variable will be chosen
as specified \fI\%above\fP\&.
.TP
.B \fI\%CMAKE_ANDROID_ARM_MODE\fP
When the standalone toolchain targets ARM, optionally set this to \fBON\fP
to target 32\-bit ARM instead of 16\-bit Thumb.
See variable documentation for details.
.TP
.B \fI\%CMAKE_ANDROID_ARM_NEON\fP
When the standalone toolchain targets ARM v7, optionally set thisto \fBON\fP
to target ARM NEON devices.  See variable documentation for details.
.UNINDENT
.sp
The following variables will be computed and provided automatically:
.INDENT 0.0
.TP
.B \fI\%CMAKE_SYSTEM_VERSION\fP
The Android API level detected from the standalone toolchain.
.TP
.B \fI\%CMAKE_ANDROID_ARCH_ABI\fP
The Android ABI detected from the standalone toolchain.
.TP
.B \fI\%CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX\fP
The absolute path prefix to the \fBbinutils\fP in the standalone toolchain.
.TP
.B \fI\%CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX\fP
The host platform suffix of the \fBbinutils\fP in the standalone toolchain.
.UNINDENT
.sp
For example, a toolchain file might contain:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /path/to/android\-toolchain)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Alternatively one may specify the values without a toolchain file:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ cmake ../src \e
  \-DCMAKE_SYSTEM_NAME=Android \e
  \-DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/path/to/android\-toolchain
.ft P
.fi
.UNINDENT
.UNINDENT
.SS Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition
.sp
A toolchain file to configure one of the \fI\%Visual Studio Generators\fP
to build using NVIDIA Nsight Tegra targeting Android may look like this:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(CMAKE_SYSTEM_NAME Android)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
The \fI\%CMAKE_GENERATOR_TOOLSET\fP may be set to select
the Nsight Tegra \(dqToolchain Version\(dq value.
.sp
See also target properties:
.INDENT 0.0
.IP \(bu 2
\fI\%ANDROID_ANT_ADDITIONAL_OPTIONS\fP
.IP \(bu 2
\fI\%ANDROID_API_MIN\fP
.IP \(bu 2
\fI\%ANDROID_API\fP
.IP \(bu 2
\fI\%ANDROID_ARCH\fP
.IP \(bu 2
\fI\%ANDROID_ASSETS_DIRECTORIES\fP
.IP \(bu 2
\fI\%ANDROID_GUI\fP
.IP \(bu 2
\fI\%ANDROID_JAR_DEPENDENCIES\fP
.IP \(bu 2
\fI\%ANDROID_JAR_DIRECTORIES\fP
.IP \(bu 2
\fI\%ANDROID_JAVA_SOURCE_DIR\fP
.IP \(bu 2
\fI\%ANDROID_NATIVE_LIB_DEPENDENCIES\fP
.IP \(bu 2
\fI\%ANDROID_NATIVE_LIB_DIRECTORIES\fP
.IP \(bu 2
\fI\%ANDROID_PROCESS_MAX\fP
.IP \(bu 2
\fI\%ANDROID_PROGUARD_CONFIG_PATH\fP
.IP \(bu 2
\fI\%ANDROID_PROGUARD\fP
.IP \(bu 2
\fI\%ANDROID_SECURE_PROPS_PATH\fP
.IP \(bu 2
\fI\%ANDROID_SKIP_ANT_STEP\fP
.IP \(bu 2
\fI\%ANDROID_STL_TYPE\fP
.UNINDENT
.SS Cross Compiling for iOS, tvOS, visionOS, or watchOS
.sp
For cross\-compiling to iOS, tvOS, visionOS, or watchOS, the \fI\%Xcode\fP
generator is recommended.  The \fI\%Unix Makefiles\fP or
\fI\%Ninja\fP generators can also be used, but they require the
project to handle more areas like target CPU selection and code signing.
.sp
Any of the Apple device platforms can be targeted by setting the
\fI\%CMAKE_SYSTEM_NAME\fP 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
\fI\%CMAKE_OSX_SYSROOT\fP variable, although this should rarely be
necessary (see \fI\%Switching Between Device and Simulator\fP below).
A list of available SDKs can be obtained by running \fBxcodebuild \-showsdks\fP\&.
.TS
center;
|l|l|l|l|.
_
T{
OS
T}	T{
CMAKE_SYSTEM_NAME
T}	T{
Device SDK (default)
T}	T{
Simulator SDK
T}
_
T{
iOS
T}	T{
iOS
T}	T{
iphoneos
T}	T{
iphonesimulator
T}
_
T{
tvOS
T}	T{
tvOS
T}	T{
appletvos
T}	T{
appletvsimulator
T}
_
T{
visionOS
T}	T{
visionOS
T}	T{
xros
T}	T{
xrsimulator
T}
_
T{
watchOS
T}	T{
watchOS
T}	T{
watchos
T}	T{
watchsimulator
T}
_
.TE
.sp
For example, to create a CMake configuration for iOS, the following
command is sufficient:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
cmake .. \-GXcode \-DCMAKE_SYSTEM_NAME=iOS
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Variable \fI\%CMAKE_OSX_ARCHITECTURES\fP can be used to set architectures
for both device and simulator. Variable \fI\%CMAKE_OSX_DEPLOYMENT_TARGET\fP
can be used to set an iOS/tvOS/visionOS/watchOS deployment target.
.sp
The next example installs five architectures in a universal binary for an iOS
library.  It adds the relevant \fB\-miphoneos\-version\-min=9.3\fP or
\fB\-mios\-simulator\-version\-min=9.3\fP compiler flag where appropriate.
Note that the \fI\%CMAKE_IOS_INSTALL_COMBINED\fP variable used in the
example is now deprecated, so this approach is no longer recommended.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ cmake \-S. \-B_builds \-GXcode \e
    \-DCMAKE_SYSTEM_NAME=iOS \e
    \(dq\-DCMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64;i386;x86_64\(dq \e
    \-DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 \e
    \-DCMAKE_INSTALL_PREFIX=\(gapwd\(ga/_install \e
    \-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \e
    \-DCMAKE_IOS_INSTALL_COMBINED=YES
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
# CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(foo)
add_library(foo foo.cpp)
install(TARGETS foo DESTINATION lib)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Install:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ cmake \-\-build _builds \-\-config Release \-\-target install
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Check library:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ lipo \-info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 armv7s x86_64 arm64
.ft P
.fi
.UNINDENT
.UNINDENT
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ otool \-l _install/lib/libfoo.a | grep \-A2 LC_VERSION_MIN_IPHONEOS
      cmd LC_VERSION_MIN_IPHONEOS
  cmdsize 16
  version 9.3
.ft P
.fi
.UNINDENT
.UNINDENT
.SS Code Signing
.sp
Some build artifacts for the embedded Apple platforms require mandatory
code signing.  If the \fI\%Xcode\fP generator is being used and
code signing is required or desired, the development team ID can be
specified via the \fBCMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM\fP 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).
.SS Switching Between Device and Simulator
.sp
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 \fI\%Xcode\fP 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 \(dqdestination\(dq
platform.  When building from the command line, the desired sdk can be
specified directly by passing a \fB\-sdk\fP option to the underlying build
tool (\fBxcodebuild\fP).  For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
$ cmake \-\-build ... \-\- \-sdk iphonesimulator
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Please note that checks made during configuration were performed against
the configure\-time SDK and might not hold true for other SDKs.  Commands
like \fI\%find_package()\fP, \fI\%find_library()\fP, 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:
.INDENT 0.0
.IP \(bu 2
Use explicit \fB\-l\fP linker flag,
e.g. \fBtarget_link_libraries(foo PUBLIC \(dq\-lz\(dq)\fP
.IP \(bu 2
Use explicit \fB\-framework\fP linker flag,
e.g. \fBtarget_link_libraries(foo PUBLIC \(dq\-framework CoreFoundation\(dq)\fP
.IP \(bu 2
Use \fI\%find_package()\fP only for libraries installed with
\fI\%CMAKE_IOS_INSTALL_COMBINED\fP feature
.UNINDENT
.SH COPYRIGHT
2000-2024 Kitware, Inc. and Contributors
.\" Generated by docutils manpage writer.
.