Command-Line Build Tool Generators

Makefile Generators

Borland Makefiles

MSYS Makefiles

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 MinGW Makefiles generator.

MinGW Makefiles

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 MSYS Makefiles generator.

NMake Makefiles

NMake Makefiles JOM

New in version 3.8: CodeBlocks generator can be used as an extra generator.

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:

Watcom WMake

Ninja Generators

Ninja

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

sub/dir/install

sub/dir/install/strip

sub/dir/test

sub/dir/package

Fortran Support

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

Swift Support

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

See Also

Ninja Multi-Config

Generates multiple build-<Config>.ninja files.

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

Unlike the Ninja generator, Ninja Multi-Config generates multiple configurations at once with CMAKE_CONFIGURATION_TYPES instead of only one configuration with 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 CMAKE_DEFAULT_BUILD_TYPE or the first item from CMAKE_CONFIGURATION_TYPES.

cmake --build . --config <Config> will always use build-<Config>.ninja to build. If no --config argument is specified, 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:

Consider the following example:

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:

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 CMAKE_CROSS_CONFIGS is set to all, and you run the following instead:

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

The Ninja Multi-Config generator adds extra capabilities to add_custom_command() and 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 $<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 $<OUTPUT_CONFIG:...> and $<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 $<OUTPUT_CONFIG:...> (because its plain name is not a generator expression).

As an example, consider the following:

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:

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.

IDE Build Tool Generators

Visual Studio Generators

Visual Studio 6

Visual Studio 7

Visual Studio 7 .NET 2003

Visual Studio 8 2005

Visual Studio 9 2008

Platform Selection

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

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 10 2010

NOTE:

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

Project Types

Platform Selection

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

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:

Toolset Selection

Visual Studio 11 2012

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

Platform Selection

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

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:

Toolset Selection

Visual Studio 12 2013

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

Platform Selection

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

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:

Toolset Selection

New in version 3.8: For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 32-bit variant even on a 64-bit host. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

New in version 3.14: Added support for host=x86 option.

Visual Studio 14 2015

Generates Visual Studio 14 (VS 2015) project files.

Project Types

Platform Selection

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

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:

Toolset Selection

New in version 3.8: For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 32-bit variant even on a 64-bit host. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

New in version 3.14: Added support for host=x86 option.

Windows 10 SDK Maximum Version for VS 2015

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 CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM to a false value or setting the CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM to the string value of the required maximum (e.g. 10.0.15063.0).

Visual Studio 15 2017

Generates Visual Studio 15 (VS 2017) project files.

Project Types

Instance Selection

VS 2017 supports multiple installations on the same machine. The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance. If the value is not specified explicitly by the user or a toolchain file, CMake queries the Visual Studio Installer to locate VS instances, chooses one, and sets the variable as a cache entry to hold the value persistently.

When CMake first chooses an instance, if the VS150COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.

Platform Selection

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

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:

Toolset Selection

New in version 3.8: For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 32-bit variant even on a 64-bit host. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

New in version 3.14: Added support for host=x86 option.

Visual Studio 16 2019

Generates Visual Studio 16 (VS 2019) project files.

Project Types

Instance Selection

When CMake first chooses an instance, if the VS160COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.

Platform Selection

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

Toolset Selection

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). By default this generator uses the 64-bit variant on x64 hosts and the 32-bit variant otherwise. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

Visual Studio 17 2022

Generates Visual Studio 17 (VS 2022) project files.

Project Types

Instance Selection

When CMake first chooses an instance, if the VS170COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.

Platform Selection

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

Toolset Selection

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). By default this generator uses the 64-bit variant on x64 hosts and the 32-bit variant otherwise. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

Other Generators

Green Hills MULTI

New in version 3.15: Linux support.

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

Customizations are available through the following cache variables:

New in version 3.14: The buildsystem has predetermined build-configuration settings that can be controlled via the CMAKE_BUILD_TYPE variable.

Toolset and Platform Selection

Customizations that are used to pick toolset and target system:

Cache variables that are used for toolset and target system customization:

Target Properties

The following properties are available:

NOTE:

Xcode

Changed in version 3.15: This generator supports Xcode 5.0 and above.

Toolset and Build System Selection

New in version 3.19: This generator supports toolset specification using one of these forms:

The toolset specifies the toolset name. The selected toolset name is provided in the 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:

Swift Support

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

CodeBlocks

Project files for CodeBlocks will be created in the top directory and in every subdirectory which features a CMakeLists.txt file containing a 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.

New in version 3.10: The 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:

CodeLite

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

New in version 3.7: The 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:

Eclipse CDT4

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:

Kate

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:

Sublime Text 2

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 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: