CMAKE-GENERATORS(7)

💖 `cmake-generators(7)` — CMake Generators Reference 💖

okay bestie, this is the CMake Generators Reference — the manual page that explains who actually writes the files that make ur build go brrr. 💅

🌸 NAME 🌸

cmake-generators — CMake Generators Reference

🦋 INTRODUCTION 🦋

okay so real talk: a CMake Generator is responsible for writing the input files for a native build system. For a build tree, exactly one of the CMake Generators must be selected — that's what tells CMake which native build system is gonna be used. Optionally, one of the Extra Generators may be selected as a variant of some of the Command-Line Build Tool Generators, so you can also produce project files for an auxiliary IDE. ✨

CMake Generators are platform-specific, so each may be available only on certain platforms. The cmake(1) command-line tool --help output lists the available generators on the current platform. Use its -G option to specify the generator for a new build tree. And cmake-gui(1) offers interactive selection of a generator when creating a new build tree. 🫶

🌈 CMAKE GENERATORS 🌈

🧵 Command-Line Build Tool Generators

These generators support command-line build tools. To use them, you must launch CMake from a command-line prompt whose environment is already configured for the chosen compiler and build tool. no cap, the environment part matters. ⭐

🧸 Makefile Generators

Borland Makefiles

Generates Borland makefiles. simple as that. 💖

MSYS Makefiles

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

Use this generator in a MSYS shell prompt and use 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 instead.

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

NMake Makefiles

Generates NMake makefiles. iconic Windows build tool behavior. 🎀

NMake Makefiles JOM

Generates JOM makefiles.

Added in version 3.8: the CodeBlocks generator can be used as an extra generator. 🦋

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.

Watcom WMake

Generates Watcom WMake makefiles. periodt. 💅

🔥 Ninja Generators

Ninja

Generates a build.ninja file into the build tree. ninja girlies rise. 🥷

Builtin Targets

Inside the Ninja generator, these builtin targets are a whole thing:

all — Depends on all targets required by the project, except those with EXCLUDE_FROM_ALL set to true.
install — Runs the install step.
install/strip — Added in version 3.7: Runs the install 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. ✨
install/parallel — Added in version 3.30: Created only if the INSTALL_PARALLEL global property is ON. Runs the install step for each subdirectory independently and in parallel. parallel install is lowkey a vibe. ⚡
test_prep/<test-name> — Added in version 4.4: Created only if the CMAKE_TEST_BUILD_DEPENDS variable is enabled. Builds all known build dependencies for the named test, including the executable target invoked by the test, targets referenced by generator expressions in the test command, and explicit BUILD_DEPENDS entries. Tests with names that are not valid target names are excluded. If multiple tests in different directories share the same name, their dependencies are merged into one test_prep/<test-name> target. 🧪
test_prep/all — Added in version 4.4: Created only if the CMAKE_TEST_BUILD_DEPENDS variable is enabled. Depends on every generated test_prep/<test-name> target.

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

sub/dir/all — Added in version 3.6: Depends on all targets required by the subdirectory.
sub/dir/install — Added in version 3.7: Runs the install step in the subdirectory, if any.
sub/dir/install/strip — Added in version 3.7: Runs the install step in the subdirectory followed by a CMAKE_STRIP command, if any.
sub/dir/test — Added in version 3.7: Runs the test step in the subdirectory, if any.
sub/dir/package — Added in version 3.7: Runs the package step in the subdirectory, if any.

Fortran Support

Added in version 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

Added in version 3.15.

The Swift support is experimental, not considered stable, and may change in future releases of CMake. so like, don't build ur whole personality on it yet. 🙈

🦋 Ninja Multi-Config

Added in version 3.17.

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:

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.
CMAKE_CROSS_CONFIGS — Specifies a semicolon-separated list of configurations available from all build-<Config>.ninja files.
CMAKE_DEFAULT_BUILD_TYPE — Specifies the configuration to use by default in a build.ninja file.
CMAKE_DEFAULT_CONFIGS — Specifies a semicolon-separated list of configurations to build for a target in build.ninja if no :<Config> suffix is specified.

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

Added in version 3.20.

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's shared across more than one configuration (like, it doesn't use any generator expressions at all), then every argument gets evaluated in the command config by default. But if all your OUTPUT and BYPRODUCTS paths are unique per config (say you used the $<CONFIG> <#genex:CONFIG> generator expression — queen behaviour 💅), then the first argument of COMMAND is still evaluated in the command config by default, while everything after it — plus the arguments to DEPENDS and WORKING_DIRECTORY — gets evaluated in the output config. You can override both of these defaults with the $<OUTPUT_CONFIG:...> <#genex:OUTPUT_CONFIG> and $<COMMAND_CONFIG:...> <#genex:COMMAND_CONFIG> generator expressions.

Heads up bestie 👀: if a target is named in DEPENDS by its plain name, or it's the first argument of COMMAND, it's always evaluated in the command config — even if you wrap it in $<OUTPUT_CONFIG:...> <#genex:OUTPUT_CONFIG>. That's because its plain name isn't a generator expression. Periodt.

So like, picture this:

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>>"
  )

Now assume generator, tgt1, tgt2, tgt3, and tgt4 are all executable targets, and assume $<CONFIG>.txt is built in the Debug output config using the Release command config. What happens? The Release build of the generator target gets called with Debug.txt Debug Release as its arguments. And the command depends on the Release builds of tgt1 and tgt4, plus the Debug builds of tgt2 and tgt3. Slay, it all lines up ✨

