This commit is contained in:
kleuter
2023-11-01 21:39:10 +01:00
parent 5c4154eda2
commit 94b1c5907b
3387 changed files with 0 additions and 0 deletions

View File

@ -0,0 +1,4 @@
Borland Makefiles
-----------------
Generates Borland makefiles.

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,7 @@
NMake Makefiles JOM
-------------------
Generates JOM makefiles.
.. versionadded:: 3.8
:generator:`CodeBlocks` generator can be used as an extra generator.

View File

@ -0,0 +1,4 @@
NMake Makefiles
---------------
Generates NMake makefiles.

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,8 @@
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 12 2013`
(or above) generator with :variable:`CMAKE_GENERATOR_TOOLSET` set to
``v100``, or by using the :generator:`NMake Makefiles` generator.

View File

@ -0,0 +1,57 @@
Visual Studio 11 2012
---------------------
Deprecated. Generates Visual Studio 11 (VS 2012) 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 11 2012 tools
using the :generator:`Visual Studio 12 2013` (or above) generator
with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v110``, 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 11" 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,
Database, Website, 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 11 2012" -A Win32``
* ``cmake -G "Visual Studio 11 2012" -A x64``
* ``cmake -G "Visual Studio 11 2012" -A ARM``
* ``cmake -G "Visual Studio 11 2012" -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 11 2012 Win64``
Specify target platform ``x64``.
``Visual Studio 11 2012 ARM``
Specify target platform ``ARM``.
``Visual Studio 11 2012 <WinCE-SDK>``
Specify target platform matching a Windows CE SDK name.
Toolset Selection
^^^^^^^^^^^^^^^^^
The ``v110`` toolset that comes with Visual Studio 11 2012 is selected by
default. The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
via the :option:`cmake -T` option, to specify another toolset.

View File

@ -0,0 +1,50 @@
Visual Studio 12 2013
---------------------
Generates Visual Studio 12 (VS 2013) project files.
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

View File

@ -0,0 +1,66 @@
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``).

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,41 @@
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 12 2013` 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.

View File

@ -0,0 +1,4 @@
Watcom WMake
------------
Generates Watcom WMake makefiles.

View File

@ -0,0 +1,56 @@
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)