cmake-generators

title: cmake-generators(7)

summary: CMake Generators Reference

text:
# cmake-generators(7)

## NAME
cmake-generators - CMake Generators Reference

## INTRODUCTION
A CMake Generator is responsible for writing the input files for a native build system. Exactly one of the CMake Generators must be selected for a build tree to determine what native build system is to be used. Optionally one of the Extra Generators may be selected as a variant of some of the Command-Line Build Tool Generators to 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 available generators on the current platform. Use its -G option to specify the generator for a new build tree. The 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. In order to use them, one must launch CMake from a command-line prompt whose environment is already configured for the chosen compiler and build tool.

### Borland Makefiles
Generates Borland makefiles.

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

### 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.

### NMake Makefiles
Generates NMake makefiles.

### NMake Makefiles JOM
Generates JOM makefiles.

New in version 3.8: 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.

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

New in version 3.6: Depends on all targets required by the subdirectory.

sub/dir/install

New in version 3.7: Runs the install step in the subdirectory, if any.

sub/dir/install/strip

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

New in version 3.7: Runs the test step in the subdirectory, if any.

sub/dir/package

New in version 3.7: Runs the package step in the subdirectory, if any.

### Fortran Support
New 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
New in version 3.15.

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

### See Also
New in version 3.17: The Ninja Multi-Config generator is similar to the Ninja generator, but generates multiple configurations at once.

### Ninja Multi-Config
New 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
New 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 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
These generators support Integrated Development Environment (IDE) project files. Since the IDEs configure their own environment one may launch CMake from any environment.

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

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

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

### Visual Studio 9 2008
Generates Visual Studio 9 2008 project files.

### Platform Selection
The default target platform name (architecture) is Win32.

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:

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

### Visual Studio 10 2010
Deprecated. Generates Visual Studio 10 (VS 2010) 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 10 2010 tools using the Visual Studio 11 2012 (or above) generator with CMAKE_GENERATOR_TOOLSET set to v100, or by using the NMake Makefiles generator.

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
Only Visual C++ and C# projects may be generated (and Fortran with Intel compiler integration). Other types of projects (Database, Website, etc.) are not supported.

### Platform Selection
The default target platform name (architecture) is Win32.

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:

- cmake -G "Visual Studio 10 2010" -A Win32

- cmake -G "Visual Studio 10 2010" -A x64

- cmake -G "Visual Studio 10 2010" -A Itanium

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 Win64

Specify target platform x64.

Visual Studio 10 2010 IA64

Specify target platform Itanium.

### Toolset Selection
The v100 toolset that comes with Visual Studio 10 2010 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

### Visual Studio 11 2012
Generates Visual Studio 11 (VS 2012) project files.

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.

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:

- 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 CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

### 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.

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:

- 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 CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

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
New in version 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 CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -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 CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

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
New 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. 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
New in version 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
New in version 3.11.

VS 2017 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 Win32.

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

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
New 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 is provided in the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -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(1) -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 17 2022
New 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 is provided in the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -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(1) -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.

### Green Hills MULTI
New in version 3.3.

New in version 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 CMAKE_BUILD_TYPE variable.

### Platform Selection
New in version 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 CMAKE_GENERATOR_PLATFORM and GHS_TARGET_PLATFORM. Defaulting to the value of arm_integrity.tgt

- The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option.

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

- The variable GHS_TARGET_PLATFORM may be set, perhaps via the cmake(1) -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
New in version 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 CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -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 cmake(1) -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 CMAKE_GENERATOR_TOOLSET should use CMake style paths.