PRE_BUILD, PRE_LINK, and POST_BUILD custom commands for targets only run in their "native" configuration (that's the Release configuration in the build-Release.ninja file) unless they have no BYPRODUCTS, or their BYPRODUCTS are unique per config. Check this out:

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 run (their byproducts are unique per-config, so they're valid 💖) but the last one doesn't. However — plot twist — if you build exe:Release in build-Release.ninja, all three custom commands get run. The more you know 🌈

🌸 FASTBuild Generator 🌸

FASTBuild

Added in version 4.2.

Generates a fbuild.bff file, which you can use to build the project with FASTBuild <https://www.fastbuild.org/docs/home.html>. We love a niche generator moment 🔥

Usage

Just specify the generator when you invoke cmake(1) <#manual:cmake(1)>:

cmake [<options>] -G FASTBuild -B <path-to-build> [-S <path-to-source>]

That writes a FASTBuild configuration file named fbuild.bff into <path-to-build>. Easy peasy 🍓

Note: this generator also produces IDE project files for Visual Studio and Xcode 😭 which get placed under: - <path-to-build>/VisualStudio — Visual Studio solution and projects - <path-to-build>/XCode — Xcode workspace and projects You can generate these IDE files by building the xcode or solution targets, and they'll build using FASTBuild as the backend. Iconic crossover episode ngl 👑

Caching

To enable FASTBuild caching, set the cache path using the CMAKE_FASTBUILD_CACHE_PATH <#variable:CMAKE_FASTBUILD_CACHE_PATH> variable, or the FASTBUILD_CACHE_PATH environment variable.

Then build with the -cache flag:

cmake --build <path-to-build> -- -cache

Compiler Behavior Variables

These next ones control how compiler nodes get emitted in the generated fbuild.bff. Heads up: they can affect build determinism, debug info paths, include handling, and compiler argument formatting 👀

CMAKE_FASTBUILD_ALLOW_RESPONSE_FILE <#variable:CMAKE_FASTBUILD_ALLOW_RESPONSE_FILE>
CMAKE_FASTBUILD_CLANG_GCC_UPDATE_XLANG_ARG <#variable:CMAKE_FASTBUILD_CLANG_GCC_UPDATE_XLANG_ARG>
CMAKE_FASTBUILD_CLANG_REWRITE_INCLUDES <#variable:CMAKE_FASTBUILD_CLANG_REWRITE_INCLUDES>
CMAKE_FASTBUILD_COMPILER_EXTRA_FILES <#variable:CMAKE_FASTBUILD_COMPILER_EXTRA_FILES>
CMAKE_FASTBUILD_FORCE_RESPONSE_FILE <#variable:CMAKE_FASTBUILD_FORCE_RESPONSE_FILE>
CMAKE_FASTBUILD_SOURCE_MAPPING <#variable:CMAKE_FASTBUILD_SOURCE_MAPPING>
CMAKE_FASTBUILD_USE_DETERMINISTIC_PATHS <#variable:CMAKE_FASTBUILD_USE_DETERMINISTIC_PATHS>
CMAKE_FASTBUILD_USE_LIGHTCACHE <#variable:CMAKE_FASTBUILD_USE_LIGHTCACHE>
CMAKE_FASTBUILD_USE_RELATIVE_PATHS <#variable:CMAKE_FASTBUILD_USE_RELATIVE_PATHS>

Configuration Variables

And these ones configure the generator itself:

CMAKE_FASTBUILD_CACHE_PATH <#variable:CMAKE_FASTBUILD_CACHE_PATH>
CMAKE_FASTBUILD_CAPTURE_SYSTEM_ENV <#variable:CMAKE_FASTBUILD_CAPTURE_SYSTEM_ENV>
CMAKE_FASTBUILD_ENV_OVERRIDES <#variable:CMAKE_FASTBUILD_ENV_OVERRIDES>
CMAKE_FASTBUILD_IDE_ARGS <#variable:CMAKE_FASTBUILD_IDE_ARGS>
CMAKE_FASTBUILD_TRACK_BYPRODUCTS_AS_OUTPUT <#variable:CMAKE_FASTBUILD_TRACK_BYPRODUCTS_AS_OUTPUT>
CMAKE_FASTBUILD_VERBOSE_GENERATOR <#variable:CMAKE_FASTBUILD_VERBOSE_GENERATOR>

Target Properties

Wanna fine-tune stuff per-target? These target properties got you:

FASTBUILD_CACHING <#prop_tgt:FASTBUILD_CACHING> — disables caching for a specific target.
FASTBUILD_DISTRIBUTION <#prop_tgt:FASTBUILD_DISTRIBUTION> — disables distributed compilation for a specific target.

Notes

This generator does not support directories as outputs of custom commands 😬 if you do specify a directory as an output, mark it with the SYMBOLIC property so you don't get incorrect behaviour. Fr fr, don't skip this one.
It is highly advised to use custom commands with only one output. If you specify multiple outputs, the generator emits an additional rule to check the outputs at build time. That's extra overhead, and it's necessary because FASTBuild natively supports only a single output per custom step. That's just how it is 💀

Example

cmake [<options>] -G FASTBuild -B <path-to-build> -DCMAKE_BUILD_TYPE=Release
cmake --build <path-to-build> --target my_app

This generates fbuild.bff in <path-to-build> and uses FASTBuild to build the my_app target. Go off ✨

🎀 IDE Build Tool Generators 🎀

These generators support Integrated Development Environment (IDE) project files. And since the IDEs configure their own environment, you can launch CMake from literally any environment. Vibe check: passed ✅

Visual Studio Generators

Visual Studio 6

Removed. This once generated Visual Studio 6 project files, but the generator has been removed since CMake 3.6. It's still possible to build with VS 6 tools using the NMake Makefiles <#generator:NMake Makefiles> generator. RIP boo 🕯️

Visual Studio 7

Removed. This once generated Visual Studio .NET 2002 project files, but the generator has been removed since CMake 3.6. It's still possible to build with VS 7.0 tools using the NMake Makefiles <#generator:NMake Makefiles> generator. Another one gone 😭

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's still possible to build with VS 7.1 tools using the NMake Makefiles <#generator:NMake Makefiles> generator.

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's still possible to build with VS 2005 tools using the NMake Makefiles <#generator:NMake Makefiles> generator.

Visual Studio 9 2008

Removed. This once generated Visual Studio 9 2008 project files, but the generator has been removed since CMake 3.30. It's still possible to build with the VS 9 2008 toolset by also installing VS 10 2010 and VS 2017 (or above) and using the Visual Studio 15 2017 <#generator:Visual Studio 15 2017> generator (or above) with CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> set to v90 — or, you know, just use the NMake Makefiles <#generator:NMake Makefiles> generator. Either works 💅

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's still possible to build with the VS 10 2010 toolset by also installing VS 2017 (or above) and using the Visual Studio 15 2017 <#generator:Visual Studio 15 2017> (or above) generator with CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> set to v100, or by using the NMake Makefiles <#generator:NMake Makefiles> generator.

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's still possible to build with the VS 11 2012 toolset by also installing VS 2017 (or above) and using the Visual Studio 15 2017 <#generator:Visual Studio 15 2017> (or above) generator with CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> set to v110, or by using the NMake Makefiles <#generator:NMake Makefiles> generator.

Visual Studio 12 2013

Removed. This once generated Visual Studio 12 2013 project files, but the generator has been removed since CMake 3.31. It's still possible to build with the VS 12 2013 toolset by also installing VS 2017 (or above) and using the Visual Studio 15 2017 <#generator:Visual Studio 15 2017> (or above) generator with CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> set to v120, or by using the NMake Makefiles <#generator:NMake Makefiles> generator.

Visual Studio 14 2015

Deprecated since version 4.2: this generator is deprecated and will be removed in a future version of CMake 😭 It'll still be possible to build with VS 14 2015 tools using the Visual Studio 15 2017 <#generator:Visual Studio 15 2017> (or above) generator with CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> set to v140, or by using the NMake Makefiles <#generator:NMake Makefiles> generator.

Added in version 3.1.

Generates Visual Studio 14 (VS 2015) project files. Old but still hanging in there 🫶

Project Types

okay so real talk bestie — only Visual C++ and C# projects may be generated here (and Fortran, but only with Intel compiler integration ✨). Any other type of project — JavaScript, Powershell, Python, etc. — is just not supported 💀 don't come for me, that's literally just how it is.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set — perhaps via the cmake -A option — to specify a target platform name (architecture). Like, 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

🚨 Changed in version 4.0: bestie, this is a removal. Previously, for compatibility with CMake versions prior to 3.1, you could optionally stick a target platform name at the end of the generator name. That is gone now. It was only ever supported for these two: - 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 CMAKE_GENERATOR_TOOLSET option may be set — perhaps via the cmake -T option — to specify another toolset.

✨ Added 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 — and yes, that's independent of the architecture they target, don't get it twisted. By default this generator uses the 32-bit variant even on a 64-bit host. You can explicitly request 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.

💜 Added in version 3.14: support for the host=x86 option was added. slay.

Windows 10 SDK Maximum Version for VS 2015

Added in version 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. So by default CMake automatically ignores Windows 10 SDKs beyond 10.0.14393.0.

But 👀 there are other recommendations for certain driver/Win32 builds that indicate otherwise. A user can override this behavior by either setting CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM to a false value, or by setting 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

Added in version 3.7.1.

Generates Visual Studio 15 (VS 2017) project files. iconic behaviour ngl 💅

Project Types

Same deal as always: 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

Added in version 3.11.

VS 2017 supports multiple installations on the same machine, which is lowkey a lot. The CMAKE_GENERATOR_INSTANCE variable may be used to select one 🫶

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set — perhaps via the 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

🚨 Changed in version 4.0: previously, for compatibility with CMake versions prior to 3.1, you could optionally specify a target platform name at the end of the generator name. Removed. This was 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 CMAKE_GENERATOR_TOOLSET option may be set — perhaps via the cmake -T option — to specify another toolset.

✨ Added 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.

💜 Added in version 3.14: added support for the host=x86 option.

🦋 Visual Studio 16 2019

Added in version 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 CMAKE_GENERATOR_INSTANCE variable may be used to select one.

Platform Selection

The default target platform name (architecture) is that of the host, and it's provided in the CMAKE_VS_PLATFORM_NAME_DEFAULT variable 👑

The CMAKE_GENERATOR_PLATFORM variable may be set — perhaps via the 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 CMAKE_GENERATOR_TOOLSET option may be set — perhaps via the cmake -T option — to specify another toolset.

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 — note the glow-up from the older ones, bestie 💅 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

Added in version 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 CMAKE_GENERATOR_INSTANCE variable may be used to select one.

Platform Selection

The default target platform name (architecture) is that of the host, and it's provided in the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.

The CMAKE_GENERATOR_PLATFORM variable may be set — perhaps via the 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 CMAKE_GENERATOR_TOOLSET option may be set — perhaps via the cmake -T option — to specify another toolset.

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 18 2026

Added in version 4.2.

Generates Visual Studio 18 (VS 2026) 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 2026 supports multiple installations on the same machine. The CMAKE_GENERATOR_INSTANCE variable may be used to select one.

Platform Selection

The default target platform name (architecture) is that of the host, and it's provided in the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.

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

cmake -G "Visual Studio 18 2026" -A Win32
cmake -G "Visual Studio 18 2026" -A x64
cmake -G "Visual Studio 18 2026" -A ARM
cmake -G "Visual Studio 18 2026" -A ARM64

Toolset Selection

The v145 toolset that comes with VS 18 2026 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set — perhaps via the cmake -T option — to specify another toolset.

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

okay now we're leaving Visual Studio territory, bestie — this is where the other icons live 👑

Green Hills MULTI

Added in version 3.3.

🌈 Added in version 3.15: Linux support.

okay so this one spits out Green Hills MULTI project files — and ngl it's experimental, work-in-progress energy 🙈 like it works but it's still glowin' up, yk?

the buildsystem has predetermined build-configuration settings that you can control via the CMAKE_BUILD_TYPE variable. slay.

🌸 Platform Selection

Added in version 3.13.

the GHS_PRIMARY_TARGET variable is your girl for picking the target platform — it sets the primaryTarget entry in the project file.

for example:

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

otherwise, primaryTarget gets composed from the values of CMAKE_GENERATOR_PLATFORM and GHS_TARGET_PLATFORM. and if nobody says anything? it defaults to arm_integrity.tgt 💅

the CMAKE_GENERATOR_PLATFORM variable may be set, maybe through the cmake -A option. typical values like arm, ppc, 86, etcetera, get used here.
the GHS_TARGET_PLATFORM variable may be set, maybe through the cmake -D option. defaults to integrity. the usual suspects are integrity, threadx, uvelosity, velosity, vxworks, standalone.

for example:

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

🛠️ Toolset Selection

Added in version 3.13.

the generator goes hunting for the latest compiler, or you can just hand it a location to use. GHS_TOOLSET_ROOT is the directory that gets checked for the latest compiler. 🕵️‍♀️

the CMAKE_GENERATOR_TOOLSET option may be set, maybe via the cmake -T option, to specify where the toolset lives. both absolute and relative paths are valid — relative paths are relative to GHS_TOOLSET_ROOT.
the GHS_TOOLSET_ROOT variable may be set, maybe via the cmake -D option. it's the 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 the 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 CMAKE_GENERATOR_TOOLSET should use CMake style paths. no cap, just use CMake style paths bestie.

🧚 OS and BSP Selection

Added in version 3.3.

certain target platforms, like Integrity, literally require an OS. the RTOS directory path can be explicitly set using GHS_OS_DIR. otherwise GHS_OS_ROOT gets searched for the latest Integrity RTOS.

if the target platform — again, like Integrity — requires a BSP name, then you set it via the GHS_BSP_NAME variable.

GHS_OS_DIR and GHS_OS_DIR_OPTION sets the -os_dir entry in the project file.

the GHS_OS_DIR_OPTION default value is -os_dir.

added in version 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 the -bsp entry in the 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

Added in version 3.14.

the following properties are available:

GHS_INTEGRITY_APP
GHS_NO_SOURCE_GROUP_FILE

🎀 MULTI Project Variables

Added in version 3.3.

adding a Customization file and macros are available through the use of these 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 4.4.5 and is still a work in progress. future versions of CMake may make breaking changes as the generator matures. so like... don't be shocked if things shift 💀

🍎 Xcode

generates Xcode project files.

changed in version 3.15: this generator supports Xcode 5.0 and above.

🔧 Toolset and Build System Selection

by default, Xcode is allowed to select its own default toolchain. the CMAKE_GENERATOR_TOOLSET option may be set — maybe via the cmake -T option — to specify another toolset.

added in version 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 gets provided in the CMAKE_XCODE_PLATFORM_TOOLSET variable. ✨

the key=value pairs form a comma-separated list of options that specify generator-specific details of the toolset selection. the supported pairs are:

buildsystem=<variant> — specify the buildsystem variant to use. see the CMAKE_XCODE_BUILD_SYSTEM variable for the allowed values.

for example, to select the original build system under Xcode 12, run cmake(1) with the option -T buildsystem=1.

🦋 Swift Support

Added in version 3.4.

when you're using the Xcode generator with Xcode 6.1 or higher, you may enable the Swift language with the enable_language() command or the project() command. cute, right?

💀 Limitations

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

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

so yeah, don't do that 🙈

💅 EXTRA GENERATORS 💅

⚠️ Deprecated since version 3.27: Support for "Extra Generators" is deprecated and will be removed from a future version of CMake. IDEs may use the cmake-file-api(7) to view CMake-generated project build trees. bestie, this whole section is on its way out — enjoy it while it lasts 😭

Some of the CMake Generators listed in the cmake(1) command-line tool --help output may have variants that specify an extra generator for an auxiliary IDE tool. Such generator names have the form <extra-generator> - <main-generator>. So like, ExtraThing - Ninja, with the little dash as the glue ✨ The following extra generators are known to CMake.

🧱 CodeBlocks

⚠️ Deprecated since version 3.27: Support for Extra Generators is deprecated and will be removed from a future version of CMake. IDEs may use the 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 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. iconic behavior ngl 💅

Added 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. lowkey so useful 🎀

This "extra" generator may be specified as:

CodeBlocks - MinGW Makefiles — Generate with MinGW Makefiles.
CodeBlocks - NMake Makefiles — Generate with NMake Makefiles.
CodeBlocks - NMake Makefiles JOM — Added in version 3.8: Generate with NMake Makefiles JOM.
CodeBlocks - Ninja — Generate with Ninja.
CodeBlocks - Unix Makefiles — Generate with Unix Makefiles.

🍋 CodeLite

⚠️ Deprecated since version 3.27: Support for Extra Generators is deprecated and will be removed from a future version of CMake. IDEs may use the 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 project() call. The appropriate make program can build the project through the default all target. An install target is also provided. fr fr, same deal as above 🫶

Added 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. a whole lil vibe shift 💫

This "extra" generator may be specified as:

CodeLite - MinGW Makefiles — Generate with MinGW Makefiles.
CodeLite - NMake Makefiles — Generate with NMake Makefiles.
CodeLite - Ninja — Generate with Ninja.
CodeLite - Unix Makefiles — Generate with Unix Makefiles.

🌘 Eclipse CDT4

⚠️ Deprecated since version 3.27: Support for Extra Generators is deprecated and will be removed from a future version of CMake. IDEs may use the 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 MinGW Makefiles.
Eclipse CDT4 - NMake Makefiles — Generate with NMake Makefiles.
Eclipse CDT4 - Ninja — Generate with Ninja.
Eclipse CDT4 - Unix Makefiles — Generate with Unix Makefiles.

📝 Kate

⚠️ Deprecated since version 3.27: Support for Extra Generators is deprecated and will be removed from a future version of CMake. IDEs may use the 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. the way that just works 😭💖

This "extra" generator may be specified as:

Kate - MinGW Makefiles — Generate with MinGW Makefiles.
Kate - NMake Makefiles — Generate with NMake Makefiles.
Kate - Ninja — Generate with Ninja.
Kate - Ninja Multi-Config — Generate with Ninja Multi-Config.
Kate - Unix Makefiles — Generate with Unix Makefiles.

🦋 Sublime Text 2

⚠️ Deprecated since version 3.27: Support for Extra Generators is deprecated and will be removed from a future version of CMake. IDEs may use the 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 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. retro but make it slay 🎀

This "extra" generator may be specified as:

Sublime Text 2 - MinGW Makefiles — Generate with MinGW Makefiles.
Sublime Text 2 - NMake Makefiles — Generate with NMake Makefiles.
Sublime Text 2 - Ninja — Generate with Ninja.
Sublime Text 2 - Unix Makefiles — Generate with Unix Makefiles.

👑 Copyright 👑

2000-2026 Kitware, Inc. and Contributors — respect the OGs, they literally built all of this 💜

and that's a wrap bestie!! 🫶 This lil masterpiece is from the CMAKE-GENERATORS(7) manual, version 4.4.5, dated Oct 28, 2026. go build something iconic, ily, bye 💅✨🍓

📦 where this page comes from

arch rolling: cmake 4.4.5-1 · BSD-3-Clause
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

CMAKE-GENERATORS(7)

💖 cmake-generators(7) — CMake Generators Reference 💖

🌸 NAME 🌸

🦋 INTRODUCTION 🦋

🌈 CMAKE GENERATORS 🌈

🧵 Command-Line Build Tool Generators

🧸 Makefile Generators

Borland Makefiles

MSYS Makefiles

MinGW Makefiles

NMake Makefiles

NMake Makefiles JOM

Unix Makefiles

Watcom WMake

🔥 Ninja Generators

Ninja

Builtin Targets

Fortran Support

Swift Support

See Also

🦋 Ninja Multi-Config

🎀 Custom Commands

🌸 FASTBuild Generator 🌸

FASTBuild

Usage

Caching

Compiler Behavior Variables

Configuration Variables

Target Properties

Notes

Example

See Also

🎀 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

Visual Studio 10 2010

Visual Studio 11 2012

Visual Studio 12 2013

Visual Studio 14 2015

Project Types

Platform Selection

Toolset Selection

Windows 10 SDK Maximum Version for VS 2015

🌈 Visual Studio 15 2017

Project Types

Instance Selection

Platform Selection

Toolset Selection

🦋 Visual Studio 16 2019

Project Types

Instance Selection

Platform Selection

Toolset Selection

🎀 Visual Studio 17 2022

Project Types

Instance Selection

Platform Selection

Toolset Selection

🧚 Visual Studio 18 2026

Project Types

Instance Selection

Platform Selection

Toolset Selection

🌸 Other Generators

Green Hills MULTI

🌸 Platform Selection

🛠️ Toolset Selection

🧚 OS and BSP Selection

💖 Target Properties

🎀 MULTI Project Variables

🍎 Xcode

🔧 Toolset and Build System Selection

🦋 Swift Support

💀 Limitations

💅 EXTRA GENERATORS 💅

🧱 CodeBlocks

💖 `cmake-generators(7)` — CMake Generators Reference 💖