code:
CMAKE_<LANG>_COMPILER_LAUNCHER
------------------------------

.. versionadded:: 3.17

.. include:: ENV_VAR.txt

Default compiler launcher to use for the specified language. Will only be used
by CMake to initialize the variable on the first configuration. Afterwards, it
is available through the cache setting of the variable of the same name. For
any configuration run (including the first), the environment variable will be
ignored if the :variable:`CMAKE_<LANG>_COMPILER_LAUNCHER` variable is defined.


code:
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES_EXCLUDE
----------------------------------------------

.. versionadded:: 3.27

.. include:: ENV_VAR.txt

A :ref:`semicolon-separated list <CMake Language Lists>` of directories
to exclude from the :variable:`CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES`
variable when it is automatically detected from the ``<LANG>`` compiler.

This may be used to work around misconfigured compiler drivers that pass
extraneous implicit link directories to their linker.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
CMAKE_<LANG>_LINKER_LAUNCHER
----------------------------

.. versionadded:: 3.21

.. include:: ENV_VAR.txt

Default launcher to use when linking a target of the specified language. Will
only be used by CMake to initialize the variable on the first configuration.
Afterwards, it is available through the cache setting of the variable of the
same name. For any configuration run (including the first), the environment
variable will be ignored if the :variable:`CMAKE_<LANG>_LINKER_LAUNCHER`
variable is defined.


code:
CMAKE_LIBRARY_PATH
------------------

.. include:: ENV_VAR.txt

The ``CMAKE_LIBRARY_PATH`` environment variable may be set to a list of
directories to be searched by the :command:`find_library` command.

This variable may hold a single directory or a list of directories separated
by ``:`` on UNIX or ``;`` on Windows (the same as the ``PATH`` environment
variable convention on those platforms).

See also the :variable:`CMAKE_LIBRARY_PATH` CMake variable.


code:
CMAKE_MAXIMUM_RECURSION_DEPTH
-----------------------------

.. versionadded:: 3.27

.. include:: ENV_VAR.txt

Maximum recursion depth for CMake scripts.  This environment variable is
used if the :variable:`CMAKE_MAXIMUM_RECURSION_DEPTH` variable is not set.
See that variable's documentation for details.


code:
CMAKE_MSVCIDE_RUN_PATH
----------------------

.. include:: ENV_VAR.txt

Extra PATH locations for custom commands when using
:generator:`Visual Studio 9 2008` (or above) generators.

The ``CMAKE_MSVCIDE_RUN_PATH`` environment variable sets the default value for
the :variable:`CMAKE_MSVCIDE_RUN_PATH` variable if not already explicitly set.


code:
CMAKE_NO_VERBOSE
----------------

.. versionadded:: 3.14

Disables verbose output from CMake when :envvar:`VERBOSE` environment variable
is set.

Only your build tool of choice will still print verbose output when you start
to actually build your project.


code:
CMAKE_OSX_ARCHITECTURES
-----------------------

.. include:: ENV_VAR.txt

Target specific architectures for macOS.

The ``CMAKE_OSX_ARCHITECTURES`` environment variable sets the default value for
the :variable:`CMAKE_OSX_ARCHITECTURES` variable. See
:prop_tgt:`OSX_ARCHITECTURES` for more information.


code:
CMAKE_PREFIX_PATH
-----------------

.. include:: ENV_VAR.txt

The ``CMAKE_PREFIX_PATH`` environment variable may be set to a list of
directories specifying installation *prefixes* to be searched by the
:command:`find_package`, :command:`find_program`, :command:`find_library`,
:command:`find_file`, and :command:`find_path` commands.  Each command will
add appropriate subdirectories (like ``bin``, ``lib``, or ``include``)
as specified in its own documentation.

This variable may hold a single prefix or a list of prefixes separated
by ``:`` on UNIX or ``;`` on Windows (the same as the ``PATH`` environment
variable convention on those platforms).

See also the :variable:`CMAKE_PREFIX_PATH` CMake variable.


code:
CMAKE_PROGRAM_PATH
------------------

.. include:: ENV_VAR.txt

The ``CMAKE_PROGRAM_PATH`` environment variable may be set to a list of
directories to be searched by the :command:`find_program` command.

This variable may hold a single directory or a list of directories separated
by ``:`` on UNIX or ``;`` on Windows (the same as the ``PATH`` environment
variable convention on those platforms).

See also the :variable:`CMAKE_PROGRAM_PATH` CMake variable.


code:
CMAKE_TEST_LAUNCHER
-------------------

.. versionadded:: 3.29

.. include:: ENV_VAR.txt

The default value for the :variable:`CMAKE_TEST_LAUNCHER` variable when there
is no explicit configuration given on the first run while creating a new
build tree.  On later runs in an existing build tree the value persists in
the cache as :variable:`CMAKE_TEST_LAUNCHER`.


code:
CMAKE_TOOLCHAIN_FILE
--------------------

.. versionadded:: 3.21

.. include:: ENV_VAR.txt

The ``CMAKE_TOOLCHAIN_FILE`` environment variable specifies a default value
for the :variable:`CMAKE_TOOLCHAIN_FILE` variable when there is no explicit
configuration given on the first run while creating a new build tree.
On later runs in an existing build tree the value persists in the cache
as :variable:`CMAKE_TOOLCHAIN_FILE`.


code:
CSFLAGS
-------

.. versionadded:: 3.9.2

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``CSharp`` files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_CSharp_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``CSharp``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_CSharp_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
CTEST_INTERACTIVE_DEBUG_MODE
----------------------------

.. include:: ENV_VAR.txt

Environment variable that will exist and be set to ``1`` when a test executed
by :manual:`ctest(1)` is run in interactive mode.


code:
CTEST_NO_TESTS_ACTION
---------------------

.. versionadded:: 3.26

.. include:: ENV_VAR.txt

Environment variable that controls how :manual:`ctest <ctest(1)>` handles
cases when there are no tests to run. Possible values are: ``error``,
``ignore``, empty or unset.

The :option:`--no-tests=\<action\> <ctest --no-tests>` option to
:manual:`ctest <ctest(1)>` overrides this environment variable if both
are given.


code:
CTEST_OUTPUT_ON_FAILURE
-----------------------

.. include:: ENV_VAR.txt

Boolean environment variable that controls if the output should be logged for
failed tests. Set the value to ``1``, ``True``, or ``ON`` to enable output on failure.
See :manual:`ctest(1)` for more information on controlling output of failed
tests.


code:
CTEST_PARALLEL_LEVEL
--------------------

.. include:: ENV_VAR.txt

Specify the number of tests for CTest to run in parallel.
For example, if ``CTEST_PARALLEL_LEVEL`` is set to 8, CTest will run
up to 8 tests concurrently as if ``ctest`` were invoked with the
:option:`--parallel 8 <ctest --parallel>` option.

See :manual:`ctest(1)` for more information on parallel test execution.


code:
CTEST_PROGRESS_OUTPUT
---------------------

.. versionadded:: 3.13

.. include:: ENV_VAR.txt

Boolean environment variable that affects how :manual:`ctest <ctest(1)>`
command output reports overall progress.  When set to ``1``, ``TRUE``, ``ON`` or anything
else that evaluates to boolean true, progress is reported by repeatedly
updating the same line.  This greatly reduces the overall verbosity, but is
only supported when output is sent directly to a terminal.  If the environment
variable is not set or has a value that evaluates to false, output is reported
normally with each test having its own start and end lines logged to the
output.

The :option:`--progress <ctest --progress>` option to :manual:`ctest <ctest(1)>`
overrides this environment variable if both are given.


code:
CTEST_USE_LAUNCHERS_DEFAULT
---------------------------

.. include:: ENV_VAR.txt

Initializes the :variable:`CTEST_USE_LAUNCHERS` variable if not already defined.


code:
CUDAARCHS
---------

.. versionadded:: 3.20

.. include:: ENV_VAR.txt

Value used to initialize :variable:`CMAKE_CUDA_ARCHITECTURES` on the first
configuration. Subsequent runs will use the value stored in the cache.

This is a semicolon-separated list of architectures as described in
:prop_tgt:`CUDA_ARCHITECTURES`.


code:
CUDACXX
-------

.. versionadded:: 3.8

.. include:: ENV_VAR.txt

