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-GENERATORS" "7" "Mar 04, 2024" "3.29.0" "CMake"
.SH NAME
cmake-generators \- CMake Generators Reference
.SH INTRODUCTION
.sp
A \fICMake Generator\fP is responsible for writing the input files for
a native build system.  Exactly one of the \fI\%CMake Generators\fP must be
selected for a build tree to determine what native build system is to
be used.  Optionally one of the \fI\%Extra Generators\fP may be selected
as a variant of some of the \fI\%Command\-Line Build Tool Generators\fP to
produce project files for an auxiliary IDE.
.sp
CMake Generators are platform\-specific so each may be available only
on certain platforms.  The \fI\%cmake(1)\fP command\-line tool
\fI\%\-\-help\fP output lists available generators on the
current platform.  Use its \fI\%\-G\fP option to specify the
generator for a new build tree. The \fI\%cmake\-gui(1)\fP offers
interactive selection of a generator when creating a new build tree.
.SH CMAKE GENERATORS
.SS Command\-Line Build Tool Generators
.sp
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.
.SS Makefile Generators
.SS Borland Makefiles
.sp
Generates Borland makefiles.
.SS MSYS Makefiles
.sp
Generates makefiles for use with MSYS (Minimal SYStem)
\fBmake\fP under the MSYS shell.
.sp
Use this generator in a MSYS shell prompt and using \fBmake\fP as the build
tool.  The generated makefiles use \fB/bin/sh\fP as the shell to launch build
rules.  They are not compatible with a Windows command prompt.
.sp
To build under a Windows command prompt, use the
\fI\%MinGW Makefiles\fP generator.
.SS MinGW Makefiles
.sp
Generates makefiles for use with \fBmingw32\-make\fP under a Windows command
prompt.
.sp
Use this generator under a Windows command prompt with
MinGW (Minimalist GNU for Windows) in the \fBPATH\fP
and using \fBmingw32\-make\fP as the build tool.  The generated makefiles use
\fBcmd.exe\fP as the shell to launch build rules.  They are not compatible with
MSYS or a unix shell.
.sp
To build under the MSYS shell, use the \fI\%MSYS Makefiles\fP generator.
.SS NMake Makefiles
.sp
Generates NMake makefiles.
.SS NMake Makefiles JOM
.sp
Generates JOM makefiles.
.sp
New in version 3.8: \fI\%CodeBlocks\fP generator can be used as an extra generator.