### OS and BSP Selection
New in version 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.
```

New 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 -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
New in version 3.14.

The following properties are available:

- GHS_INTEGRITY_APP

- GHS_NO_SOURCE_GROUP_FILE

### MULTI Project Variables
New in version 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 3.23.2 and is still a work in progress. Future versions of CMake may make breaking changes as the generator matures.

### Xcode
Generate 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, perhaps via the cmake(1) -T option, to specify another toolset.

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

buildsystem=<variant>

Specify the buildsystem variant to use. See the CMAKE_XCODE_BUILD_SYSTEM variable for allowed values. For example, to select the original build system under Xcode 12, run cmake(1) with the option -T buildsystem=1.

### Swift Support
New in version 3.4.

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().

## EXTRA GENERATORS
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>. The following extra generators are known to CMake.

### CodeBlocks
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.

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:

CodeBlocks - MinGW Makefiles

Generate with MinGW Makefiles.

CodeBlocks - NMake Makefiles

Generate with NMake Makefiles.

CodeBlocks - NMake Makefiles JOM

New in version 3.8: Generate with NMake Makefiles JOM.

CodeBlocks - Ninja

Generate with Ninja.

CodeBlocks - Unix Makefiles

Generate with Unix Makefiles.

### CodeLite
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.

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:

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

Kate - NMake Makefiles

Generate with NMake Makefiles.

Kate - Ninja

Generate with Ninja.

Kate - Unix Makefiles

Generate with Unix Makefiles.

### Sublime Text 2
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.

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-2023 Kitware, Inc. and Contributors


cmake-language

package: cmake

title: cmake-language(7)

summary: CMake Language Reference

text:
# cmake-language(7)

## NAME
cmake-language - CMake Language Reference

## ORGANIZATION
CMake input files are written in the "CMake Language" in source files named CMakeLists.txt or ending in a .cmake file name extension.

CMake Language source files in a project are organized into:

- Directories (CMakeLists.txt),

- Scripts (<script>.cmake), and

- Modules (<module>.cmake).

### Directories
When CMake processes a project source tree, the entry point is a source file called CMakeLists.txt in the top-level source directory. This file may contain the entire build specification or use the add_subdirectory() command to add subdirectories to the build. Each subdirectory added by the command must also contain a CMakeLists.txt file as the entry point to that directory. For each source directory whose CMakeLists.txt file is processed CMake generates a corresponding directory in the build tree to act as the default working and output directory.

### Scripts
An individual <script>.cmake source file may be processed in script mode by using the cmake(1) command-line tool with the -P option. Script mode simply runs the commands in the given CMake Language source file and does not generate a build system. It does not allow CMake commands that define build targets or actions.

### Modules
CMake Language code in either Directories or Scripts may use the include() command to load a <module>.cmake source file in the scope of the including context. See the cmake-modules(7) manual page for documentation of modules included with the CMake distribution. Project source trees may also provide their own modules and specify their location(s) in the CMAKE_MODULE_PATH variable.

## SYNTAX

### Encoding
A CMake Language source file may be written in 7-bit ASCII text for maximum portability across all supported platforms. Newlines may be encoded as either \n or \r\n but will be converted to \n as input files are read.

Note that the implementation is 8-bit clean so source files may be encoded as UTF-8 on platforms with system APIs supporting this encoding. In addition, CMake 3.2 and above support source files encoded in UTF-8 on Windows (using UTF-16 to call system APIs). Furthermore, CMake 3.0 and above allow a leading UTF-8 Byte-Order Mark in source files.

### Source Files
A CMake Language source file consists of zero or more Command Invocations separated by newlines and optionally spaces and Comments:

```
file         ::=  file_element*
file_element ::=  command_invocation line_ending |

                  (bracket_comment|space)* line_ending
line_ending  ::=  line_comment? newline
space        ::=  <match '[ \t]+'>
newline      ::=  <match '\n'>
```

Note that any source file line not inside Command Arguments or a Bracket Comment can end in a Line Comment.

### Command Invocations
A command invocation is a name followed by paren-enclosed arguments separated by whitespace:

```
command_invocation  ::=  space* identifier space* '(' arguments ')'
identifier          ::=  <match '[A-Za-z_][A-Za-z0-9_]*'>
arguments           ::=  argument? separated_arguments*
separated_arguments ::=  separation+ argument? |

                         separation* '(' arguments ')'