Preferred executable for compiling ``CUDA`` language files. Will only be used by
CMake on the first configuration to determine ``CUDA`` compiler, after which the
value for ``CUDA`` is stored in the cache as
:variable:`CMAKE_CUDA_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_CUDA_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.

.. note::
  Options that are required to make the compiler work correctly can be included;
  they can not be changed.

.. code-block:: console

  $ export CUDACXX="custom-compiler --arg1 --arg2"


code:
CUDAFLAGS
---------

.. versionadded:: 3.8

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``CUDA`` files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_CUDA_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``CUDA``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_CUDA_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
CUDAHOSTCXX
-----------

.. versionadded:: 3.8

.. include:: ENV_VAR.txt

Preferred executable for compiling host code when compiling ``CUDA``
language files. Will only be used by CMake on the first configuration to
determine ``CUDA`` host compiler, after which the value for ``CUDAHOSTCXX`` is
stored in the cache as
:variable:`CMAKE_CUDA_HOST_COMPILER <CMAKE_<LANG>_HOST_COMPILER>`.
This environment variable is preferred over
:variable:`CMAKE_CUDA_HOST_COMPILER <CMAKE_<LANG>_HOST_COMPILER>`.

This environment variable is primarily meant for use with projects that
enable ``CUDA`` as a first-class language.

.. note::

  Ignored when using :ref:`Visual Studio Generators`.

.. versionadded:: 3.13
  The :module:`FindCUDA`
  module will use this variable to initialize its ``CUDA_HOST_COMPILER`` setting.


code:
CXX
---

.. include:: ENV_VAR.txt

Preferred executable for compiling ``CXX`` language files. Will only be used by
CMake on the first configuration to determine ``CXX`` compiler, after which the
value for ``CXX`` is stored in the cache as
:variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.

.. note::
  Options that are required to make the compiler work correctly can be included;
  they can not be changed.

.. code-block:: console

  $ export CXX="custom-compiler --arg1 --arg2"


code:
CXXFLAGS
--------

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``CXX`` (C++) files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_CXX_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``CXX``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_CXX_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
DASHBOARD_TEST_FROM_CTEST
-------------------------

.. include:: ENV_VAR.txt

Environment variable that will exist when a test executed by :manual:`ctest(1)`
is run in non-interactive mode.  The value will be equal to
:variable:`CMAKE_VERSION`.


code:
DESTDIR
-------

.. include:: ENV_VAR.txt

On UNIX one can use the ``DESTDIR`` mechanism in order to relocate the
whole installation.  ``DESTDIR`` means DESTination DIRectory.  It is
commonly used by packagers to install software in a staging directory.

For example, running

.. code-block:: shell

  make DESTDIR=/package/stage install

will install the software using the installation prefix, e.g. ``/usr/local``,
prepended with the ``DESTDIR`` value which gives ``/package/stage/usr/local``.
The packaging tool may then construct the package from the content of the
``/package/stage`` directory.

See the :variable:`CMAKE_INSTALL_PREFIX` variable to control the
installation prefix when configuring a build tree.  Or, when using
the :manual:`cmake(1)` command-line tool's :option:`--install <cmake --install>`
mode, one may specify a different prefix using the
:option:`--prefix <cmake--install --prefix>` option.

.. note::

  ``DESTDIR`` may not be used on Windows because installation
  prefix usually contains a drive letter like in ``C:/Program Files``
  which cannot be prepended with some other prefix.


code:
This is a CMake :ref:`Environment Variable <CMake Language
Environment Variables>`. Its initial value is taken from
the calling process environment.


code:
FC
--

.. include:: ENV_VAR.txt

Preferred executable for compiling ``Fortran`` language files. Will only be used
by CMake on the first configuration to determine ``Fortran`` compiler, after
which the value for ``Fortran`` is stored in the cache as
:variable:`CMAKE_Fortran_COMPILER <CMAKE_<LANG>_COMPILER>`. For any
configuration run (including the first), the environment variable will be
ignored if the :variable:`CMAKE_Fortran_COMPILER <CMAKE_<LANG>_COMPILER>`
variable is defined.

.. note::
  Options that are required to make the compiler work correctly can be included;
  they can not be changed.

.. code-block:: console

  $ export FC="custom-compiler --arg1 --arg2"


code:
FFLAGS
------

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``Fortran`` files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_Fortran_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``Fortran``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_Fortran_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
HIPCXX
------

.. versionadded:: 3.21

.. include:: ENV_VAR.txt

Preferred executable for compiling ``HIP`` language files. Will only be used by
CMake on the first configuration to determine ``HIP`` compiler, after which the
value for ``HIP`` is stored in the cache as
:variable:`CMAKE_HIP_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_HIP_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.


code:
HIPFLAGS
--------

.. versionadded:: 3.21

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``HIP`` files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_HIP_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``HIP``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_HIP_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
HIPHOSTCXX
-----------

.. versionadded:: 3.28

.. include:: ENV_VAR.txt

Preferred executable for compiling host code when compiling ``HIP``
language files with the NVIDIA CUDA Compiler. Will only be used by CMake
on the first configuration to determine ``HIP`` host compiler, after which
the value for ``HIPHOSTCXX`` is stored in the cache as
:variable:`CMAKE_HIP_HOST_COMPILER <CMAKE_<LANG>_HOST_COMPILER>`.

This environment variable is primarily meant for use with projects that
enable ``HIP`` as a first-class language.

.. note::

  Ignored when using :ref:`Visual Studio Generators`.


code:
ISPC
-------

.. versionadded:: 3.19

.. include:: ENV_VAR.txt

Preferred executable for compiling ``ISPC`` language files. Will only be used by
CMake on the first configuration to determine ``ISPC`` compiler, after which the
value for ``ISPC`` is stored in the cache as
:variable:`CMAKE_ISPC_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_ISPC_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.


code:
ISPCFLAGS
---------

.. versionadded:: 3.19

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``ISPC`` files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_ISPC_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``ISPC``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_ISPC_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
CMake uses this environment variable value, in combination with its own
builtin default flags for the toolchain, to initialize and store the
|CMAKE_LANG_FLAGS| cache entry.
This occurs the first time a build tree is configured for language |LANG|.
For any configuration run (including the first), the environment variable
will be ignored if the |CMAKE_LANG_FLAGS| variable is already defined.


code:
LDFLAGS
-------

.. include:: ENV_VAR.txt

Will only be used by CMake on the first configuration to determine the default
linker flags, after which the value for ``LDFLAGS`` is stored in the cache
as :variable:`CMAKE_EXE_LINKER_FLAGS_INIT`,
:variable:`CMAKE_SHARED_LINKER_FLAGS_INIT`, and
:variable:`CMAKE_MODULE_LINKER_FLAGS_INIT`. For any configuration run
(including the first), the environment variable will be ignored if the
equivalent  ``CMAKE_<TYPE>_LINKER_FLAGS_INIT`` variable is defined.


code:
MACOSX_DEPLOYMENT_TARGET
------------------------

.. include:: ENV_VAR.txt

Specify the minimum version of macOS on which the target binaries are
to be deployed.

The ``MACOSX_DEPLOYMENT_TARGET`` environment variable sets the default value for
the :variable:`CMAKE_OSX_DEPLOYMENT_TARGET` variable.


code:
OBJC
----

.. versionadded:: 3.16.7

.. include:: ENV_VAR.txt

Preferred executable for compiling ``OBJC`` language files. Will only be used
by CMake on the first configuration to determine ``OBJC`` compiler, after
which the value for ``OBJC`` is stored in the cache as
:variable:`CMAKE_OBJC_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_OBJC_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.

If ``OBJC`` is not defined, the :envvar:`CC` environment variable will
be checked instead.


code:
OBJCXX
------

.. versionadded:: 3.16.7

.. include:: ENV_VAR.txt

Preferred executable for compiling ``OBJCXX`` language files. Will only be used
by CMake on the first configuration to determine ``OBJCXX`` compiler, after
which the value for ``OBJCXX`` is stored in the cache as
:variable:`CMAKE_OBJCXX_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration
run (including the first), the environment variable will be ignored if the
:variable:`CMAKE_OBJCXX_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.

If ``OBJCXX`` is not defined, the :envvar:`CXX` environment variable will
be checked instead.


code:
<PackageName>_ROOT
------------------

.. versionadded:: 3.12

.. include:: ENV_VAR.txt

Calls to :command:`find_package(<PackageName>)` will search in prefixes
specified by the ``<PackageName>_ROOT`` environment variable, where
``<PackageName>`` is the (case-preserved) name given to the
:command:`find_package` call and ``_ROOT`` is literal.
For example, ``find_package(Foo)`` will search prefixes specified in the
``Foo_ROOT`` environment variable (if set).  See policy :policy:`CMP0074`.

This variable may hold a single prefix or a list of prefixes separated
by ``:`` on UNIX or ``;`` on Windows (the same as the ``PATH`` environment
variable convention on those platforms).

See also the :variable:`<PackageName>_ROOT` CMake variable.

.. envvar:: <PACKAGENAME>_ROOT

  .. versionadded:: 3.27

  Calls to :command:`find_package(<PackageName>)` will also search in
  prefixes specified by the upper-case ``<PACKAGENAME>_ROOT`` environment
  variable.  See policy :policy:`CMP0144`.