.SS Unix Makefiles
.sp
Generates standard UNIX makefiles.
.sp
A hierarchy of UNIX makefiles is generated into the build tree.  Use
any standard UNIX\-style make program to build the project through
the \fBall\fP target and install the project through the \fBinstall\fP
(or \fBinstall/strip\fP) target.
.sp
For each subdirectory \fBsub/dir\fP of the project a UNIX makefile will
be created, containing the following targets:
.INDENT 0.0
.TP
.B \fBall\fP
Depends on all targets required by the subdirectory.
.TP
.B \fBinstall\fP
Runs the install step in the subdirectory, if any.
.TP
.B \fBinstall/strip\fP
Runs the install step in the subdirectory followed by a \fBCMAKE_STRIP\fP command,
if any.
.sp
The \fBCMAKE_STRIP\fP variable will contain the platform\(aqs \fBstrip\fP utility, which
removes symbols information from generated binaries.
.TP
.B \fBtest\fP
Runs the test step in the subdirectory, if any.
.TP
.B \fBpackage\fP
Runs the package step in the subdirectory, if any.
.UNINDENT
.SS Watcom WMake
.sp
Generates Watcom WMake makefiles.
.SS Ninja Generators
.SS Ninja
.sp
Generates \fBbuild.ninja\fP files.
.sp
A \fBbuild.ninja\fP file is generated into the build tree.  Use the ninja
program to build the project through the \fBall\fP target and install the
project through the \fBinstall\fP (or \fBinstall/strip\fP) target.
.sp
For each subdirectory \fBsub/dir\fP of the project, additional targets
are generated:
.sp
\fBsub/dir/all\fP
.INDENT 0.0
.INDENT 3.5
New in version 3.6: Depends on all targets required by the subdirectory.

.UNINDENT
.UNINDENT
.sp
\fBsub/dir/install\fP
.INDENT 0.0
.INDENT 3.5
New in version 3.7: Runs the install step in the subdirectory, if any.

.UNINDENT
.UNINDENT
.sp
\fBsub/dir/install/strip\fP
.INDENT 0.0
.INDENT 3.5
New in version 3.7: Runs the install step in the subdirectory followed by a \fBCMAKE_STRIP\fP command,
if any.
.sp
The \fBCMAKE_STRIP\fP variable will contain the platform\(aqs \fBstrip\fP utility, which
removes symbols information from generated binaries.

.UNINDENT
.UNINDENT
.sp
\fBsub/dir/test\fP
.INDENT 0.0
.INDENT 3.5
New in version 3.7: Runs the test step in the subdirectory, if any.

.UNINDENT
.UNINDENT
.sp
\fBsub/dir/package\fP
.INDENT 0.0
.INDENT 3.5
New in version 3.7: Runs the package step in the subdirectory, if any.

.UNINDENT
.UNINDENT
.SS Fortran Support
.sp
New in version 3.7.

.sp
The \fBNinja\fP generator conditionally supports Fortran when the \fBninja\fP
tool is at least version 1.10 (which has the required features).
.SS Swift Support
.sp
New in version 3.15.

.sp
The Swift support is experimental, not considered stable, and may change
in future releases of CMake.
.SS See Also
.sp
New in version 3.17: The \fI\%Ninja Multi\-Config\fP generator is similar to the \fBNinja\fP
generator, but generates multiple configurations at once.

.SS Ninja Multi\-Config
.sp
New in version 3.17.

.sp
Generates multiple \fBbuild\-<Config>.ninja\fP files.
.sp
This generator is very much like the \fI\%Ninja\fP generator, but with
some key differences. Only these differences will be discussed in this
document.
.sp
Unlike the \fI\%Ninja\fP generator, \fBNinja Multi\-Config\fP generates
multiple configurations at once with \fI\%CMAKE_CONFIGURATION_TYPES\fP
instead of only one configuration with \fI\%CMAKE_BUILD_TYPE\fP\&. One
\fBbuild\-<Config>.ninja\fP file will be generated for each of these
configurations (with \fB<Config>\fP being the configuration name.) These files
are intended to be run with \fBninja \-f build\-<Config>.ninja\fP\&. A
\fBbuild.ninja\fP file is also generated, using the configuration from either
\fI\%CMAKE_DEFAULT_BUILD_TYPE\fP or the first item from
\fI\%CMAKE_CONFIGURATION_TYPES\fP\&.
.sp
\fBcmake \-\-build . \-\-config <Config>\fP will always use \fBbuild\-<Config>.ninja\fP
to build. If no \fI\%\-\-config\fP argument is
specified, \fI\%cmake \-\-build .\fP will use \fBbuild.ninja\fP\&.
.sp
Each \fBbuild\-<Config>.ninja\fP file contains \fB<target>\fP targets as well as
\fB<target>:<Config>\fP targets, where \fB<Config>\fP is the same as the
configuration specified in \fBbuild\-<Config>.ninja\fP Additionally, if
cross\-config mode is enabled, \fBbuild\-<Config>.ninja\fP may contain
\fB<target>:<OtherConfig>\fP targets, where \fB<OtherConfig>\fP is a cross\-config,
as well as \fB<target>:all\fP, which builds the target in all cross\-configs. See
below for how to enable cross\-config mode.
.sp
The \fBNinja Multi\-Config\fP generator recognizes the following variables:
.INDENT 0.0
.TP
.B \fI\%CMAKE_CONFIGURATION_TYPES\fP
Specifies the total set of configurations to build. Unlike with other
multi\-config generators, this variable has a value of
\fBDebug;Release;RelWithDebInfo\fP by default.
.TP
.B \fI\%CMAKE_CROSS_CONFIGS\fP
Specifies a \fI\%semicolon\-separated list\fP of
configurations available from all \fBbuild\-<Config>.ninja\fP files.
.TP
.B \fI\%CMAKE_DEFAULT_BUILD_TYPE\fP
Specifies the configuration to use by default in a \fBbuild.ninja\fP file.
.TP
.B \fI\%CMAKE_DEFAULT_CONFIGS\fP
Specifies a \fI\%semicolon\-separated list\fP of
configurations to build for a target in \fBbuild.ninja\fP
if no \fB:<Config>\fP suffix is specified.
.UNINDENT
.sp
Consider the following example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
cmake_minimum_required(VERSION 3.16)
project(MultiConfigNinja C)

add_executable(generator generator.c)
add_custom_command(OUTPUT generated.c COMMAND generator generated.c)
add_library(generated ${CMAKE_BINARY_DIR}/generated.c)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Now assume you configure the project with \fBNinja Multi\-Config\fP and run one of
the following commands:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
ninja \-f build\-Debug.ninja generated
# OR
cmake \-\-build . \-\-config Debug \-\-target generated
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
This would build the \fBDebug\fP configuration of \fBgenerator\fP, which would be
used to generate \fBgenerated.c\fP, which would be used to build the \fBDebug\fP
configuration of \fBgenerated\fP\&.
.sp
But if \fI\%CMAKE_CROSS_CONFIGS\fP is set to \fBall\fP, and you run the
following instead:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
ninja \-f build\-Release.ninja generated:Debug
# OR
cmake \-\-build . \-\-config Release \-\-target generated:Debug
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
This would build the \fBRelease\fP configuration of \fBgenerator\fP, which would be
used to generate \fBgenerated.c\fP, which would be used to build the \fBDebug\fP
configuration of \fBgenerated\fP\&. This is useful for running a release\-optimized
version of a generator utility while still building the debug version of the
targets built with the generated code.
.SS Custom Commands
.sp
New in version 3.20.

.sp
The \fBNinja Multi\-Config\fP generator adds extra capabilities to
\fI\%add_custom_command()\fP and \fI\%add_custom_target()\fP through its
cross\-config mode. The \fBCOMMAND\fP, \fBDEPENDS\fP, and \fBWORKING_DIRECTORY\fP
arguments can be evaluated in the context of either the \(dqcommand config\(dq (the
\(dqnative\(dq configuration of the \fBbuild\-<Config>.ninja\fP file in use) or the
\(dqoutput config\(dq (the configuration used to evaluate the \fBOUTPUT\fP and
\fBBYPRODUCTS\fP).
.sp
If either \fBOUTPUT\fP or \fBBYPRODUCTS\fP names a path that is common to
more than one configuration (e.g. it does not use any generator expressions),
all arguments are evaluated in the command config by default.
If all \fBOUTPUT\fP and \fBBYPRODUCTS\fP paths are unique to each configuration
(e.g. by using the \fI\%$<CONFIG>\fP generator expression), the first argument of
\fBCOMMAND\fP is still evaluated in the command config by default, while all
subsequent arguments, as well as the arguments to \fBDEPENDS\fP and
\fBWORKING_DIRECTORY\fP, are evaluated in the output config. These defaults can
be overridden with the \fI\%$<OUTPUT_CONFIG:...>\fP and \fI\%$<COMMAND_CONFIG:...>\fP
generator\-expressions. Note that if a target is specified by its name in
\fBDEPENDS\fP, or as the first argument of \fBCOMMAND\fP, it is always evaluated
in the command config, even if it is wrapped in \fI\%$<OUTPUT_CONFIG:...>\fP
(because its plain name is not a generator expression).
.sp
As an example, consider the following:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
add_custom_command(
  OUTPUT \(dq$<CONFIG>.txt\(dq
  COMMAND
    generator \(dq$<CONFIG>.txt\(dq
              \(dq$<OUTPUT_CONFIG:$<CONFIG>>\(dq
              \(dq$<COMMAND_CONFIG:$<CONFIG>>\(dq
  DEPENDS
    tgt1
    \(dq$<TARGET_FILE:tgt2>\(dq
    \(dq$<OUTPUT_CONFIG:$<TARGET_FILE:tgt3>>\(dq
    \(dq$<COMMAND_CONFIG:$<TARGET_FILE:tgt4>>\(dq
  )
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Assume that \fBgenerator\fP, \fBtgt1\fP, \fBtgt2\fP, \fBtgt3\fP, and \fBtgt4\fP are all
executable targets, and assume that \fB$<CONFIG>.txt\fP is built in the \fBDebug\fP
output config using the \fBRelease\fP command config. The \fBRelease\fP build of
the \fBgenerator\fP target is called with \fBDebug.txt Debug Release\fP as
arguments. The command depends on the \fBRelease\fP builds of \fBtgt1\fP and
\fBtgt4\fP, and the \fBDebug\fP builds of \fBtgt2\fP and \fBtgt3\fP\&.
.sp
\fBPRE_BUILD\fP, \fBPRE_LINK\fP, and \fBPOST_BUILD\fP custom commands for targets
only get run in their \(dqnative\(dq configuration (the \fBRelease\fP configuration in
the \fBbuild\-Release.ninja\fP file) unless they have no \fBBYPRODUCTS\fP or their
\fBBYPRODUCTS\fP are unique per config. Consider the following example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
add_executable(exe main.c)
add_custom_command(
  TARGET exe
  POST_BUILD
  COMMAND
    ${CMAKE_COMMAND} \-E echo \(dqRunning no\-byproduct command\(dq
  )
add_custom_command(
  TARGET exe
  POST_BUILD
  COMMAND
    ${CMAKE_COMMAND} \-E echo
    \(dqRunning separate\-byproduct command for $<CONFIG>\(dq
  BYPRODUCTS $<CONFIG>.txt
  )
add_custom_command(
  TARGET exe
  POST_BUILD
  COMMAND
    ${CMAKE_COMMAND} \-E echo
    \(dqRunning common\-byproduct command for $<CONFIG>\(dq
  BYPRODUCTS exe.txt
  )
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
In this example, if you build \fBexe:Debug\fP in \fBbuild\-Release.ninja\fP, the
first and second custom commands get run, since their byproducts are unique
per\-config, but the last custom command does not. However, if you build
\fBexe:Release\fP in \fBbuild\-Release.ninja\fP, all three custom commands get run.
.SS IDE Build Tool Generators
.sp
These generators support Integrated Development Environment (IDE)
project files.  Since the IDEs configure their own environment
one may launch CMake from any environment.
.SS Visual Studio Generators
.SS Visual Studio 6
.sp
Removed.  This once generated Visual Studio 6 project files, but the
generator has been removed since CMake 3.6.  It is still possible to
build with VS 6 tools using the \fI\%NMake Makefiles\fP generator.
.SS Visual Studio 7
.sp
Removed.  This once generated Visual Studio .NET 2002 project files, but
the generator has been removed since CMake 3.6.  It is still possible to
build with VS 7.0 tools using the \fI\%NMake Makefiles\fP generator.
.SS Visual Studio 7 .NET 2003
.sp
Removed.  This once generated Visual Studio .NET 2003 project files, but
the generator has been removed since CMake 3.9.  It is still possible to
build with VS 7.1 tools using the \fI\%NMake Makefiles\fP generator.
.SS Visual Studio 8 2005
.sp
Removed.  This once generated Visual Studio 8 2005 project files, but
the generator has been removed since CMake 3.12.  It is still possible to
build with VS 2005 tools using the \fI\%NMake Makefiles\fP generator.
.SS Visual Studio 9 2008
.sp
Deprecated.  Generates Visual Studio 9 2008 project files.
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
This generator is deprecated and will be removed in a future version
of CMake.  It will still be possible to build with VS 9 2008 tools
using the \fI\%Visual Studio 14 2015\fP generator (or above,
and with VS 10 2010 also installed) with
\fI\%CMAKE_GENERATOR_TOOLSET\fP set to \fBv90\fP,
or by using the \fI\%NMake Makefiles\fP generator.
.UNINDENT
.UNINDENT
.SS Platform Selection
.sp
The default target platform name (architecture) is \fBWin32\fP\&.
.sp
New in version 3.1: The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option, to specify a target platform
name (architecture).  For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 9 2008\(dq \-A Win32\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 9 2008\(dq \-A x64\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 9 2008\(dq \-A Itanium\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 9 2008\(dq \-A <WinCE\-SDK>\fP
(Specify a target platform matching a Windows CE SDK name.)
.UNINDENT

.sp
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
.INDENT 0.0
.TP
.B \fBVisual Studio 9 2008 Win64\fP
Specify target platform \fBx64\fP\&.
.TP
.B \fBVisual Studio 9 2008 IA64\fP
Specify target platform \fBItanium\fP\&.
.TP
.B \fBVisual Studio 9 2008 <WinCE\-SDK>\fP
Specify target platform matching a Windows CE SDK name.
.UNINDENT
.SS Visual Studio 10 2010
.sp
Removed.  This once generated Visual Studio 10 2010 project files, but
the generator has been removed since CMake 3.25.  It is still possible
to build with VS 10 2010 tools using the \fI\%Visual Studio 14 2015\fP
(or above) generator with \fI\%CMAKE_GENERATOR_TOOLSET\fP set to
\fBv100\fP, or by using the \fI\%NMake Makefiles\fP generator.
.SS Visual Studio 11 2012
.sp
Removed.  This once generated Visual Studio 11 2012 project files, but
the generator has been removed since CMake 3.28.  It is still possible
to build with VS 11 2012 tools using the \fI\%Visual Studio 14 2015\fP
(or above) generator with \fI\%CMAKE_GENERATOR_TOOLSET\fP set to \fBv110\fP,
or by using the \fI\%NMake Makefiles\fP generator.
.SS Visual Studio 12 2013
.sp
Deprecated.  Generates Visual Studio 12 (VS 2013) project files.
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
This generator is deprecated and will be removed in a future version
of CMake.  It will still be possible to build with VS 12 2013 tools
using the \fI\%Visual Studio 14 2015\fP (or above) generator
with \fI\%CMAKE_GENERATOR_TOOLSET\fP set to \fBv120\fP, or by
using the \fI\%NMake Makefiles\fP generator.
.UNINDENT
.UNINDENT
.sp
For compatibility with CMake versions prior to 3.0, one may specify this
generator using the name \(dqVisual Studio 12\(dq without the year component.
.SS Project Types
.sp
Only Visual C++ and C# projects may be generated (and Fortran with
Intel compiler integration).  Other types of projects (JavaScript,
Powershell, Python, etc.) are not supported.
.SS Platform Selection
.sp
The default target platform name (architecture) is \fBWin32\fP\&.
.sp
New in version 3.1: The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option, to specify a target platform
name (architecture).  For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 12 2013\(dq \-A Win32\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 12 2013\(dq \-A x64\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 12 2013\(dq \-A ARM\fP
.UNINDENT

.sp
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
.INDENT 0.0
.TP
.B \fBVisual Studio 12 2013 Win64\fP
Specify target platform \fBx64\fP\&.
.TP
.B \fBVisual Studio 12 2013 ARM\fP
Specify target platform \fBARM\fP\&.
.UNINDENT
.SS Toolset Selection
.sp
The \fBv120\fP toolset that comes with Visual Studio 12 2013 is selected by
default.  The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify another toolset.
.sp
New in version 3.8: For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32\-bit (\fBx86\fP) and
64\-bit (\fBx64\fP) hosts (independent of the architecture they target).
By default this generator uses the 32\-bit variant even on a 64\-bit host.
One may explicitly request use of either the 32\-bit or 64\-bit host tools
by adding either \fBhost=x86\fP or \fBhost=x64\fP to the toolset specification.
See the \fI\%CMAKE_GENERATOR_TOOLSET\fP variable for details.

.sp
New in version 3.14: Added support for \fBhost=x86\fP option.

.SS Visual Studio 14 2015
.sp
New in version 3.1.

.sp
Generates Visual Studio 14 (VS 2015) project files.
.SS Project Types
.sp
Only Visual C++ and C# projects may be generated (and Fortran with
Intel compiler integration).  Other types of projects (JavaScript,
Powershell, Python, etc.) are not supported.
.SS Platform Selection
.sp
The default target platform name (architecture) is \fBWin32\fP\&.
.sp
The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option, to specify a target platform
name (architecture).  For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 14 2015\(dq \-A Win32\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 14 2015\(dq \-A x64\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 14 2015\(dq \-A ARM\fP
.UNINDENT
.sp
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
.INDENT 0.0
.TP
.B \fBVisual Studio 14 2015 Win64\fP
Specify target platform \fBx64\fP\&.
.TP
.B \fBVisual Studio 14 2015 ARM\fP
Specify target platform \fBARM\fP\&.
.UNINDENT
.SS Toolset Selection
.sp
The \fBv140\fP toolset that comes with Visual Studio 14 2015 is selected by
default.  The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify another toolset.
.sp
New in version 3.8: For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32\-bit (\fBx86\fP) and
64\-bit (\fBx64\fP) hosts (independent of the architecture they target).
By default this generator uses the 32\-bit variant even on a 64\-bit host.
One may explicitly request use of either the 32\-bit or 64\-bit host tools
by adding either \fBhost=x86\fP or \fBhost=x64\fP to the toolset specification.
See the \fI\%CMAKE_GENERATOR_TOOLSET\fP variable for details.

.sp
New in version 3.14: Added support for \fBhost=x86\fP option.

.SS Windows 10 SDK Maximum Version for VS 2015
.sp
New in version 3.19.

.sp
Microsoft stated in a \(dqWindows 10 October 2018 Update\(dq blog post that Windows
10 SDK versions (15063, 16299, 17134, 17763) are not supported by VS 2015 and
are only supported by VS 2017 and later.  Therefore by default CMake
automatically ignores Windows 10 SDKs beyond \fB10.0.14393.0\fP\&.
.sp
However, there are other recommendations for certain driver/Win32 builds that
indicate otherwise.  A user can override this behavior by either setting the
\fI\%CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM\fP to a false value
or setting the \fI\%CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM\fP to
the string value of the required maximum (e.g. \fB10.0.15063.0\fP).
.SS Visual Studio 15 2017
.sp
New in version 3.7.1.

.sp
Generates Visual Studio 15 (VS 2017) project files.
.SS Project Types
.sp
Only Visual C++ and C# projects may be generated (and Fortran with
Intel compiler integration).  Other types of projects (JavaScript,
Powershell, Python, etc.) are not supported.
.SS Instance Selection
.sp
New in version 3.11.

.sp
VS 2017 supports multiple installations on the same machine.  The
\fI\%CMAKE_GENERATOR_INSTANCE\fP variable may be used to select one.
.SS Platform Selection
.sp
The default target platform name (architecture) is \fBWin32\fP\&.
.sp
The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option, to specify a target platform
name (architecture).  For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 15 2017\(dq \-A Win32\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 15 2017\(dq \-A x64\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 15 2017\(dq \-A ARM\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 15 2017\(dq \-A ARM64\fP
.UNINDENT
.sp
For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:
.INDENT 0.0
.TP
.B \fBVisual Studio 15 2017 Win64\fP
Specify target platform \fBx64\fP\&.
.TP
.B \fBVisual Studio 15 2017 ARM\fP
Specify target platform \fBARM\fP\&.
.UNINDENT
.SS Toolset Selection
.sp
The \fBv141\fP toolset that comes with Visual Studio 15 2017 is selected by
default.  The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify another toolset.
.sp
New in version 3.8: For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32\-bit (\fBx86\fP) and
64\-bit (\fBx64\fP) hosts (independent of the architecture they target).
By default this generator uses the 32\-bit variant even on a 64\-bit host.
One may explicitly request use of either the 32\-bit or 64\-bit host tools
by adding either \fBhost=x86\fP or \fBhost=x64\fP to the toolset specification.
See the \fI\%CMAKE_GENERATOR_TOOLSET\fP variable for details.

.sp
New in version 3.14: Added support for \fBhost=x86\fP option.

.SS Visual Studio 16 2019
.sp
New in version 3.14.

.sp
Generates Visual Studio 16 (VS 2019) project files.
.SS Project Types
.sp
Only Visual C++ and C# projects may be generated (and Fortran with
Intel compiler integration).  Other types of projects (JavaScript,
Powershell, Python, etc.) are not supported.
.SS Instance Selection
.sp
VS 2019 supports multiple installations on the same machine.  The
\fI\%CMAKE_GENERATOR_INSTANCE\fP variable may be used to select one.
.SS Platform Selection
.sp
The default target platform name (architecture) is that of the host
and is provided in the \fI\%CMAKE_VS_PLATFORM_NAME_DEFAULT\fP variable.
.sp
The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option, to specify a target platform
name (architecture).  For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 16 2019\(dq \-A Win32\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 16 2019\(dq \-A x64\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 16 2019\(dq \-A ARM\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 16 2019\(dq \-A ARM64\fP
.UNINDENT
.SS Toolset Selection
.sp
The \fBv142\fP toolset that comes with Visual Studio 16 2019 is selected by
default.  The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify another toolset.
.sp
For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32\-bit (\fBx86\fP) and
64\-bit (\fBx64\fP) hosts (independent of the architecture they target).
By default this generator uses the 64\-bit variant on x64 hosts and
the 32\-bit variant otherwise.
One may explicitly request use of either the 32\-bit or 64\-bit host tools
by adding either \fBhost=x86\fP or \fBhost=x64\fP to the toolset specification.
See the \fI\%CMAKE_GENERATOR_TOOLSET\fP variable for details.
.SS Visual Studio 17 2022
.sp
New in version 3.21.

.sp
Generates Visual Studio 17 (VS 2022) project files.
.SS Project Types
.sp
Only Visual C++ and C# projects may be generated (and Fortran with
Intel compiler integration).  Other types of projects (JavaScript,
Powershell, Python, etc.) are not supported.
.SS Instance Selection
.sp
VS 2022 supports multiple installations on the same machine.  The
\fI\%CMAKE_GENERATOR_INSTANCE\fP variable may be used to select one.
.SS Platform Selection
.sp
The default target platform name (architecture) is that of the host
and is provided in the \fI\%CMAKE_VS_PLATFORM_NAME_DEFAULT\fP variable.
.sp
The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option, to specify a target platform
name (architecture).  For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 17 2022\(dq \-A Win32\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 17 2022\(dq \-A x64\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 17 2022\(dq \-A ARM\fP
.IP \(bu 2
\fBcmake \-G \(dqVisual Studio 17 2022\(dq \-A ARM64\fP
.UNINDENT
.SS Toolset Selection
.sp
The \fBv143\fP toolset that comes with VS 17 2022 is selected by default.
The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify another toolset.
.sp
For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32\-bit (\fBx86\fP) and
64\-bit (\fBx64\fP) hosts (independent of the architecture they target).
By default this generator uses the 64\-bit variant on x64 hosts and
the 32\-bit variant otherwise.
One may explicitly request use of either the 32\-bit or 64\-bit host tools
by adding either \fBhost=x86\fP or \fBhost=x64\fP to the toolset specification.
See the \fI\%CMAKE_GENERATOR_TOOLSET\fP variable for details.
.SS Other Generators
.SS Green Hills MULTI
.sp
New in version 3.3.

.sp
New in version 3.15: Linux support.

.sp
Generates Green Hills MULTI project files (experimental, work\-in\-progress).
.INDENT 0.0
.INDENT 3.5
The buildsystem has predetermined build\-configuration settings that can be controlled
via the \fI\%CMAKE_BUILD_TYPE\fP variable.
.UNINDENT
.UNINDENT
.SS Platform Selection
.sp
New in version 3.13.

.sp
The variable \fBGHS_PRIMARY_TARGET\fP can be used to select the target platform.
.INDENT 0.0
.INDENT 3.5
.nf
Sets \fBprimaryTarget\fP entry in project file.
.fi
.sp
.UNINDENT
.UNINDENT
.sp
For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-D GHS_PRIMARY_TARGET=ppc_integrity.tgt\fP
.UNINDENT
.sp
Otherwise the \fBprimaryTarget\fP will be composed from the values of \fI\%CMAKE_GENERATOR_PLATFORM\fP
and \fBGHS_TARGET_PLATFORM\fP\&. Defaulting to the value of \fBarm_integrity.tgt\fP
.INDENT 0.0
.IP \(bu 2
The \fI\%CMAKE_GENERATOR_PLATFORM\fP variable may be set, perhaps
via the \fI\%cmake \-A\fP option.
.nf
Typical values of \fBarm\fP, \fBppc\fP, \fB86\fP, etcetera, are used.
.fi
.sp
.IP \(bu 2
The variable \fBGHS_TARGET_PLATFORM\fP may be set, perhaps via the \fI\%cmake \-D\fP
option.
.nf
Defaults to \fBintegrity\fP\&.
Usual values are \fBintegrity\fP, \fBthreadx\fP, \fBuvelosity\fP, \fBvelosity\fP,
\fBvxworks\fP, \fBstandalone\fP\&.
.fi
.sp
.UNINDENT
.sp
For example:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq\fP for \fBarm_integrity.tgt\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-A 86\fP for \fB86_integrity.tgt\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-D GHS_TARGET_PLATFORM=standalone\fP for \fBarm_standalone.tgt\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-A ppc \-D GHS_TARGET_PLATFORM=standalone\fP for \fBppc_standalone.tgt\fP\&.
.UNINDENT
.SS Toolset Selection
.sp
New in version 3.13.

.sp
The generator searches for the latest compiler or can be given a location to use.
\fBGHS_TOOLSET_ROOT\fP is the directory that is checked for the latest compiler.
.INDENT 0.0
.IP \(bu 2
The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify the location of the toolset.
Both absolute and relative paths are valid. Paths are relative to \fBGHS_TOOLSET_ROOT\fP\&.
.IP \(bu 2
The variable \fBGHS_TOOLSET_ROOT\fP may be set, perhaps via the \fI\%cmake \-D\fP
option.
.nf
Root path for toolset searches and relative paths.
Defaults to \fBC:/ghs\fP in Windows or \fB/usr/ghs\fP in Linux.
.fi
.sp
.UNINDENT
.sp
For example, setting a specific compiler:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-T comp_201754\fP for \fB/usr/ghs/comp_201754\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-T comp_201754 \-D GHS_TOOLSET_ROOT=/opt/ghs\fP for \fB/opt/ghs/comp_201754\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-T /usr/ghs/comp_201554\fP
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-T C:/ghs/comp_201754\fP
.UNINDENT
.sp
For example, searching for latest compiler:
.INDENT 0.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq\fP for searching \fB/usr/ghs\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI \-D GHS_TOOLSET_ROOT=/opt/ghs\(dq\fP for searching \fB/opt/ghs\fP\&.
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
The \fI\%CMAKE_GENERATOR_TOOLSET\fP should use CMake style paths.
.UNINDENT
.UNINDENT
.SS OS and BSP Selection
.sp
New in version 3.3.

.sp
Certain target platforms, like Integrity, require an OS.  The RTOS directory path
can be explicitly set using \fBGHS_OS_DIR\fP\&.  Otherwise \fBGHS_OS_ROOT\fP will be
searched for the latest Integrity RTOS.
.sp
If the target platform, like Integrity, requires a BSP name then it can be set via
the \fBGHS_BSP_NAME\fP variable.
.INDENT 0.0
.IP \(bu 2
\fBGHS_OS_DIR\fP and \fBGHS_OS_DIR_OPTION\fP
.nf
Sets \fB\-os_dir\fP entry in project file.
.fi
.sp
.nf
\fBGHS_OS_DIR_OPTION\fP default value is \fB\-os_dir\fP\&.
.fi
.sp
.sp
New in version 3.15: The \fBGHS_OS_DIR_OPTION\fP variable.

.sp
For example:
.INDENT 2.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-D GHS_OS_DIR=/usr/ghs/int1144\fP
.UNINDENT
.IP \(bu 2
\fBGHS_OS_ROOT\fP
.nf
Root path for RTOS searches.
Defaults to \fBC:/ghs\fP in Windows or \fB/usr/ghs\fP in Linux.
.fi
.sp
.sp
For example:
.INDENT 2.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-D GHS_OS_ROOT=/opt/ghs\fP
.UNINDENT
.IP \(bu 2
\fBGHS_BSP_NAME\fP
.nf
Sets \fB\-bsp\fP entry in project file.
Defaults to \fBsim<arch>\fP for \fBintegrity\fP platforms.
.fi
.sp
.sp
For example:
.INDENT 2.0
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq\fP for \fBsimarm\fP on \fBarm_integrity.tgt\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-A 86\fP for \fBsim86\fP on \fB86_integrity.tgt\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-A ppc \-D GHS_BSP_NAME=sim800\fP for \fBsim800\fP
on \fBppc_integrity.tgt\fP\&.
.IP \(bu 2
\fBcmake \-G \(dqGreen Hills MULTI\(dq \-D GHS_PRIMARY_TARGET=ppc_integrity.tgt \-D GHS_BSP_NAME=fsl\-t1040\fP
for \fBfsl\-t1040\fP on \fBppc_integrity.tgt\fP\&.
.UNINDENT
.UNINDENT
.SS Target Properties
.sp
New in version 3.14.

.sp
The following properties are available:
.INDENT 0.0
.IP \(bu 2
\fI\%GHS_INTEGRITY_APP\fP
.IP \(bu 2
\fI\%GHS_NO_SOURCE_GROUP_FILE\fP
.UNINDENT
.SS MULTI Project Variables
.sp
New in version 3.3.

.sp
Adding a Customization file and macros are available through the use of the following
variables:
.INDENT 0.0
.IP \(bu 2
\fBGHS_CUSTOMIZATION\fP \- CMake path name to Customization File.
.IP \(bu 2
\fBGHS_GPJ_MACROS\fP \- CMake list of Macros.
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
This generator is deemed experimental as of CMake 3.29.0\-rc3
and is still a work in progress.  Future versions of CMake
may make breaking changes as the generator matures.
.UNINDENT
.UNINDENT
.SS Xcode
.sp
Generate Xcode project files.
.sp
Changed in version 3.15: This generator supports Xcode 5.0 and above.

.SS Toolset and Build System Selection
.sp
By default Xcode is allowed to select its own default toolchain.
The \fI\%CMAKE_GENERATOR_TOOLSET\fP option may be set, perhaps
via the \fI\%cmake \-T\fP option, to specify another toolset.
.sp
New in version 3.19: This generator supports toolset specification using one of these forms:

.INDENT 0.0
.IP \(bu 2
\fBtoolset\fP
.IP \(bu 2
\fBtoolset[,key=value]*\fP
.IP \(bu 2
\fBkey=value[,key=value]*\fP
.UNINDENT
.sp
The \fBtoolset\fP specifies the toolset name.  The selected toolset name
is provided in the \fI\%CMAKE_XCODE_PLATFORM_TOOLSET\fP variable.
.sp
The \fBkey=value\fP pairs form a comma\-separated list of options to
specify generator\-specific details of the toolset selection.
Supported pairs are:
.INDENT 0.0
.TP
.B \fBbuildsystem=<variant>\fP
Specify the buildsystem variant to use.
See the \fI\%CMAKE_XCODE_BUILD_SYSTEM\fP variable for allowed values.
.sp
For example, to select the original build system under Xcode 12,
run \fI\%cmake(1)\fP with the option \fI\%\-T buildsystem=1\fP\&.
.UNINDENT
.SS Swift Support
.sp
New in version 3.4.

.sp
When using the \fBXcode\fP generator with Xcode 6.1 or higher,
one may enable the \fBSwift\fP language with the \fI\%enable_language()\fP
command or the \fI\%project()\fP\&.
.SS Limitations
.sp
The Xcode generator does not support per\-configuration sources.
Code like the following will result in a generation error:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
add_executable(MyApp mymain\-$<CONFIG>.cpp)
.ft P
.fi
.UNINDENT
.UNINDENT
.SH EXTRA GENERATORS
.sp
Deprecated since version 3.27: Support for \(dqExtra Generators\(dq is deprecated and will be removed from
a future version of CMake.  IDEs may use the \fI\%cmake\-file\-api(7)\fP
to view CMake\-generated project build trees.

.sp
Some of the \fI\%CMake Generators\fP listed in the \fI\%cmake(1)\fP
command\-line tool \fI\%\-\-help\fP output may have
variants that specify an extra generator for an auxiliary IDE tool.
Such generator names have the form \fB<extra\-generator> \- <main\-generator>\fP\&.
The following extra generators are known to CMake.
.SS CodeBlocks
.sp
Deprecated since version 3.27: Support for \fI\%Extra Generators\fP is deprecated and will be removed from
a future version of CMake.  IDEs may use the \fI\%cmake\-file\-api(7)\fP
to view CMake\-generated project build trees.

.sp
Generates CodeBlocks project files.
.sp
Project files for CodeBlocks will be created in the top directory and
in every subdirectory which features a \fBCMakeLists.txt\fP file containing
a \fI\%project()\fP call.  Additionally a hierarchy of makefiles is generated
into the build tree.
The appropriate make program can build the
project through the default \fBall\fP target.  An \fBinstall\fP target is
also provided.
.sp
New in version 3.10: The \fI\%CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES\fP variable may
be set to \fBON\fP to exclude any files which are located outside of
the project root directory.

.sp
This \(dqextra\(dq generator may be specified as:
.INDENT 0.0
.TP
.B \fBCodeBlocks \- MinGW Makefiles\fP
Generate with \fI\%MinGW Makefiles\fP\&.
.TP
.B \fBCodeBlocks \- NMake Makefiles\fP
Generate with \fI\%NMake Makefiles\fP\&.
.TP
.B \fBCodeBlocks \- NMake Makefiles JOM\fP
New in version 3.8: Generate with \fI\%NMake Makefiles JOM\fP\&.

.TP
.B \fBCodeBlocks \- Ninja\fP
Generate with \fI\%Ninja\fP\&.
.TP
.B \fBCodeBlocks \- Unix Makefiles\fP
Generate with \fI\%Unix Makefiles\fP\&.
.UNINDENT
.SS CodeLite
.sp
Deprecated since version 3.27: Support for \fI\%Extra Generators\fP is deprecated and will be removed from
a future version of CMake.  IDEs may use the \fI\%cmake\-file\-api(7)\fP
to view CMake\-generated project build trees.

.sp
Generates CodeLite project files.
.sp
Project files for CodeLite will be created in the top directory and
in every subdirectory which features a CMakeLists.txt file containing
a \fI\%project()\fP call.
The appropriate make program can build the
project through the default \fBall\fP target.  An \fBinstall\fP target
is also provided.
.sp
New in version 3.7: The \fI\%CMAKE_CODELITE_USE_TARGETS\fP variable may be set to \fBON\fP
to change the default behavior from projects to targets as the basis
for project files.

.sp
This \(dqextra\(dq generator may be specified as:
.INDENT 0.0
.TP
.B \fBCodeLite \- MinGW Makefiles\fP
Generate with \fI\%MinGW Makefiles\fP\&.
.TP
.B \fBCodeLite \- NMake Makefiles\fP
Generate with \fI\%NMake Makefiles\fP\&.
.TP
.B \fBCodeLite \- Ninja\fP
Generate with \fI\%Ninja\fP\&.
.TP
.B \fBCodeLite \- Unix Makefiles\fP
Generate with \fI\%Unix Makefiles\fP\&.
.UNINDENT
.SS Eclipse CDT4
.sp
Deprecated since version 3.27: Support for \fI\%Extra Generators\fP is deprecated and will be removed from
a future version of CMake.  IDEs may use the \fI\%cmake\-file\-api(7)\fP
to view CMake\-generated project build trees.

.sp
Generates Eclipse CDT 4.0 project files.
.sp
Project files for Eclipse will be created in the top directory.  In
out of source builds, a linked resource to the top level source
directory will be created.  Additionally a hierarchy of makefiles is
generated into the build tree.  The appropriate make program can build
the project through the default \fBall\fP target.  An \fBinstall\fP target
is also provided.
.sp
This \(dqextra\(dq generator may be specified as:
.INDENT 0.0
.TP
.B \fBEclipse CDT4 \- MinGW Makefiles\fP
Generate with \fI\%MinGW Makefiles\fP\&.
.TP
.B \fBEclipse CDT4 \- NMake Makefiles\fP
Generate with \fI\%NMake Makefiles\fP\&.
.TP
.B \fBEclipse CDT4 \- Ninja\fP
Generate with \fI\%Ninja\fP\&.
.TP
.B \fBEclipse CDT4 \- Unix Makefiles\fP
Generate with \fI\%Unix Makefiles\fP\&.
.UNINDENT
.SS Kate
.sp
Deprecated since version 3.27: Support for \fI\%Extra Generators\fP is deprecated and will be removed from
a future version of CMake.  IDEs may use the \fI\%cmake\-file\-api(7)\fP
to view CMake\-generated project build trees.

.sp
Generates Kate project files.
.sp
A project file for Kate will be created in the top directory in the top level
build directory.
To use it in Kate, the Project plugin must be enabled.
The project file is loaded in Kate by opening the
\fBProjectName.kateproject\fP file in the editor.
If the Kate Build\-plugin is enabled, all targets generated by CMake are
available for building.
.sp
This \(dqextra\(dq generator may be specified as:
.INDENT 0.0
.TP
.B \fBKate \- MinGW Makefiles\fP
Generate with \fI\%MinGW Makefiles\fP\&.
.TP
.B \fBKate \- NMake Makefiles\fP
Generate with \fI\%NMake Makefiles\fP\&.
.TP
.B \fBKate \- Ninja\fP
Generate with \fI\%Ninja\fP\&.
.TP
.B \fBKate \- Ninja Multi\-Config\fP
Generate with \fI\%Ninja Multi\-Config\fP\&.
.TP
.B \fBKate \- Unix Makefiles\fP
Generate with \fI\%Unix Makefiles\fP\&.
.UNINDENT
.SS Sublime Text 2
.sp
Deprecated since version 3.27: Support for \fI\%Extra Generators\fP is deprecated and will be removed from
a future version of CMake.  IDEs may use the \fI\%cmake\-file\-api(7)\fP
to view CMake\-generated project build trees.

.sp
Generates Sublime Text 2 project files.
.sp
Project files for Sublime Text 2 will be created in the top directory
and in every subdirectory which features a \fBCMakeLists.txt\fP file
containing a \fI\%project()\fP call.  Additionally \fBMakefiles\fP
(or \fBbuild.ninja\fP files) are generated into the build tree.
The appropriate make program can build the project through the default \fBall\fP
target.  An \fBinstall\fP target is also provided.
.sp
This \(dqextra\(dq generator may be specified as:
.INDENT 0.0
.TP
.B \fBSublime Text 2 \- MinGW Makefiles\fP
Generate with \fI\%MinGW Makefiles\fP\&.
.TP
.B \fBSublime Text 2 \- NMake Makefiles\fP
Generate with \fI\%NMake Makefiles\fP\&.
.TP
.B \fBSublime Text 2 \- Ninja\fP
Generate with \fI\%Ninja\fP\&.
.TP
.B \fBSublime Text 2 \- Unix Makefiles\fP
Generate with \fI\%Unix Makefiles\fP\&.
.UNINDENT
.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-LANGUAGE" "7" "Mar 04, 2024" "3.29.0" "CMake"
.SH NAME
cmake-language \- CMake Language Reference
.SH ORGANIZATION
.sp
CMake input files are written in the \(dqCMake Language\(dq in source files
named \fBCMakeLists.txt\fP or ending in a \fB\&.cmake\fP file name extension.
.sp
CMake Language source files in a project are organized into:
.INDENT 0.0
.IP \(bu 2
\fI\%Directories\fP (\fBCMakeLists.txt\fP),
.IP \(bu 2
\fI\%Scripts\fP (\fB<script>.cmake\fP), and
.IP \(bu 2
\fI\%Modules\fP (\fB<module>.cmake\fP).
.UNINDENT
.SS Directories
.sp
When CMake processes a project source tree, the entry point is
a source file called \fBCMakeLists.txt\fP in the top\-level source
directory.  This file may contain the entire build specification
or use the \fI\%add_subdirectory()\fP command to add subdirectories
to the build.  Each subdirectory added by the command must also
contain a \fBCMakeLists.txt\fP file as the entry point to that
directory.  For each source directory whose \fBCMakeLists.txt\fP file
is processed CMake generates a corresponding directory in the build
tree to act as the default working and output directory.
.SS Scripts
.sp
An individual \fB<script>.cmake\fP source file may be processed
in \fIscript mode\fP by using the \fI\%cmake(1)\fP command\-line tool
with the \fI\%\-P\fP 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.
.SS Modules
.sp
CMake Language code in either \fI\%Directories\fP or \fI\%Scripts\fP may
use the \fI\%include()\fP command to load a \fB<module>.cmake\fP
source file in the scope of the including context.
See the \fI\%cmake\-modules(7)\fP 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 \fI\%CMAKE_MODULE_PATH\fP
variable.
.SH SYNTAX
.SS Encoding
.sp
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 \fB\en\fP or \fB\er\en\fP but will be converted to \fB\en\fP
as input files are read.
.sp
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
\fI\%Byte\-Order Mark\fP in source files.
.SS Source Files
.sp
A CMake Language source file consists of zero or more
\fI\%Command Invocations\fP separated by newlines and optionally
spaces and \fI\%Comments\fP:
.sp
.nf
\fBfile        \fP ::=  \fI\%file_element\fP*
\fBfile_element\fP ::=  \fI\%command_invocation\fP \fI\%line_ending\fP |
                  (\fI\%bracket_comment\fP|\fI\%space\fP)* \fI\%line_ending\fP
\fBline_ending \fP ::=  \fI\%line_comment\fP? \fI\%newline\fP
\fBspace       \fP ::=  <match \(aq[ \et]+\(aq>
\fBnewline     \fP ::=  <match \(aq\en\(aq>

.fi
.sp
Note that any source file line not inside \fI\%Command Arguments\fP or
a \fI\%Bracket Comment\fP can end in a \fI\%Line Comment\fP\&.
.SS Command Invocations
.sp
A \fIcommand invocation\fP is a name followed by paren\-enclosed arguments
separated by whitespace:
.sp
.nf
\fBcommand_invocation \fP ::=  \fI\%space\fP* \fI\%identifier\fP \fI\%space\fP* \(aq(\(aq \fI\%arguments\fP \(aq)\(aq
\fBidentifier         \fP ::=  <match \(aq[A\-Za\-z_][A\-Za\-z0\-9_]*\(aq>
\fBarguments          \fP ::=  \fI\%argument\fP? \fI\%separated_arguments\fP*
\fBseparated_arguments\fP ::=  \fI\%separation\fP+ \fI\%argument\fP? |
                         \fI\%separation\fP* \(aq(\(aq \fI\%arguments\fP \(aq)\(aq
\fBseparation         \fP ::=  \fI\%space\fP | \fI\%line_ending\fP

.fi
.sp
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
add_executable(hello world.c)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Command names are case\-insensitive.
Nested unquoted parentheses in the arguments must balance.
Each \fB(\fP or \fB)\fP is given to the command invocation as
a literal \fI\%Unquoted Argument\fP\&.  This may be used in calls
to the \fI\%if()\fP command to enclose conditions.
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
if(FALSE AND (FALSE OR TRUE)) # evaluates to FALSE
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
CMake versions prior to 3.0 require command name identifiers
to be at least 2 characters.
.sp
CMake versions prior to 2.8.12 silently accept an \fI\%Unquoted Argument\fP
or a \fI\%Quoted Argument\fP immediately following a \fI\%Quoted Argument\fP and
not separated by any whitespace.  For compatibility, CMake 2.8.12 and
higher accept such code but produce a warning.
.UNINDENT
.UNINDENT
.SS Command Arguments
.sp
There are three types of arguments within \fI\%Command Invocations\fP:
.sp
.nf
\fBargument\fP ::=  \fI\%bracket_argument\fP | \fI\%quoted_argument\fP | \fI\%unquoted_argument\fP

.fi
.SS Bracket Argument
.sp
A \fIbracket argument\fP, inspired by \fI\%Lua\fP long bracket syntax,
encloses content between opening and closing \(dqbrackets\(dq of the
same length:
.sp
.nf
\fBbracket_argument\fP ::=  \fI\%bracket_open\fP \fI\%bracket_content\fP \fI\%bracket_close\fP
\fBbracket_open    \fP ::=  \(aq[\(aq \(aq=\(aq* \(aq[\(aq
\fBbracket_content \fP ::=  <any text not containing a \fI\%bracket_close\fP with
                       the same number of \(aq=\(aq as the \fI\%bracket_open\fP>
\fBbracket_close   \fP ::=  \(aq]\(aq \(aq=\(aq* \(aq]\(aq

.fi
.sp
An opening bracket is written \fB[\fP followed by zero or more \fB=\fP followed
by \fB[\fP\&.  The corresponding closing bracket is written \fB]\fP followed
by the same number of \fB=\fP followed by \fB]\fP\&.
Brackets do not nest.  A unique length may always be chosen
for the opening and closing brackets to contain closing brackets
of other lengths.
.sp
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 \fI\%Escape Sequences\fP or \fI\%Variable References\fP,
is performed.  A bracket argument is always given to the command
invocation as exactly one argument.
.sp
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
message([=[
This is the first line in a bracket argument with bracket length 1.
No \e\-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.
]=])
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
CMake versions prior to 3.0 do not support bracket arguments.
They interpret the opening bracket as the start of an
\fI\%Unquoted Argument\fP\&.
.UNINDENT
.UNINDENT
.SS Quoted Argument
.sp
A \fIquoted argument\fP encloses content between opening and closing
double\-quote characters:
.sp
.nf
\fBquoted_argument    \fP ::=  \(aq\(dq\(aq \fI\%quoted_element\fP* \(aq\(dq\(aq
\fBquoted_element     \fP ::=  <any character except \(aq\e\(aq or \(aq\(dq\(aq> |
                         \fI\%escape_sequence\fP |
                         \fI\%quoted_continuation\fP
\fBquoted_continuation\fP ::=  \(aq\e\(aq \fI\%newline\fP

.fi
.sp
Quoted argument content consists of all text between opening and
closing quotes.  Both \fI\%Escape Sequences\fP and \fI\%Variable References\fP
are evaluated.  A quoted argument is always given to the command
invocation as exactly one argument.
.sp
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
message(\(dqThis is a quoted argument containing multiple lines.
This is always one argument even though it contains a ; character.
Both \e\e\-escape sequences and ${variable} references are evaluated.
The text does not end on an escaped double\-quote like \e\(dq.
It does end in an unescaped double quote.
\(dq)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
The final \fB\e\fP 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:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
message(\(dq\e
This is the first line of a quoted argument. \e
In fact it is the only line but since it is long \e
the source code uses line continuation.\e
\(dq)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
CMake versions prior to 3.0 do not support continuation with \fB\e\fP\&.
They report errors in quoted arguments containing lines ending in
an odd number of \fB\e\fP characters.
.UNINDENT
.UNINDENT
.SS Unquoted Argument
.sp
An \fIunquoted argument\fP is not enclosed by any quoting syntax.
It may not contain any whitespace, \fB(\fP, \fB)\fP, \fB#\fP, \fB\(dq\fP, or \fB\e\fP
except when escaped by a backslash:
.sp
.nf
\fBunquoted_argument\fP ::=  \fI\%unquoted_element\fP+ | \fI\%unquoted_legacy\fP
\fBunquoted_element \fP ::=  <any character except whitespace or one of \(aq()#\(dq\e\(aq> |
                       \fI\%escape_sequence\fP
\fBunquoted_legacy  \fP ::=  <see note in text>

.fi
.sp
Unquoted argument content consists of all text in a contiguous block
of allowed or escaped characters.  Both \fI\%Escape Sequences\fP and
\fI\%Variable References\fP are evaluated.  The resulting value is divided
in the same way \fI\%Lists\fP 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.
.sp
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
foreach(arg
    NoSpace
    Escaped\e Space
    This;Divides;Into;Five;Arguments
    Escaped\e;Semicolon
    )
  message(\(dq${arg}\(dq)
endforeach()
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
To support legacy CMake code, unquoted arguments may also contain
double\-quoted strings (\fB\(dq...\(dq\fP, possibly enclosing horizontal
whitespace), and make\-style variable references (\fB$(MAKEVAR)\fP).
.sp
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 \fB\-Da=\(dqb c\(dq\fP,
\fB\-Da=$(v)\fP, and \fBa\(dq \(dqb\(dqc\(dqd\fP are each interpreted literally.
They may instead be written as quoted arguments \fB\(dq\-Da=\e\(dqb c\e\(dq\(dq\fP,
\fB\(dq\-Da=$(v)\(dq\fP, and \fB\(dqa\e\(dq \e\(dqb\e\(dqc\e\(dqd\(dq\fP, respectively.
.sp
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 \fB$\fP, \fB(\fP,
\fBMAKEVAR\fP, and \fB)\fP arguments).
.sp
The above \(dqunquoted_legacy\(dq production represents such arguments.
We do not recommend using legacy unquoted arguments in new code.
Instead use a \fI\%Quoted Argument\fP or a \fI\%Bracket Argument\fP to
represent the content.
.UNINDENT
.UNINDENT
.SS Escape Sequences
.sp
An \fIescape sequence\fP is a \fB\e\fP followed by one character:
.sp
.nf
\fBescape_sequence \fP ::=  \fI\%escape_identity\fP | \fI\%escape_encoded\fP | \fI\%escape_semicolon\fP
\fBescape_identity \fP ::=  \(aq\e\(aq <match \(aq[^A\-Za\-z0\-9;]\(aq>
\fBescape_encoded  \fP ::=  \(aq\et\(aq | \(aq\er\(aq | \(aq\en\(aq
\fBescape_semicolon\fP ::=  \(aq\e;\(aq

.fi
.sp
A \fB\e\fP followed by a non\-alphanumeric character simply encodes the literal
character without interpreting it as syntax.  A \fB\et\fP, \fB\er\fP, or \fB\en\fP
encodes a tab, carriage return, or newline character, respectively. A \fB\e;\fP
outside of any \fI\%Variable References\fP  encodes itself but may be used in an
\fI\%Unquoted Argument\fP to encode the \fB;\fP without dividing the argument
value on it.  A \fB\e;\fP inside \fI\%Variable References\fP encodes the literal
\fB;\fP character.  (See also policy \fI\%CMP0053\fP documentation for
historical considerations.)
.SS Variable References
.sp
A \fIvariable reference\fP has the form \fB${<variable>}\fP and is
evaluated inside a \fI\%Quoted Argument\fP or an \fI\%Unquoted Argument\fP\&.
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. \fB${outer_${inner_variable}_variable}\fP\&.
.sp
Literal variable references may consist of alphanumeric characters,
the characters \fB/_.+\-\fP, and \fI\%Escape Sequences\fP\&.  Nested references
may be used to evaluate variables of any name.  See also policy
\fI\%CMP0053\fP documentation for historical considerations and reasons why
the \fB$\fP is also technically permitted but is discouraged.
.sp
The \fI\%Variables\fP section documents the scope of variable names
and how their values are set.
.sp
An \fIenvironment variable reference\fP has the form \fB$ENV{<variable>}\fP\&.
See the \fI\%Environment Variables\fP section for more information.
.sp
A \fIcache variable reference\fP has the form \fB$CACHE{<variable>}\fP,
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 \fI\%CACHE\fP for more information.
.sp
The \fI\%if()\fP command has a special condition syntax that
allows for variable references in the short form \fB<variable>\fP
instead of \fB${<variable>}\fP\&.  However, environment variables
always need to be referenced as \fB$ENV{<variable>}\fP\&.
.SS Comments
.sp
A comment starts with a \fB#\fP character that is not inside a
\fI\%Bracket Argument\fP, \fI\%Quoted Argument\fP, or escaped with \fB\e\fP
as part of an \fI\%Unquoted Argument\fP\&.  There are two types of
comments: a \fI\%Bracket Comment\fP and a \fI\%Line Comment\fP\&.
.SS Bracket Comment
.sp
A \fB#\fP immediately followed by a \fI\%bracket_open\fP forms a
\fIbracket comment\fP consisting of the entire bracket enclosure:
.sp
.nf
\fBbracket_comment\fP ::=  \(aq#\(aq \fI\%bracket_argument\fP

.fi
.sp
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
#[[This is a bracket comment.
It runs until the close bracket.]]
message(\(dqFirst Argument\en\(dq #[[Bracket Comment]] \(dqSecond Argument\(dq)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
CMake versions prior to 3.0 do not support bracket comments.
They interpret the opening \fB#\fP as the start of a \fI\%Line Comment\fP\&.
.UNINDENT
.UNINDENT
.SS Line Comment
.sp
A \fB#\fP not immediately followed by a \fI\%bracket_open\fP forms a
\fIline comment\fP that runs until the end of the line:
.sp
.nf
\fBline_comment\fP ::=  \(aq#\(aq <any text not starting in a \fI\%bracket_open\fP
                       and not containing a \fI\%newline\fP>

.fi
.sp
For example:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
# This is a line comment.
message(\(dqFirst Argument\en\(dq # This is a line comment :)
        \(dqSecond Argument\(dq) # This is a line comment.
.ft P
.fi
.UNINDENT
.UNINDENT
.SH CONTROL STRUCTURES
.SS Conditional Blocks
.sp
The \fI\%if()\fP/\fI\%elseif()\fP/\fI\%else()\fP/\fI\%endif()\fP
commands delimit code blocks to be executed conditionally.
.SS Loops
.sp
The \fI\%foreach()\fP/\fI\%endforeach()\fP and
\fI\%while()\fP/\fI\%endwhile()\fP commands delimit code
blocks to be executed in a loop.  Inside such blocks the
\fI\%break()\fP command may be used to terminate the loop
early whereas the \fI\%continue()\fP command may be used
to start with the next iteration immediately.
.SS Command Definitions
.sp
The \fI\%macro()\fP/\fI\%endmacro()\fP, and
\fI\%function()\fP/\fI\%endfunction()\fP commands delimit
code blocks to be recorded for later invocation as commands.
.SH VARIABLES
.sp
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 \fI\%set()\fP and \fI\%unset()\fP 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 \fB_\fP and \fB\-\fP\&.
.sp
Variables have dynamic scope.  Each variable \(dqset\(dq or \(dqunset\(dq
creates a binding in the current scope:
.INDENT 0.0
.TP
.B Block Scope
The \fI\%block()\fP command may create a new scope for variable bindings.
.TP
.B Function Scope
\fI\%Command Definitions\fP created by the \fI\%function()\fP command
create commands that, when invoked, process the recorded commands
in a new variable binding scope.  A variable \(dqset\(dq or \(dqunset\(dq
binds in this scope and is visible for the current function and
any nested calls within it, but not after the function returns.
.TP
.B Directory Scope
Each of the \fI\%Directories\fP in a source tree has its own variable
bindings.  Before processing the \fBCMakeLists.txt\fP file for a
directory, CMake copies all variable bindings currently defined
in the parent directory, if any, to initialize the new directory
scope.  CMake \fI\%Scripts\fP, when processed with \fI\%cmake \-P\fP,
bind variables in one \(dqdirectory\(dq scope.
.sp
A variable \(dqset\(dq or \(dqunset\(dq not inside a function call binds
to the current directory scope.
.TP
.B Persistent Cache
CMake stores a separate set of \(dqcache\(dq variables, or \(dqcache entries\(dq,
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 \fBCACHE\fP option of the
\fI\%set()\fP and \fI\%unset()\fP commands.
.UNINDENT
.sp
When evaluating \fI\%Variable References\fP, 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
\(dqset\(dq binding is found, its value is used.  If an \(dqunset\(dq 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 \fB$CACHE{VAR}\fP syntax can be used to do direct cache entry
lookups.
.sp
The \fI\%cmake\-variables(7)\fP manual documents the many variables
that are provided by CMake or have meaning to CMake when set
by project code.
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
CMake reserves identifiers that:
.INDENT 0.0
.IP \(bu 2
begin with \fBCMAKE_\fP (upper\-, lower\-, or mixed\-case), or
.IP \(bu 2
begin with \fB_CMAKE_\fP (upper\-, lower\-, or mixed\-case), or
.IP \(bu 2
begin with \fB_\fP followed by the name of any \fI\%CMake Command\fP\&.
.UNINDENT
.UNINDENT
.UNINDENT
.SH ENVIRONMENT VARIABLES
.sp
Environment Variables are like ordinary \fI\%Variables\fP, with the
following differences:
.INDENT 0.0
.TP
.B Scope
Environment variables have global scope in a CMake process.
They are never cached.
.TP
.B References
\fI\%Variable References\fP have the form \fB$ENV{<variable>}\fP, using the
\fI\%ENV\fP operator.
.TP
.B Initialization
Initial values of the CMake environment variables are those of
the calling process.
Values can be changed using the \fI\%set()\fP and \fI\%unset()\fP
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.
.sp
See the \fI\%cmake \-E env\fP command\-line
tool to run a command in a modified environment.
.TP
.B Inspection
See the \fI\%cmake \-E environment\fP command\-line
tool to display all current environment variables.
.UNINDENT
.sp
The \fI\%cmake\-env\-variables(7)\fP manual documents environment
variables that have special meaning to CMake.
.SH LISTS
.sp
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 \fI\%Unquoted Argument\fP\&.  In such contexts, a string
is divided into list elements by splitting on \fB;\fP characters not
following an unequal number of \fB[\fP and \fB]\fP characters and not
immediately preceded by a \fB\e\fP\&.  The sequence \fB\e;\fP does not
divide a value but is replaced by \fB;\fP in the resulting element.
.sp
A list of elements is represented as a string by concatenating
the elements separated by \fB;\fP\&.  For example, the \fI\%set()\fP
command stores multiple values into the destination variable
as a list:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(srcs a.c b.c c.c) # sets \(dqsrcs\(dq to \(dqa.c;b.c;c.c\(dq
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
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 \fB;\fP characters
in list elements, thus flattening nested lists:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
set(x a \(dqb;c\(dq) # sets \(dqx\(dq to \(dqa;b;c\(dq, not \(dqa;b\e;c\(dq
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
In general, lists do not support elements containing \fB;\fP characters.
To avoid problems, consider the following advice:
.INDENT 0.0
.IP \(bu 2
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.
.IP \(bu 2
When constructing a list, substitute an otherwise\-unused placeholder
for \fB;\fP in elements when.  Then substitute \fB;\fP for the placeholder
when processing list elements.
For example, the following code uses \fB|\fP in place of \fB;\fP characters:
.INDENT 2.0
.INDENT 3.5
.sp
.nf
.ft C
set(mylist a \(dqb|c\(dq)
foreach(entry IN LISTS mylist)
  string(REPLACE \(dq|\(dq \(dq;\(dq entry \(dq${entry}\(dq)
  # use \(dq${entry}\(dq normally
endforeach()
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
The \fI\%ExternalProject\fP module\(aqs \fBLIST_SEPARATOR\fP option is an
example of an interface built using this approach.
.IP \(bu 2
In lists of \fI\%generator expressions\fP,
use the \fI\%$<SEMICOLON>\fP generator expression.
.IP \(bu 2
In command calls, use \fI\%Quoted Argument\fP syntax whenever possible.
The called command will receive the content of the argument with
semicolons preserved.  An \fI\%Unquoted Argument\fP will be split on
semicolons.
.IP \(bu 2
In \fI\%function()\fP implementations, avoid \fBARGV\fP and \fBARGN\fP,
which do not distinguish semicolons in values from those separating values.
Instead, prefer using named positional arguments and the \fBARGC\fP and
\fBARGV#\fP variables.
When using \fI\%cmake_parse_arguments()\fP to parse arguments, prefer
its \fBPARSE_ARGV\fP signature, which uses the \fBARGV#\fP variables.
.sp
Note that this approach does not apply to \fI\%macro()\fP implementations
because they reference arguments using placeholders, not real variables.
.UNINDENT
.SH COPYRIGHT
2000-2024 Kitware, Inc. and Contributors
.\" Generated by docutils manpage writer.
.

repo_name: lazytadpole/codenamesilverfish

license: mit