separation          ::=  space | line_ending
```

For example:

```
add_executable(hello world.c)
```

Command names are case-insensitive. Nested unquoted parentheses in the arguments must balance. Each ( or ) is given to the command invocation as a literal Unquoted Argument. This may be used in calls to the if() command to enclose conditions. For example:

```
if(FALSE AND (FALSE OR TRUE)) # evaluates to FALSE
```

NOTE:

CMake versions prior to 3.0 require command name identifiers to be at least 2 characters. CMake versions prior to 2.8.12 silently accept an Unquoted Argument or a Quoted Argument immediately following a Quoted Argument and not separated by any whitespace. For compatibility, CMake 2.8.12 and higher accept such code but produce a warning.

### Command Arguments
There are three types of arguments within Command Invocations:

```
argument ::=  bracket_argument | quoted_argument | unquoted_argument
```

### Bracket Argument
A bracket argument, inspired by Lua long bracket syntax, encloses content between opening and closing "brackets" of the same length:

```
bracket_argument ::=  bracket_open bracket_content bracket_close
bracket_open     ::=  '[' '='* '['
bracket_content  ::=  <any text not containing a bracket_close with

                       the same number of '=' as the bracket_open>
bracket_close    ::=  ']' '='* ']'
```

An opening bracket is written [ followed by zero or more = followed by [. The corresponding closing bracket is written ] followed by the same number of = followed by ]. Brackets do not nest. A unique length may always be chosen for the opening and closing brackets to contain closing brackets of other lengths.

Bracket argument content consists of all text between the opening and closing brackets, except that one newline immediately following the opening bracket, if any, is ignored. No evaluation of the enclosed content, such as Escape Sequences or Variable References, is performed. A bracket argument is always given to the command invocation as exactly one argument.

For example:

```
message([=[
This is the first line in a bracket argument with bracket length 1.
No \-escape sequences or ${variable} references are evaluated.
This is always one argument even though it contains a ; character.
The text does not end on a closing bracket of length 0 like ]].
It does end in a closing bracket of length 1.
]=])
```

NOTE:

CMake versions prior to 3.0 do not support bracket arguments. They interpret the opening bracket as the start of an Unquoted Argument.

### Quoted Argument
A quoted argument encloses content between opening and closing double-quote characters:

```
quoted_argument     ::=  '"' quoted_element* '"'
quoted_element      ::=  <any character except '\' or '"'> |

                         escape_sequence |

                         quoted_continuation