.. note::

  Note that the ``<PackageName>_ROOT`` and ``<PACKAGENAME>_ROOT``
  environment variables are distinct only on platforms that have
  case-sensitive environments.


code:
RC
--

.. include:: ENV_VAR.txt

Preferred executable for compiling ``resource`` files. Will only be used by CMake
on the first configuration to determine ``resource`` compiler, after which the
value for ``RC`` is stored in the cache as
:variable:`CMAKE_RC_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration run
(including the first), the environment variable will be ignored if the
:variable:`CMAKE_RC_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.

.. note::
  Options that are required to make the compiler work correctly can be included;
  they can not be changed.

.. code-block:: console

  $ export RC="custom-compiler --arg1 --arg2"


code:
RCFLAGS
-------

.. include:: ENV_VAR.txt

Add default compilation flags to be used when compiling ``RC`` (resource) files.

.. |CMAKE_LANG_FLAGS| replace:: :variable:`CMAKE_RC_FLAGS <CMAKE_<LANG>_FLAGS>`
.. |LANG| replace:: ``RC``
.. include:: LANG_FLAGS.txt

See also :variable:`CMAKE_RC_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>`.


code:
SSL_CERT_DIR
------------

.. versionadded:: 3.25

.. include:: ENV_VAR.txt

Specify default directory containing CA certificates.  It overrides
the default CA directory used.


code:
SSL_CERT_FILE
-------------

.. versionadded:: 3.25

.. include:: ENV_VAR.txt

Specify the file name containing CA certificates.  It overrides the
default, os-specific CA file used.


code:
SWIFTC
------

.. versionadded:: 3.15

.. include:: ENV_VAR.txt