quoted_continuation ::=  '\' newline
```

Quoted argument content consists of all text between opening and closing quotes. Both Escape Sequences and Variable References are evaluated. A quoted argument is always given to the command invocation as exactly one argument.

For example:

```
message("This is a quoted argument containing multiple lines.
This is always one argument even though it contains a ; character.
Both \\-escape sequences and ${variable} references are evaluated.
The text does not end on an escaped double-quote like \".
It does end in an unescaped double quote.
")
```

The final \ on any line ending in an odd number of backslashes is treated as a line continuation and ignored along with the immediately following newline character. For example:

```
message("\
This is the first line of a quoted argument. \
In fact it is the only line but since it is long \
the source code uses line continuation.\
")
```

NOTE:

CMake versions prior to 3.0 do not support continuation with \. They report errors in quoted arguments containing lines ending in an odd number of \ characters.

### Unquoted Argument
An unquoted argument is not enclosed by any quoting syntax. It may not contain any whitespace, (, ), #, ", or \ except when escaped by a backslash:

```
unquoted_argument ::=  unquoted_element+ | unquoted_legacy
unquoted_element  ::=  <any character except whitespace or one of '()#"\'> |

                       escape_sequence
unquoted_legacy   ::=  <see note in text>
```

Unquoted argument content consists of all text in a contiguous block of allowed or escaped characters. Both Escape Sequences and Variable References are evaluated. The resulting value is divided in the same way Lists divide into elements. Each non-empty element is given to the command invocation as an argument. Therefore an unquoted argument may be given to a command invocation as zero or more arguments.

For example:

```
foreach(arg

    NoSpace

    Escaped\ Space

    This;Divides;Into;Five;Arguments

    Escaped\;Semicolon

    )

  message("${arg}")
endforeach()
```

NOTE:

To support legacy CMake code, unquoted arguments may also contain double-quoted strings ("...", possibly enclosing horizontal whitespace), and make-style variable references ($(MAKEVAR)). Unescaped double-quotes must balance, may not appear at the beginning of an unquoted argument, and are treated as part of the content. For example, the unquoted arguments -Da="b c", -Da=$(v), and a" "b"c"d are each interpreted literally. They may instead be written as quoted arguments "-Da=\"b c\"", "-Da=$(v)", and "a\" \"b\"c\"d", respectively.

Make-style references are treated literally as part of the content and do not undergo variable expansion. They are treated as part of a single argument (rather than as separate $, (, MAKEVAR, and ) arguments).

The above "unquoted_legacy" production represents such arguments. We do not recommend using legacy unquoted arguments in new code. Instead use a Quoted Argument or a Bracket Argument to represent the content.

### Escape Sequences
An escape sequence is a \ followed by one character:

```
escape_sequence  ::=  escape_identity | escape_encoded | escape_semicolon
escape_identity  ::=  '\' <match '[^A-Za-z0-9;]'>
escape_encoded   ::=  '\t' | '\r' | '\n'
escape_semicolon ::=  '\;'
```

A \ followed by a non-alphanumeric character simply encodes the literal character without interpreting it as syntax. A \t, \r, or \n encodes a tab, carriage return, or newline character, respectively. A \; outside of any Variable References encodes itself but may be used in an Unquoted Argument to encode the ; without dividing the argument value on it. A \; inside Variable References encodes the literal ; character. (See also policy CMP0053 documentation for historical considerations.)

### Variable References
A variable reference has the form ${<variable>} and is evaluated inside a Quoted Argument or an Unquoted Argument. A variable reference is replaced by the value of the variable, or by the empty string if the variable is not set. Variable references can nest and are evaluated from the inside out, e.g. ${outer_${inner_variable}_variable}.

Literal variable references may consist of alphanumeric characters, the characters /_.+-, and Escape Sequences. Nested references may be used to evaluate variables of any name. See also policy CMP0053 documentation for historical considerations and reasons why the $ is also technically permitted but is discouraged.

The Variables section documents the scope of variable names and how their values are set.

An environment variable reference has the form $ENV{<variable>}. See the Environment Variables section for more information.

A cache variable reference has the form $CACHE{<variable>}. See CACHE for more information.

The if() command has a special condition syntax that allows for variable references in the short form <variable> instead of ${<variable>}. However, environment and cache variables always need to be referenced as $ENV{<variable>} or $CACHE{<variable>}.

### Comments
A comment starts with a # character that is not inside a Bracket Argument, Quoted Argument, or escaped with \ as part of an Unquoted Argument. There are two types of comments: a Bracket Comment and a Line Comment.

### Bracket Comment
A # immediately followed by a bracket_open forms a bracket comment consisting of the entire bracket enclosure:

```
bracket_comment ::=  '#' bracket_argument
```

For example:

```
#[[This is a bracket comment.
It runs until the close bracket.]]
message("First Argument\n" #[[Bracket Comment]] "Second Argument")
```

NOTE:

CMake versions prior to 3.0 do not support bracket comments. They interpret the opening # as the start of a Line Comment.

### Line Comment
A # not immediately followed by a bracket_open forms a line comment that runs until the end of the line:

```
line_comment ::=  '#' <any text not starting in a bracket_open

                       and not containing a newline>
```

For example:

```
# This is a line comment.
message("First Argument\n" # This is a line comment :)

        "Second Argument") # This is a line comment.
```

## CONTROL STRUCTURES

### Conditional Blocks
The if()/elseif()/else()/endif() commands delimit code blocks to be executed conditionally.

### Loops
The foreach()/endforeach() and while()/endwhile() commands delimit code blocks to be executed in a loop. Inside such blocks the break() command may be used to terminate the loop early whereas the continue() command may be used to start with the next iteration immediately.

### Command Definitions
The macro()/endmacro(), and function()/endfunction() commands delimit code blocks to be recorded for later invocation as commands.

## VARIABLES
Variables are the basic unit of storage in the CMake Language. Their values are always of string type, though some commands may interpret the strings as values of other types. The set() and unset() commands explicitly set or unset a variable, but other commands have semantics that modify variables as well. Variable names are case-sensitive and may consist of almost any text, but we recommend sticking to names consisting only of alphanumeric characters plus _ and -.

Variables have dynamic scope. Each variable "set" or "unset" creates a binding in the current scope:

Function Scope

Command Definitions created by the function() command create commands that, when invoked, process the recorded commands in a new variable binding scope. A variable "set" or "unset" binds in this scope and is visible for the current function and any nested calls within it, but not after the function returns.

Directory Scope

Each of the Directories in a source tree has its own variable bindings. Before processing the CMakeLists.txt file for a directory, CMake copies all variable bindings currently defined in the parent directory, if any, to initialize the new directory scope. CMake Scripts, when processed with cmake -P, bind variables in one "directory" scope. A variable "set" or "unset" not inside a function call binds to the current directory scope.

Persistent Cache

CMake stores a separate set of "cache" variables, or "cache entries", whose values persist across multiple runs within a project build tree. Cache entries have an isolated binding scope modified only by explicit request, such as by the CACHE option of the set() and unset() commands.

When evaluating Variable References, CMake first searches the function call stack, if any, for a binding and then falls back to the binding in the current directory scope, if any. If a "set" binding is found, its value is used. If an "unset" binding is found, or no binding is found, CMake then searches for a cache entry. If a cache entry is found, its value is used. Otherwise, the variable reference evaluates to an empty string. The $CACHE{VAR} syntax can be used to do direct cache entry lookups.

The cmake-variables(7) manual documents the many variables that are provided by CMake or have meaning to CMake when set by project code.

NOTE:

CMake reserves identifiers that:

- begin with CMAKE_ (upper-, lower-, or mixed-case), or

- begin with _CMAKE_ (upper-, lower-, or mixed-case), or

- begin with _ followed by the name of any CMake Command.

## ENVIRONMENT VARIABLES
Environment Variables are like ordinary Variables, with the following differences:

Scope

Environment variables have global scope in a CMake process. They are never cached.

References

Variable References have the form $ENV{<variable>}.

Initialization

Initial values of the CMake environment variables are those of the calling process. Values can be changed using the set() and unset() commands. These commands only affect the running CMake process, not the system environment at large. Changed values are not written back to the calling process, and they are not seen by subsequent build or test processes.

The cmake-env-variables(7) manual documents environment variables that have special meaning to CMake.

## LISTS
Although all values in CMake are stored as strings, a string may be treated as a list in certain contexts, such as during evaluation of an Unquoted Argument. In such contexts, a string is divided into list elements by splitting on ; characters not following an unequal number of [ and ] characters and not immediately preceded by a \. The sequence \; does not divide a value but is replaced by ; in the resulting element.

A list of elements is represented as a string by concatenating the elements separated by ;. For example, the set() command stores multiple values into the destination variable as a list:

```
set(srcs a.c b.c c.c) # sets "srcs" to "a.c;b.c;c.c"
```

Lists are meant for simple use cases such as a list of source files and should not be used for complex data processing tasks. Most commands that construct lists do not escape ; characters in list elements, thus flattening nested lists:

```
set(x a "b;c") # sets "x" to "a;b;c", not "a;b\;c"
```

In general, lists do not support elements containing ; characters. To avoid problems, consider the following advice:

- The interfaces of many CMake commands, variables, and properties accept semicolon-separated lists. Avoid passing lists with elements containing semicolons to these interfaces unless they document either direct support or some way to escape or encode semicolons.

- When constructing a list, substitute an otherwise-unused placeholder for ; in elements when. Then substitute ; for the placeholder when processing list elements. For example, the following code uses | in place of ; characters:

```
set(mylist a "b|c")
foreach(entry IN LISTS mylist)

  string(REPLACE "|" ";" entry "${entry}")

  # use "${entry}" normally
endforeach()
```

The ExternalProject module's LIST_SEPARATOR option is an example of an interface built using this approach.

- In lists of generator expressions, use the $<SEMICOLON> generator expression.

- In command calls, use Quoted Argument syntax whenever possible. The called command will receive the content of the argument with semicolons preserved. An Unquoted Argument will be split on semicolons.

- In function() implementations, avoid ARGV and ARGN, which do not distinguish semicolons in values from those separating values. Instead, prefer using named positional arguments and the ARGC and ARGV# variables. When using cmake_parse_arguments() to parse arguments, prefer its PARSE_ARGV signature, which uses the ARGV# variables. Note that this approach does not apply to macro() implementations because they reference arguments using placeholders, not real variables.

## COPYRIGHT
2000-2023 Kitware, Inc. and Contributors