Preferred executable for compiling ``Swift`` language files. Will only be used by
CMake on the first configuration to determine ``Swift`` compiler, after which the
value for ``SWIFTC`` is stored in the cache as
:variable:`CMAKE_Swift_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration run
(including the first), the environment variable will be ignored if the
:variable:`CMAKE_Swift_COMPILER <CMAKE_<LANG>_COMPILER>` variable is defined.

.. note::
  Options that are required to make the compiler work correctly can be included;
  they can not be changed.

.. code-block:: console

  $ export SWIFTC="custom-compiler --arg1 --arg2"


code:
VERBOSE
-------

.. versionadded:: 3.14

Activates verbose output from CMake and your build tools of choice when
you start to actually build your project.

Note that any given value is ignored. It's just checked for existence.

See also :ref:`Build Tool Mode <Build Tool Mode>` and
:envvar:`CMAKE_NO_VERBOSE` environment variable


code:
Borland Makefiles
-----------------

Generates Borland makefiles.


code:
CodeBlocks
----------

.. deprecated:: 3.27

  Support for :ref:`Extra Generators` is deprecated and will be removed from
  a future version of CMake.  IDEs may use the :manual:`cmake-file-api(7)`
  to view CMake-generated project build trees.

Generates CodeBlocks project files.

Project files for CodeBlocks will be created in the top directory and
in every subdirectory which features a ``CMakeLists.txt`` file containing
a :command:`project` call.  Additionally a hierarchy of makefiles is generated
into the build tree.
The appropriate make program can build the
project through the default ``all`` target.  An ``install`` target is
also provided.

.. versionadded:: 3.10
 The :variable:`CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES` variable may
 be set to ``ON`` to exclude any files which are located outside of
 the project root directory.

This "extra" generator may be specified as:

``CodeBlocks - MinGW Makefiles``
 Generate with :generator:`MinGW Makefiles`.

``CodeBlocks - NMake Makefiles``
 Generate with :generator:`NMake Makefiles`.

``CodeBlocks - NMake Makefiles JOM``
 .. versionadded:: 3.8
  Generate with :generator:`NMake Makefiles JOM`.

``CodeBlocks - Ninja``
 Generate with :generator:`Ninja`.

``CodeBlocks - Unix Makefiles``
 Generate with :generator:`Unix Makefiles`.


code:
CodeLite
----------

.. deprecated:: 3.27

  Support for :ref:`Extra Generators` is deprecated and will be removed from
  a future version of CMake.  IDEs may use the :manual:`cmake-file-api(7)`
  to view CMake-generated project build trees.

Generates CodeLite project files.

Project files for CodeLite will be created in the top directory and
in every subdirectory which features a CMakeLists.txt file containing
a :command:`project` call.
The appropriate make program can build the
project through the default ``all`` target.  An ``install`` target
is also provided.

.. versionadded:: 3.7
 The :variable:`CMAKE_CODELITE_USE_TARGETS` variable may be set to ``ON``
 to change the default behavior from projects to targets as the basis
 for project files.

This "extra" generator may be specified as:

``CodeLite - MinGW Makefiles``
 Generate with :generator:`MinGW Makefiles`.

``CodeLite - NMake Makefiles``
 Generate with :generator:`NMake Makefiles`.

``CodeLite - Ninja``
 Generate with :generator:`Ninja`.

``CodeLite - Unix Makefiles``
 Generate with :generator:`Unix Makefiles`.


code:
Eclipse CDT4
------------

.. deprecated:: 3.27

  Support for :ref:`Extra Generators` is deprecated and will be removed from
  a future version of CMake.  IDEs may use the :manual:`cmake-file-api(7)`
  to view CMake-generated project build trees.

Generates Eclipse CDT 4.0 project files.

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 ``all`` target.  An ``install`` target
is also provided.

This "extra" generator may be specified as:

``Eclipse CDT4 - MinGW Makefiles``
 Generate with :generator:`MinGW Makefiles`.

``Eclipse CDT4 - NMake Makefiles``
 Generate with :generator:`NMake Makefiles`.

``Eclipse CDT4 - Ninja``
 Generate with :generator:`Ninja`.

``Eclipse CDT4 - Unix Makefiles``
 Generate with :generator:`Unix Makefiles`.


code:
Green Hills MULTI
-----------------

.. versionadded:: 3.3

.. versionadded:: 3.15
  Linux support.

Generates Green Hills MULTI project files (experimental, work-in-progress).

  The buildsystem has predetermined build-configuration settings that can be controlled
  via the :variable:`CMAKE_BUILD_TYPE` variable.

Platform Selection
^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.13

The variable ``GHS_PRIMARY_TARGET`` can be used to select the target platform.

  | Sets ``primaryTarget`` entry in project file.

For example:

* ``cmake -G "Green Hills MULTI" -D GHS_PRIMARY_TARGET=ppc_integrity.tgt``

Otherwise the ``primaryTarget`` will be composed from the values of :variable:`CMAKE_GENERATOR_PLATFORM`
and ``GHS_TARGET_PLATFORM``. Defaulting to the value of ``arm_integrity.tgt``

* The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
  via the :option:`cmake -A` option.

  | Typical values of ``arm``, ``ppc``, ``86``, etcetera, are used.

* The variable ``GHS_TARGET_PLATFORM`` may be set, perhaps via the :option:`cmake -D`
  option.

  | Defaults to ``integrity``.
  | Usual values are ``integrity``, ``threadx``, ``uvelosity``, ``velosity``,
    ``vxworks``, ``standalone``.

For example:

* ``cmake -G "Green Hills MULTI"`` for ``arm_integrity.tgt``.
* ``cmake -G "Green Hills MULTI" -A 86`` for ``86_integrity.tgt``.
* ``cmake -G "Green Hills MULTI" -D GHS_TARGET_PLATFORM=standalone`` for ``arm_standalone.tgt``.
* ``cmake -G "Green Hills MULTI" -A ppc -D GHS_TARGET_PLATFORM=standalone`` for ``ppc_standalone.tgt``.

Toolset Selection
^^^^^^^^^^^^^^^^^

.. versionadded:: 3.13

The generator searches for the latest compiler or can be given a location to use.
``GHS_TOOLSET_ROOT`` is the directory that is checked for the latest compiler.

* The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
  via the :option:`cmake -T` option, to specify the location of the toolset.
  Both absolute and relative paths are valid. Paths are relative to ``GHS_TOOLSET_ROOT``.

* The variable ``GHS_TOOLSET_ROOT`` may be set, perhaps via the :option:`cmake -D`
  option.

  | Root path for toolset searches and relative paths.
  | Defaults to ``C:/ghs`` in Windows or ``/usr/ghs`` in Linux.

For example, setting a specific compiler:

* ``cmake -G "Green Hills MULTI" -T comp_201754`` for ``/usr/ghs/comp_201754``.
* ``cmake -G "Green Hills MULTI" -T comp_201754 -D GHS_TOOLSET_ROOT=/opt/ghs`` for ``/opt/ghs/comp_201754``.
* ``cmake -G "Green Hills MULTI" -T /usr/ghs/comp_201554``
* ``cmake -G "Green Hills MULTI" -T C:/ghs/comp_201754``

For example, searching for latest compiler:

* ``cmake -G "Green Hills MULTI"`` for searching ``/usr/ghs``.
* ``cmake -G "Green Hills MULTI -D GHS_TOOLSET_ROOT=/opt/ghs"`` for searching ``/opt/ghs``.

.. note::
  The :variable:`CMAKE_GENERATOR_TOOLSET` should use CMake style paths.

OS and BSP Selection
^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.3

Certain target platforms, like Integrity, require an OS.  The RTOS directory path
can be explicitly set using ``GHS_OS_DIR``.  Otherwise ``GHS_OS_ROOT`` will be
searched for the latest Integrity RTOS.

If the target platform, like Integrity, requires a BSP name then it can be set via
the ``GHS_BSP_NAME`` variable.

* ``GHS_OS_DIR`` and ``GHS_OS_DIR_OPTION``

  | Sets ``-os_dir`` entry in project file.

  | ``GHS_OS_DIR_OPTION`` default value is ``-os_dir``.

  .. versionadded:: 3.15
    The ``GHS_OS_DIR_OPTION`` variable.

  For example:

  * ``cmake -G "Green Hills MULTI" -D GHS_OS_DIR=/usr/ghs/int1144``

* ``GHS_OS_ROOT``

  | Root path for RTOS searches.
  | Defaults to ``C:/ghs`` in Windows or ``/usr/ghs`` in Linux.

  For example:

  * ``cmake -G "Green Hills MULTI" -D GHS_OS_ROOT=/opt/ghs``

* ``GHS_BSP_NAME``

  | Sets ``-bsp`` entry in project file.
  | Defaults to ``sim<arch>`` for ``integrity`` platforms.

  For example:

  * ``cmake -G "Green Hills MULTI"`` for ``simarm`` on ``arm_integrity.tgt``.
  * ``cmake -G "Green Hills MULTI" -A 86`` for ``sim86`` on ``86_integrity.tgt``.
  * ``cmake -G "Green Hills MULTI" -A ppc -D GHS_BSP_NAME=sim800`` for ``sim800``
    on ``ppc_integrity.tgt``.
  * ``cmake -G "Green Hills MULTI" -D GHS_PRIMARY_TARGET=ppc_integrity.tgt -D GHS_BSP_NAME=fsl-t1040``
    for ``fsl-t1040`` on ``ppc_integrity.tgt``.

Target Properties
^^^^^^^^^^^^^^^^^

.. versionadded:: 3.14

The following properties are available:

* :prop_tgt:`GHS_INTEGRITY_APP`
* :prop_tgt:`GHS_NO_SOURCE_GROUP_FILE`

MULTI Project Variables
^^^^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.3

Adding a Customization file and macros are available through the use of the following
variables:

* ``GHS_CUSTOMIZATION`` - CMake path name to Customization File.
* ``GHS_GPJ_MACROS`` - CMake list of Macros.

.. note::
  This generator is deemed experimental as of CMake |release|
  and is still a work in progress.  Future versions of CMake
  may make breaking changes as the generator matures.


code:
Kate
----

.. deprecated:: 3.27

  Support for :ref:`Extra Generators` is deprecated and will be removed from
  a future version of CMake.  IDEs may use the :manual:`cmake-file-api(7)`
  to view CMake-generated project build trees.

Generates Kate project files.

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
``ProjectName.kateproject`` file in the editor.
If the Kate Build-plugin is enabled, all targets generated by CMake are
available for building.

This "extra" generator may be specified as:

``Kate - MinGW Makefiles``
 Generate with :generator:`MinGW Makefiles`.

``Kate - NMake Makefiles``
 Generate with :generator:`NMake Makefiles`.

``Kate - Ninja``
 Generate with :generator:`Ninja`.

``Kate - Ninja Multi-Config``
 Generate with :generator:`Ninja Multi-Config`.

``Kate - Unix Makefiles``
 Generate with :generator:`Unix Makefiles`.


code:
MSYS Makefiles
--------------

Generates makefiles for use with MSYS (Minimal SYStem)
``make`` under the MSYS shell.

Use this generator in a MSYS shell prompt and using ``make`` as the build
tool.  The generated makefiles use ``/bin/sh`` as the shell to launch build
rules.  They are not compatible with a Windows command prompt.

To build under a Windows command prompt, use the
:generator:`MinGW Makefiles` generator.


code:
MinGW Makefiles
---------------

Generates makefiles for use with ``mingw32-make`` under a Windows command
prompt.

Use this generator under a Windows command prompt with
MinGW (Minimalist GNU for Windows) in the ``PATH``
and using ``mingw32-make`` as the build tool.  The generated makefiles use
``cmd.exe`` as the shell to launch build rules.  They are not compatible with
MSYS or a unix shell.

To build under the MSYS shell, use the :generator:`MSYS Makefiles` generator.


code:
NMake Makefiles JOM
-------------------

Generates JOM makefiles.

.. versionadded:: 3.8
  :generator:`CodeBlocks` generator can be used as an extra generator.


code:
NMake Makefiles
---------------

Generates NMake makefiles.


code:
Ninja Multi-Config
------------------

.. versionadded:: 3.17

Generates multiple ``build-<Config>.ninja`` files.

This generator is very much like the :generator:`Ninja` generator, but with
some key differences. Only these differences will be discussed in this
document.

Unlike the :generator:`Ninja` generator, ``Ninja Multi-Config`` generates
multiple configurations at once with :variable:`CMAKE_CONFIGURATION_TYPES`
instead of only one configuration with :variable:`CMAKE_BUILD_TYPE`. One
``build-<Config>.ninja`` file will be generated for each of these
configurations (with ``<Config>`` being the configuration name.) These files
are intended to be run with ``ninja -f build-<Config>.ninja``. A
``build.ninja`` file is also generated, using the configuration from either
:variable:`CMAKE_DEFAULT_BUILD_TYPE` or the first item from
:variable:`CMAKE_CONFIGURATION_TYPES`.

``cmake --build . --config <Config>`` will always use ``build-<Config>.ninja``
to build. If no :option:`--config <cmake--build --config>` argument is
specified, :option:`cmake --build . <cmake --build>` will use ``build.ninja``.

Each ``build-<Config>.ninja`` file contains ``<target>`` targets as well as
``<target>:<Config>`` targets, where ``<Config>`` is the same as the
configuration specified in ``build-<Config>.ninja`` Additionally, if
cross-config mode is enabled, ``build-<Config>.ninja`` may contain
``<target>:<OtherConfig>`` targets, where ``<OtherConfig>`` is a cross-config,
as well as ``<target>:all``, which builds the target in all cross-configs. See
below for how to enable cross-config mode.

The ``Ninja Multi-Config`` generator recognizes the following variables:

:variable:`CMAKE_CONFIGURATION_TYPES`
  Specifies the total set of configurations to build. Unlike with other
  multi-config generators, this variable has a value of
  ``Debug;Release;RelWithDebInfo`` by default.

:variable:`CMAKE_CROSS_CONFIGS`
  Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of
  configurations available from all ``build-<Config>.ninja`` files.

:variable:`CMAKE_DEFAULT_BUILD_TYPE`
  Specifies the configuration to use by default in a ``build.ninja`` file.

:variable:`CMAKE_DEFAULT_CONFIGS`
  Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of
  configurations to build for a target in ``build.ninja``
  if no ``:<Config>`` suffix is specified.

Consider the following example:

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.16)
  project(MultiConfigNinja C)

  add_executable(generator generator.c)
  add_custom_command(OUTPUT generated.c COMMAND generator generated.c)
  add_library(generated ${CMAKE_BINARY_DIR}/generated.c)

Now assume you configure the project with ``Ninja Multi-Config`` and run one of
the following commands:

.. code-block:: shell

  ninja -f build-Debug.ninja generated
  # OR
  cmake --build . --config Debug --target generated

This would build the ``Debug`` configuration of ``generator``, which would be
used to generate ``generated.c``, which would be used to build the ``Debug``
configuration of ``generated``.

But if :variable:`CMAKE_CROSS_CONFIGS` is set to ``all``, and you run the
following instead:

.. code-block:: shell

  ninja -f build-Release.ninja generated:Debug
  # OR
  cmake --build . --config Release --target generated:Debug

This would build the ``Release`` configuration of ``generator``, which would be
used to generate ``generated.c``, which would be used to build the ``Debug``
configuration of ``generated``. This is useful for running a release-optimized
version of a generator utility while still building the debug version of the
targets built with the generated code.

Custom Commands
^^^^^^^^^^^^^^^

.. versionadded:: 3.20

The ``Ninja Multi-Config`` generator adds extra capabilities to
:command:`add_custom_command` and :command:`add_custom_target` through its
cross-config mode. The ``COMMAND``, ``DEPENDS``, and ``WORKING_DIRECTORY``
arguments can be evaluated in the context of either the "command config" (the
"native" configuration of the ``build-<Config>.ninja`` file in use) or the
"output config" (the configuration used to evaluate the ``OUTPUT`` and
``BYPRODUCTS``).

If either ``OUTPUT`` or ``BYPRODUCTS`` 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 ``OUTPUT`` and ``BYPRODUCTS`` paths are unique to each configuration
(e.g. by using the :genex:`$<CONFIG>` generator expression), the first argument of
``COMMAND`` is still evaluated in the command config by default, while all
subsequent arguments, as well as the arguments to ``DEPENDS`` and
``WORKING_DIRECTORY``, are evaluated in the output config. These defaults can
be overridden with the :genex:`$<OUTPUT_CONFIG:...>` and :genex:`$<COMMAND_CONFIG:...>`
generator-expressions. Note that if a target is specified by its name in
``DEPENDS``, or as the first argument of ``COMMAND``, it is always evaluated
in the command config, even if it is wrapped in :genex:`$<OUTPUT_CONFIG:...>`
(because its plain name is not a generator expression).

As an example, consider the following:

.. code-block:: cmake

  add_custom_command(
    OUTPUT "$<CONFIG>.txt"
    COMMAND
      generator "$<CONFIG>.txt"
                "$<OUTPUT_CONFIG:$<CONFIG>>"
                "$<COMMAND_CONFIG:$<CONFIG>>"
    DEPENDS
      tgt1
      "$<TARGET_FILE:tgt2>"
      "$<OUTPUT_CONFIG:$<TARGET_FILE:tgt3>>"
      "$<COMMAND_CONFIG:$<TARGET_FILE:tgt4>>"
    )

Assume that ``generator``, ``tgt1``, ``tgt2``, ``tgt3``, and ``tgt4`` are all
executable targets, and assume that ``$<CONFIG>.txt`` is built in the ``Debug``
output config using the ``Release`` command config. The ``Release`` build of
the ``generator`` target is called with ``Debug.txt Debug Release`` as
arguments. The command depends on the ``Release`` builds of ``tgt1`` and
``tgt4``, and the ``Debug`` builds of ``tgt2`` and ``tgt3``.

``PRE_BUILD``, ``PRE_LINK``, and ``POST_BUILD`` custom commands for targets
only get run in their "native" configuration (the ``Release`` configuration in
the ``build-Release.ninja`` file) unless they have no ``BYPRODUCTS`` or their
``BYPRODUCTS`` are unique per config. Consider the following example:

.. code-block:: cmake

  add_executable(exe main.c)
  add_custom_command(
    TARGET exe
    POST_BUILD
    COMMAND
      ${CMAKE_COMMAND} -E echo "Running no-byproduct command"
    )
  add_custom_command(
    TARGET exe
    POST_BUILD
    COMMAND
      ${CMAKE_COMMAND} -E echo
      "Running separate-byproduct command for $<CONFIG>"
    BYPRODUCTS $<CONFIG>.txt
    )
  add_custom_command(
    TARGET exe
    POST_BUILD
    COMMAND
      ${CMAKE_COMMAND} -E echo
      "Running common-byproduct command for $<CONFIG>"
    BYPRODUCTS exe.txt
    )

In this example, if you build ``exe:Debug`` in ``build-Release.ninja``, 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
``exe:Release`` in ``build-Release.ninja``, all three custom commands get run.


code:
Ninja
-----

Generates ``build.ninja`` files.

A ``build.ninja`` file is generated into the build tree.  Use the ninja
program to build the project through the ``all`` target and install the
project through the ``install`` (or ``install/strip``) target.

For each subdirectory ``sub/dir`` of the project, additional targets
are generated:

``sub/dir/all``

  .. versionadded:: 3.6

    Depends on all targets required by the subdirectory.

``sub/dir/install``

  .. versionadded:: 3.7

    Runs the install step in the subdirectory, if any.

``sub/dir/install/strip``

  .. versionadded:: 3.7
    Runs the install step in the subdirectory followed by a ``CMAKE_STRIP`` command,
    if any.

    The ``CMAKE_STRIP`` variable will contain the platform's ``strip`` utility, which
    removes symbols information from generated binaries.

``sub/dir/test``

  .. versionadded:: 3.7

    Runs the test step in the subdirectory, if any.

``sub/dir/package``

  .. versionadded:: 3.7

    Runs the package step in the subdirectory, if any.

Fortran Support
^^^^^^^^^^^^^^^

.. versionadded:: 3.7

The ``Ninja`` generator conditionally supports Fortran when the ``ninja``
tool is at least version 1.10 (which has the required features).

Swift Support
^^^^^^^^^^^^^

.. versionadded:: 3.15

The Swift support is experimental, not considered stable, and may change
in future releases of CMake.

See Also
^^^^^^^^

.. versionadded:: 3.17
  The :generator:`Ninja Multi-Config` generator is similar to the ``Ninja``
  generator, but generates multiple configurations at once.


code:
Sublime Text 2
--------------

.. deprecated:: 3.27

  Support for :ref:`Extra Generators` is deprecated and will be removed from
  a future version of CMake.  IDEs may use the :manual:`cmake-file-api(7)`
  to view CMake-generated project build trees.

Generates Sublime Text 2 project files.

Project files for Sublime Text 2 will be created in the top directory
and in every subdirectory which features a ``CMakeLists.txt`` file
containing a :command:`project` call.  Additionally ``Makefiles``
(or ``build.ninja`` files) are generated into the build tree.
The appropriate make program can build the project through the default ``all``
target.  An ``install`` target is also provided.

This "extra" generator may be specified as:

``Sublime Text 2 - MinGW Makefiles``
 Generate with :generator:`MinGW Makefiles`.

``Sublime Text 2 - NMake Makefiles``
 Generate with :generator:`NMake Makefiles`.

``Sublime Text 2 - Ninja``
 Generate with :generator:`Ninja`.

``Sublime Text 2 - Unix Makefiles``
 Generate with :generator:`Unix Makefiles`.


code:
Unix Makefiles
--------------

Generates standard UNIX makefiles.

A hierarchy of UNIX makefiles is generated into the build tree.  Use
any standard UNIX-style make program to build the project through
the ``all`` target and install the project through the ``install``
(or ``install/strip``) target.

For each subdirectory ``sub/dir`` of the project a UNIX makefile will
be created, containing the following targets:

``all``
  Depends on all targets required by the subdirectory.

``install``
  Runs the install step in the subdirectory, if any.

``install/strip``
  Runs the install step in the subdirectory followed by a ``CMAKE_STRIP`` command,
  if any.

  The ``CMAKE_STRIP`` variable will contain the platform's ``strip`` utility, which
  removes symbols information from generated binaries.

``test``
  Runs the test step in the subdirectory, if any.

``package``
  Runs the package step in the subdirectory, if any.


code:
For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32-bit (``x86``) and
64-bit (``x64``) hosts (independent of the architecture they target).
|VS_TOOLSET_HOST_ARCH_DEFAULT|
One may explicitly request use of either the 32-bit or 64-bit host tools
by adding either ``host=x86`` or ``host=x64`` to the toolset specification.
See the :variable:`CMAKE_GENERATOR_TOOLSET` variable for details.


code:
.. versionadded:: 3.8
  For each toolset that comes with this version of Visual Studio, there are
  variants that are themselves compiled for 32-bit (``x86``) and
  64-bit (``x64``) hosts (independent of the architecture they target).
  |VS_TOOLSET_HOST_ARCH_DEFAULT|
  One may explicitly request use of either the 32-bit or 64-bit host tools
  by adding either ``host=x86`` or ``host=x64`` to the toolset specification.
  See the :variable:`CMAKE_GENERATOR_TOOLSET` variable for details.

.. versionadded:: 3.14
  Added support for ``host=x86`` option.


code:
Visual Studio 10 2010
---------------------

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 :generator:`Visual Studio 14 2015`
(or above) generator with :variable:`CMAKE_GENERATOR_TOOLSET` set to
``v100``, or by using the :generator:`NMake Makefiles` generator.

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 10 2010.rst


code:
Visual Studio 11 2012
---------------------

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 :generator:`Visual Studio 14 2015`
(or above) generator with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v110``,
or by using the :generator:`NMake Makefiles` generator.

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 11 2012.rst


code:
Visual Studio 12 2013
---------------------

Deprecated.  Generates Visual Studio 12 (VS 2013) project files.

.. note::
  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 :generator:`Visual Studio 14 2015` (or above) generator
  with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v120``, or by
  using the :generator:`NMake Makefiles` generator.

For compatibility with CMake versions prior to 3.0, one may specify this
generator using the name "Visual Studio 12" without the year component.

Project Types
^^^^^^^^^^^^^

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.

Platform Selection
^^^^^^^^^^^^^^^^^^

The default target platform name (architecture) is ``Win32``.

.. versionadded:: 3.1
  The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
  via the :option:`cmake -A` option, to specify a target platform
  name (architecture).  For example:

  * ``cmake -G "Visual Studio 12 2013" -A Win32``
  * ``cmake -G "Visual Studio 12 2013" -A x64``
  * ``cmake -G "Visual Studio 12 2013" -A ARM``

For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:

``Visual Studio 12 2013 Win64``
  Specify target platform ``x64``.

``Visual Studio 12 2013 ARM``
  Specify target platform ``ARM``.

Toolset Selection
^^^^^^^^^^^^^^^^^

The ``v120`` toolset that comes with Visual Studio 12 2013 is selected by
default.  The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

.. |VS_TOOLSET_HOST_ARCH_DEFAULT| replace::
   By default this generator uses the 32-bit variant even on a 64-bit host.

.. include:: VS_TOOLSET_HOST_ARCH_LEGACY.txt

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 12 2013.rst


code:
Visual Studio 14 2015
---------------------

.. versionadded:: 3.1

Generates Visual Studio 14 (VS 2015) project files.

Project Types
^^^^^^^^^^^^^

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.

Platform Selection
^^^^^^^^^^^^^^^^^^

The default target platform name (architecture) is ``Win32``.

The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :option:`cmake -A` option, to specify a target platform
name (architecture).  For example:

* ``cmake -G "Visual Studio 14 2015" -A Win32``
* ``cmake -G "Visual Studio 14 2015" -A x64``
* ``cmake -G "Visual Studio 14 2015" -A ARM``

For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:

``Visual Studio 14 2015 Win64``
  Specify target platform ``x64``.

``Visual Studio 14 2015 ARM``
  Specify target platform ``ARM``.

Toolset Selection
^^^^^^^^^^^^^^^^^

The ``v140`` toolset that comes with Visual Studio 14 2015 is selected by
default.  The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

.. |VS_TOOLSET_HOST_ARCH_DEFAULT| replace::
   By default this generator uses the 32-bit variant even on a 64-bit host.

.. include:: VS_TOOLSET_HOST_ARCH_LEGACY.txt

.. _`Windows 10 SDK Maximum Version for VS 2015`:

Windows 10 SDK Maximum Version for VS 2015
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.19

Microsoft stated in a "Windows 10 October 2018 Update" 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 ``10.0.14393.0``.

However, there are other recommendations for certain driver/Win32 builds that
indicate otherwise.  A user can override this behavior by either setting the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` to a false value
or setting the :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` to
the string value of the required maximum (e.g. ``10.0.15063.0``).

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 14 2015.rst


code:
Visual Studio 15 2017
---------------------

.. versionadded:: 3.7.1

Generates Visual Studio 15 (VS 2017) project files.

Project Types
^^^^^^^^^^^^^

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.

Instance Selection
^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.11

VS 2017 supports multiple installations on the same machine.  The
:variable:`CMAKE_GENERATOR_INSTANCE` variable may be used to select one.

Platform Selection
^^^^^^^^^^^^^^^^^^

The default target platform name (architecture) is ``Win32``.

The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :option:`cmake -A` option, to specify a target platform
name (architecture).  For example:

* ``cmake -G "Visual Studio 15 2017" -A Win32``
* ``cmake -G "Visual Studio 15 2017" -A x64``
* ``cmake -G "Visual Studio 15 2017" -A ARM``
* ``cmake -G "Visual Studio 15 2017" -A ARM64``

For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:

``Visual Studio 15 2017 Win64``
  Specify target platform ``x64``.

``Visual Studio 15 2017 ARM``
  Specify target platform ``ARM``.

Toolset Selection
^^^^^^^^^^^^^^^^^

The ``v141`` toolset that comes with Visual Studio 15 2017 is selected by
default.  The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

.. |VS_TOOLSET_HOST_ARCH_DEFAULT| replace::
   By default this generator uses the 32-bit variant even on a 64-bit host.

.. include:: VS_TOOLSET_HOST_ARCH_LEGACY.txt

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 15 2017.rst


code:
Visual Studio 16 2019
---------------------

.. versionadded:: 3.14

Generates Visual Studio 16 (VS 2019) project files.

Project Types
^^^^^^^^^^^^^

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.

Instance Selection
^^^^^^^^^^^^^^^^^^

VS 2019 supports multiple installations on the same machine.  The
:variable:`CMAKE_GENERATOR_INSTANCE` variable may be used to select one.

Platform Selection
^^^^^^^^^^^^^^^^^^

The default target platform name (architecture) is that of the host
and is provided in the :variable:`CMAKE_VS_PLATFORM_NAME_DEFAULT` variable.

The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :option:`cmake -A` option, to specify a target platform
name (architecture).  For example:

* ``cmake -G "Visual Studio 16 2019" -A Win32``
* ``cmake -G "Visual Studio 16 2019" -A x64``
* ``cmake -G "Visual Studio 16 2019" -A ARM``
* ``cmake -G "Visual Studio 16 2019" -A ARM64``

Toolset Selection
^^^^^^^^^^^^^^^^^

The ``v142`` toolset that comes with Visual Studio 16 2019 is selected by
default.  The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

.. |VS_TOOLSET_HOST_ARCH_DEFAULT| replace::
   By default this generator uses the 64-bit variant on x64 hosts and
   the 32-bit variant otherwise.

.. include:: VS_TOOLSET_HOST_ARCH.txt

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 16 2019.rst


code:
Visual Studio 17 2022
---------------------

.. versionadded:: 3.21

Generates Visual Studio 17 (VS 2022) project files.

Project Types
^^^^^^^^^^^^^

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.

Instance Selection
^^^^^^^^^^^^^^^^^^

VS 2022 supports multiple installations on the same machine.  The
:variable:`CMAKE_GENERATOR_INSTANCE` variable may be used to select one.

Platform Selection
^^^^^^^^^^^^^^^^^^

The default target platform name (architecture) is that of the host
and is provided in the :variable:`CMAKE_VS_PLATFORM_NAME_DEFAULT` variable.

The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
via the :option:`cmake -A` option, to specify a target platform
name (architecture).  For example:

* ``cmake -G "Visual Studio 17 2022" -A Win32``
* ``cmake -G "Visual Studio 17 2022" -A x64``
* ``cmake -G "Visual Studio 17 2022" -A ARM``
* ``cmake -G "Visual Studio 17 2022" -A ARM64``

Toolset Selection
^^^^^^^^^^^^^^^^^

The ``v143`` toolset that comes with VS 17 2022 is selected by default.
The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

.. |VS_TOOLSET_HOST_ARCH_DEFAULT| replace::
   By default this generator uses the 64-bit variant on x64 hosts and
   the 32-bit variant otherwise.

.. include:: VS_TOOLSET_HOST_ARCH.txt

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 17 2022.rst


code:
Visual Studio 6
---------------

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 :generator:`NMake Makefiles` generator.


code:
Visual Studio 7 .NET 2003
-------------------------

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 :generator:`NMake Makefiles` generator.

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 7 .NET 2003.rst


code:
Visual Studio 7
---------------

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 :generator:`NMake Makefiles` generator.


code:
Visual Studio 8 2005
--------------------

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 :generator:`NMake Makefiles` generator.

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 8 2005.rst


code:
Visual Studio 9 2008
--------------------

Deprecated.  Generates Visual Studio 9 2008 project files.

.. note::
  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 :generator:`Visual Studio 14 2015` generator (or above,
  and with VS 10 2010 also installed) with
  :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v90``,
  or by using the :generator:`NMake Makefiles` generator.

Platform Selection
^^^^^^^^^^^^^^^^^^

The default target platform name (architecture) is ``Win32``.

.. versionadded:: 3.1
  The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
  via the :option:`cmake -A` option, to specify a target platform
  name (architecture).  For example:

  * ``cmake -G "Visual Studio 9 2008" -A Win32``
  * ``cmake -G "Visual Studio 9 2008" -A x64``
  * ``cmake -G "Visual Studio 9 2008" -A Itanium``
  * ``cmake -G "Visual Studio 9 2008" -A <WinCE-SDK>``
    (Specify a target platform matching a Windows CE SDK name.)

For compatibility with CMake versions prior to 3.1, one may specify
a target platform name optionally at the end of the generator name.
This is supported only for:

``Visual Studio 9 2008 Win64``
  Specify target platform ``x64``.

``Visual Studio 9 2008 IA64``
  Specify target platform ``Itanium``.

``Visual Studio 9 2008 <WinCE-SDK>``
  Specify target platform matching a Windows CE SDK name.

path: buildtools/windows/cmake/share/cmake-3.29/Help/generator/Visual Studio 9 2008.rst


code:
Watcom WMake
------------

Generates Watcom WMake makefiles.


code:
Xcode
-----

Generate Xcode project files.

.. versionchanged:: 3.15
  This generator supports Xcode 5.0 and above.

.. _`Xcode Build System Selection`:

Toolset and Build System Selection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

By default Xcode is allowed to select its own default toolchain.
The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

.. versionadded:: 3.19
  This generator supports toolset specification using one of these forms:

* ``toolset``
* ``toolset[,key=value]*``
* ``key=value[,key=value]*``

The ``toolset`` specifies the toolset name.  The selected toolset name
is provided in the :variable:`CMAKE_XCODE_PLATFORM_TOOLSET` variable.

The ``key=value`` pairs form a comma-separated list of options to
specify generator-specific details of the toolset selection.
Supported pairs are:

``buildsystem=<variant>``
  Specify the buildsystem variant to use.
  See the :variable:`CMAKE_XCODE_BUILD_SYSTEM` variable for allowed values.

  For example, to select the original build system under Xcode 12,
  run :manual:`cmake(1)` with the option :option:`-T buildsystem=1 <cmake -T>`.

Swift Support
^^^^^^^^^^^^^

.. versionadded:: 3.4

When using the ``Xcode`` generator with Xcode 6.1 or higher,
one may enable the ``Swift`` language with the :command:`enable_language`
command or the :command:`project`.

Limitations
^^^^^^^^^^^

The Xcode generator does not support per-configuration sources.
Code like the following will result in a generation error:

.. code-block:: cmake

  add_executable(MyApp mymain-$<CONFIG>.cpp)


code:
Disclaimer: Most native build tools have poor support for escaping
certain values.  CMake has work-arounds for many cases but some values
may just not be possible to pass correctly.  If a value does not seem
to be escaped correctly, do not attempt to work-around the problem by
adding escape sequences to the value.  Your work-around may break in a
future version of CMake that has improved escape support.  Instead
consider defining the macro in a (configured) header file.  Then
report the limitation.  Known limitations include::

  #          - broken almost everywhere
  ;          - broken in VS IDE 7.0 and Borland Makefiles
  ,          - broken in VS IDE
  %          - broken in some cases in NMake
  & |        - broken in some cases on MinGW
  ^ < > \"   - broken in most Make tools on Windows

CMake does not reject these values outright because they do work in
some cases.  Use with caution.


code:
Note that it is not advisable to populate the :genex:`INSTALL_INTERFACE` of
the |INTERFACE_PROPERTY_LINK| of a target with absolute paths to the include
directories of dependencies.  That would hard-code into installed packages
the include directory paths for dependencies
**as found on the machine the package was made on**.

The :genex:`INSTALL_INTERFACE` of the |INTERFACE_PROPERTY_LINK| is only
suitable for specifying the required include directories for headers
provided with the target itself, not those provided by the transitive
dependencies listed in its :prop_tgt:`INTERFACE_LINK_LIBRARIES` target
property.  Those dependencies should themselves be targets that specify
their own header locations in |INTERFACE_PROPERTY_LINK|.

See the :ref:`Creating Relocatable Packages` section of the
:manual:`cmake-packages(7)` manual for discussion of additional care
that must be taken when specifying usage requirements while creating
packages for redistribution.


code:
Note that it is not advisable to populate the
|INTERFACE_PROPERTY_LINK| of a target with absolute paths to dependencies.
That would hard-code into installed packages the library file paths
for dependencies **as found on the machine the package was made on**.

See the :ref:`Creating Relocatable Packages` section of the
:manual:`cmake-packages(7)` manual for discussion of additional care
that must be taken when specifying usage requirements while creating
packages for redistribution.


code:
.. title:: CMake Reference Documentation

Introduction
############

CMake is a tool to manage building of source code.  Originally, CMake was
designed as a generator for various dialects of ``Makefile``, today
CMake generates modern buildsystems such as ``Ninja`` as well as project
files for IDEs such as Visual Studio and Xcode.

CMake is widely used for the C and C++ languages, but it may be used to
build source code of other languages too.

People encountering CMake for the first time may have different initial
goals.  To learn how to build a source code package downloaded from the
internet, start with the :guide:`User Interaction Guide`.
This will detail the steps needed to run the :manual:`cmake(1)` or
:manual:`cmake-gui(1)` executable and how to choose a generator, and
how to complete the build.

The :guide:`Using Dependencies Guide` is aimed at developers
wishing to get started using a third-party library.

For developers starting a project using CMake, the :guide:`CMake Tutorial`
is a suitable starting point.  The :manual:`cmake-buildsystem(7)`
manual is aimed at developers expanding their knowledge of maintaining
a buildsystem and becoming familiar with the build targets that
can be represented in CMake.  The :manual:`cmake-packages(7)` manual
explains how to create packages which can easily be consumed by
third-party CMake-based buildsystems.

Command-Line Tools
##################

.. toctree::
   :maxdepth: 1

   /manual/cmake.1
   /manual/ctest.1
   /manual/cpack.1

Interactive Dialogs
###################

.. toctree::
   :maxdepth: 1

   /manual/cmake-gui.1
   /manual/ccmake.1

Reference Manuals
#################

.. toctree::
   :maxdepth: 1

   /manual/cmake-buildsystem.7
   /manual/cmake-commands.7
   /manual/cmake-compile-features.7
   /manual/cmake-configure-log.7
   /manual/cmake-cxxmodules.7
   /manual/cmake-developer.7
   /manual/cmake-env-variables.7
   /manual/cmake-file-api.7
   /manual/cmake-generator-expressions.7
   /manual/cmake-generators.7
   /manual/cmake-language.7
   /manual/cmake-modules.7
   /manual/cmake-packages.7
   /manual/cmake-policies.7
   /manual/cmake-presets.7
   /manual/cmake-properties.7
   /manual/cmake-qt.7
   /manual/cmake-server.7
   /manual/cmake-toolchains.7
   /manual/cmake-variables.7
   /manual/cpack-generators.7

.. only:: not man

 Guides
 ######

 .. toctree::
    :maxdepth: 1

    /guide/tutorial/index
    /guide/user-interaction/index
    /guide/using-dependencies/index
    /guide/importing-exporting/index
    /guide/ide-integration/index

.. only:: html or text

 Release Notes
 #############

 .. toctree::
    :maxdepth: 1

    /release/index

.. only:: html

 Index and Search
 ################

 * :ref:`genindex`
 * :ref:`search`


code:
test:
	+ctest -j 8


code:
.. note::

  CMake reserves identifiers that:

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


code:
The following resources are available to get help using CMake:

Home Page
 https://cmake.org

 The primary starting point for learning about CMake.

Online Documentation and Community Resources
 https://cmake.org/documentation

 Links to available documentation and community resources may be
 found on this web page.

Discourse Forum
 https://discourse.cmake.org

 The Discourse Forum hosts discussion and questions about CMake.


code:
.. option:: -S <path-to-source>

 Path to root directory of the CMake project to build.

.. option:: -B <path-to-build>

 Path to directory which CMake will use as the root of build directory.

 If the directory doesn't already exist CMake will make it.

.. option:: -C <initial-cache>

 Pre-load a script to populate the cache.

 When CMake is first run in an empty build tree, it creates a
 ``CMakeCache.txt`` file and populates it with customizable settings for
 the project.  This option may be used to specify a file from which
 to load cache entries before the first pass through the project's
 CMake listfiles.  The loaded entries take priority over the
 project's default values.  The given file should be a CMake script
 containing :command:`set` commands that use the ``CACHE`` option, not a
 cache-format file.

 References to :variable:`CMAKE_SOURCE_DIR` and :variable:`CMAKE_BINARY_DIR`
 within the script evaluate to the top-level source and build tree.

.. option:: -D <var>:<type>=<value>, -D <var>=<value>

 Create or update a CMake ``CACHE`` entry.

 When CMake is first run in an empty build tree, it creates a
 ``CMakeCache.txt`` file and populates it with customizable settings for
 the project.  This option may be used to specify a setting that
 takes priority over the project's default value.  The option may be
 repeated for as many ``CACHE`` entries as desired.

 If the ``:<type>`` portion is given it must be one of the types
 specified by the :command:`set` command documentation for its
 ``CACHE`` signature.
 If the ``:<type>`` portion is omitted the entry will be created
 with no type if it does not exist with a type already.  If a
 command in the project sets the type to ``PATH`` or ``FILEPATH``
 then the ``<value>`` will be converted to an absolute path.

 This option may also be given as a single argument:
 ``-D<var>:<type>=<value>`` or ``-D<var>=<value>``.

 It's important to note that the order of ``-C`` and ``-D`` arguments is
 significant. They will be carried out in the order they are listed, with the
 last argument taking precedence over the previous ones. For example, if you
 specify ``-DCMAKE_BUILD_TYPE=Debug``, followed by a ``-C`` argument with a
 file that calls:

 .. code-block:: cmake

   set(CMAKE_BUILD_TYPE "Release" CACHE STRING "" FORCE)

 then the ``-C`` argument will take precedence, and ``CMAKE_BUILD_TYPE`` will
 be set to ``Release``. However, if the ``-D`` argument comes after the ``-C``
 argument, it will be set to ``Debug``.

 If a ``set(... CACHE ...)`` call in the ``-C`` file does not use ``FORCE``,
 and a ``-D`` argument sets the same variable, the ``-D`` argument will take
 precedence regardless of order because of the nature of non-``FORCE``
 ``set(... CACHE ...)`` calls.

.. option:: -U <globbing_expr>

 Remove matching entries from CMake ``CACHE``.

 This option may be used to remove one or more variables from the
 ``CMakeCache.txt`` file, globbing expressions using ``*`` and ``?`` are
 supported.  The option may be repeated for as many ``CACHE`` entries as
 desired.

 Use with care, you can make your ``CMakeCache.txt`` non-working.

.. option:: -G <generator-name>

 Specify a build system generator.

 CMake may support multiple native build systems on certain
 platforms.  A generator is responsible for generating a particular
 build system.  Possible generator names are specified in the
 :manual:`cmake-generators(7)` manual.

 If not specified, CMake checks the :envvar:`CMAKE_GENERATOR` environment
 variable and otherwise falls back to a builtin default selection.

.. option:: -T <toolset-spec>

 Toolset specification for the generator, if supported.

 Some CMake generators support a toolset specification to tell
 the native build system how to choose a compiler.  See the
 :variable:`CMAKE_GENERATOR_TOOLSET` variable for details.

.. option:: -A <platform-name>

 Specify platform name if supported by generator.

 Some CMake generators support a platform name to be given to the
 native build system to choose a compiler or SDK.  See the
 :variable:`CMAKE_GENERATOR_PLATFORM` variable for details.

.. option:: --toolchain <path-to-file>

 .. versionadded:: 3.21

 Specify the cross compiling toolchain file, equivalent to setting
 :variable:`CMAKE_TOOLCHAIN_FILE` variable.

.. option:: --install-prefix <directory>

 .. versionadded:: 3.21

 Specify the installation directory, used by the
 :variable:`CMAKE_INSTALL_PREFIX` variable. Must be an absolute path.

.. option:: -Wno-dev

 Suppress developer warnings.

 Suppress warnings that are meant for the author of the
 ``CMakeLists.txt`` files. By default this will also turn off
 deprecation warnings.

.. option:: -Wdev

 Enable developer warnings.

 Enable warnings that are meant for the author of the ``CMakeLists.txt``
 files. By default this will also turn on deprecation warnings.

.. option:: -Wdeprecated

 Enable deprecated functionality warnings.

 Enable warnings for usage of deprecated functionality, that are meant
 for the author of the ``CMakeLists.txt`` files.

.. option:: -Wno-deprecated

 Suppress deprecated functionality warnings.

 Suppress warnings for usage of deprecated functionality, that are meant
 for the author of the ``CMakeLists.txt`` files.

.. option:: -Werror=<what>

 Treat CMake warnings as errors. ``<what>`` must be one of the following:

 ``dev``
   Make developer warnings errors.

   Make warnings that are meant for the author of the ``CMakeLists.txt`` files
   errors. By default this will also turn on deprecated warnings as errors.

 ``deprecated``
  Make deprecated macro and function warnings errors.

  Make warnings for usage of deprecated macros and functions, that are meant
  for the author of the ``CMakeLists.txt`` files, errors.

.. option:: -Wno-error=<what>

 Do not treat CMake warnings as errors. ``<what>`` must be one of the following:

 ``dev``
  Make warnings that are meant for the author of the ``CMakeLists.txt`` files not
  errors. By default this will also turn off deprecated warnings as errors.

 ``deprecated``
  Make warnings for usage of deprecated macros and functions, that are meant
  for the author of the ``CMakeLists.txt`` files, not errors.


code:
.. |file| replace:: The output is printed to a named ``<file>`` if given.

.. option:: -version [<file>], --version [<file>], /V [<file>]

 Show program name/version banner and exit.
 |file|

.. option:: -h, -H, --help, -help, -usage, /?

 Print usage information and exit.

 Usage describes the basic command line interface and its options.

.. option:: --help <keyword> [<file>]

 Print help for one CMake keyword.

 ``<keyword>`` can be a property, variable, command, policy, generator
 or module.

 The relevant manual entry for ``<keyword>`` is
 printed in a human-readable text format.
 |file|

 .. versionchanged:: 3.28

   Prior to CMake 3.28, this option supported command names only.

.. option:: --help-full [<file>]

 Print all help manuals and exit.

 All manuals are printed in a human-readable text format.
 |file|

.. option:: --help-manual <man> [<file>]

 Print one help manual and exit.

 The specified manual is printed in a human-readable text format.
 |file|

.. option:: --help-manual-list [<file>]

 List help manuals available and exit.

 The list contains all manuals for which help may be obtained by
 using the ``--help-manual`` option followed by a manual name.
 |file|

.. option:: --help-command <cmd> [<file>]

 Print help for one command and exit.

 The :manual:`cmake-commands(7)` manual entry for ``<cmd>`` is
 printed in a human-readable text format.
 |file|

.. option:: --help-command-list [<file>]

 List commands with help available and exit.

 The list contains all commands for which help may be obtained by
 using the ``--help-command`` option followed by a command name.
 |file|

.. option:: --help-commands [<file>]

 Print cmake-commands manual and exit.

 The :manual:`cmake-commands(7)` manual is printed in a
 human-readable text format.
 |file|

.. option:: --help-module <mod> [<file>]

 Print help for one module and exit.

 The :manual:`cmake-modules(7)` manual entry for ``<mod>`` is printed
 in a human-readable text format.
 |file|

.. option:: --help-module-list [<file>]

 List modules with help available and exit.

 The list contains all modules for which help may be obtained by
 using the ``--help-module`` option followed by a module name.
 |file|

.. option:: --help-modules [<file>]

 Print cmake-modules manual and exit.

 The :manual:`cmake-modules(7)` manual is printed in a human-readable
 text format.
 |file|

.. option:: --help-policy <cmp> [<file>]

 Print help for one policy and exit.

 The :manual:`cmake-policies(7)` manual entry for ``<cmp>`` is
 printed in a human-readable text format.
 |file|

.. option:: --help-policy-list [<file>]

 List policies with help available and exit.

 The list contains all policies for which help may be obtained by
 using the ``--help-policy`` option followed by a policy name.
 |file|

.. option:: --help-policies [<file>]

 Print cmake-policies manual and exit.

 The :manual:`cmake-policies(7)` manual is printed in a
 human-readable text format.
 |file|

.. option:: --help-property <prop> [<file>]

 Print help for one property and exit.

 The :manual:`cmake-properties(7)` manual entries for ``<prop>`` are
 printed in a human-readable text format.
 |file|

.. option:: --help-property-list [<file>]

 List properties with help available and exit.

 The list contains all properties for which help may be obtained by
 using the ``--help-property`` option followed by a property name.
 |file|

.. option:: --help-properties [<file>]

 Print cmake-properties manual and exit.

 The :manual:`cmake-properties(7)` manual is printed in a
 human-readable text format.
 |file|

.. option:: --help-variable <var> [<file>]

 Print help for one variable and exit.

 The :manual:`cmake-variables(7)` manual entry for ``<var>`` is
 printed in a human-readable text format.
 |file|

.. option:: --help-variable-list [<file>]

 List variables with help available and exit.

 The list contains all variables for which help may be obtained by
 using the ``--help-variable`` option followed by a variable name.
 |file|

.. option:: --help-variables [<file>]

 Print cmake-variables manual and exit.

 The :manual:`cmake-variables(7)` manual is printed in a
 human-readable text format.
 |file|


code:
.. cmake-manual-description: CMake Curses Dialog Command-Line Reference

ccmake(1)
*********

Synopsis
========

.. parsed-literal::

 ccmake [<options>] -B <path-to-build> [-S <path-to-source>]
 ccmake [<options>] <path-to-source | path-to-existing-build>

Description
===========

The :program:`ccmake` executable is the CMake curses interface.  Project
configuration settings may be specified interactively through this
GUI.  Brief instructions are provided at the bottom of the terminal
when the program is running.

CMake is a cross-platform build system generator.  Projects specify
their build process with platform-independent CMake listfiles included
in each directory of a source tree with the name ``CMakeLists.txt``.
Users build a project by using CMake to generate a build system for a
native tool on their platform.

Options
=======

.. program:: ccmake

.. include:: OPTIONS_BUILD.txt

.. include:: OPTIONS_HELP.txt

See Also
========

.. include:: LINKS.txt