cmake-qt

package: cmake

title: cmake-qt(7)

summary: CMake Qt Features Reference

text:
# cmake-qt(7)

## NAME
cmake-qt - CMake Qt Features Reference

## INTRODUCTION
CMake can find and use Qt 4, Qt 5 and Qt 6 libraries. The Qt 4 libraries are found by the FindQt4 <#module:FindQt4> find-module shipped with CMake, whereas the Qt 5 and Qt 6 libraries are found using "Config-file Packages" shipped with Qt 5 and Qt 6. See cmake-packages(7) <#manual:cmake-packages(7)> for more information about CMake packages, and see the Qt cmake manual <https://doc.qt.io/qt-6/cmake-manual.html> for your Qt version.

Qt 4, Qt 5 and Qt 6 may be used together in the same CMake buildsystem <#manual:cmake-buildsystem(7)>:

```
cmake_minimum_required(VERSION 3.16 FATAL_ERROR)
project(Qt4_5_6)
set(CMAKE_AUTOMOC ON)
find_package(Qt6 COMPONENTS Widgets DBus REQUIRED)
add_executable(publisher publisher.cpp)
target_link_libraries(publisher Qt6::Widgets Qt6::DBus)
find_package(Qt5 COMPONENTS Gui DBus REQUIRED)
add_executable(subscriber1 subscriber1.cpp)
target_link_libraries(subscriber1 Qt5::Gui Qt5::DBus)
find_package(Qt4 REQUIRED)
add_executable(subscriber2 subscriber2.cpp)
target_link_libraries(subscriber2 Qt4::QtGui Qt4::QtDBus)
```

A CMake target may not link to more than one Qt version. A diagnostic is issued if this is attempted or results from transitive target dependency evaluation.

## QT BUILD TOOLS
Qt relies on some bundled tools for code generation, such as moc for meta-object code generation, uic for widget layout and population, and rcc for virtual file system content generation. These tools may be automatically invoked by cmake(1) <#manual:cmake(1)> if the appropriate conditions are met. The automatic tool invocation may be used with Qt version 4 to 6.

### AUTOMOC
The AUTOMOC <#prop_tgt:AUTOMOC> target property controls whether cmake(1) <#manual:cmake(1)> inspects the C++ files in the target to determine if they require moc to be run, and to create rules to execute moc at the appropriate time.

If a macro from AUTOMOC_MACRO_NAMES <#prop_tgt:AUTOMOC_MACRO_NAMES> is found in a header file, moc will be run on the file. The result will be put into a file named according to moc_<basename>.cpp. If the macro is found in a C++ implementation file, the moc output will be put into a file named according to <basename>.moc, following the Qt conventions. The <basename>.moc must be included by the user in the C++ implementation file with a preprocessor #include.

Included moc_*.cpp and *.moc files will be generated in the <AUTOGEN_BUILD_DIR>/include directory which is automatically added to the target's INCLUDE_DIRECTORIES <#prop_tgt:INCLUDE_DIRECTORIES>.

- This differs from CMake 3.7 and below; see their documentation for details.

- For multi configuration generators <#prop_gbl:GENERATOR_IS_MULTI_CONFIG>, the include directory is <AUTOGEN_BUILD_DIR>/include_<CONFIG>.

- See AUTOGEN_BUILD_DIR <#prop_tgt:AUTOGEN_BUILD_DIR>.

Not included moc_<basename>.cpp files will be generated in custom folders to avoid name collisions and included in a separate file which is compiled into the target, named either <AUTOGEN_BUILD_DIR>/mocs_compilation.cpp or <AUTOGEN_BUILD_DIR>/mocs_compilation_$<CONFIG>.cpp.

•

See AUTOGEN_BUILD_DIR <#prop_tgt:AUTOGEN_BUILD_DIR>.

The moc command line will consume the COMPILE_DEFINITIONS <#prop_tgt:COMPILE_DEFINITIONS> and INCLUDE_DIRECTORIES <#prop_tgt:INCLUDE_DIRECTORIES> target properties from the target it is being invoked for, and for the appropriate build configuration.

The AUTOMOC <#prop_tgt:AUTOMOC> target property may be pre-set for all following targets by setting the CMAKE_AUTOMOC <#variable:CMAKE_AUTOMOC> variable. The AUTOMOC_MOC_OPTIONS <#prop_tgt:AUTOMOC_MOC_OPTIONS> target property may be populated to set options to pass to moc. The CMAKE_AUTOMOC_MOC_OPTIONS <#variable:CMAKE_AUTOMOC_MOC_OPTIONS> variable may be populated to pre-set the options for all following targets.

Additional macro names to search for can be added to AUTOMOC_MACRO_NAMES <#prop_tgt:AUTOMOC_MACRO_NAMES>.

Additional moc dependency file names can be extracted from source code by using AUTOMOC_DEPEND_FILTERS <#prop_tgt:AUTOMOC_DEPEND_FILTERS>.

Source C++ files can be excluded from AUTOMOC <#prop_tgt:AUTOMOC> processing by enabling SKIP_AUTOMOC <#prop_sf:SKIP_AUTOMOC> or the broader SKIP_AUTOGEN <#prop_sf:SKIP_AUTOGEN>.

### AUTOUIC
The AUTOUIC <#prop_tgt:AUTOUIC> target property controls whether cmake(1) <#manual:cmake(1)> inspects the C++ files in the target to determine if they require uic to be run, and to create rules to execute uic at the appropriate time.

If a preprocessor #include directive is found which matches <path>ui_<basename>.h, and a <basename>.ui file exists, then uic will be executed to generate the appropriate file. The <basename>.ui file is searched for in the following places

1.

<source_dir>/<basename>.ui

2.

<source_dir>/<path><basename>.ui

3.

<AUTOUIC_SEARCH_PATHS>/<basename>.ui

4.

<AUTOUIC_SEARCH_PATHS>/<path><basename>.ui

where <source_dir> is the directory of the C++ file and AUTOUIC_SEARCH_PATHS <#prop_tgt:AUTOUIC_SEARCH_PATHS> is a list of additional search paths.

The generated generated ui_*.h files are placed in the <AUTOGEN_BUILD_DIR>/include directory which is automatically added to the target's INCLUDE_DIRECTORIES <#prop_tgt:INCLUDE_DIRECTORIES>.

- This differs from CMake 3.7 and below; see their documentation for details.

- For multi configuration generators <#prop_gbl:GENERATOR_IS_MULTI_CONFIG>, the include directory is <AUTOGEN_BUILD_DIR>/include_<CONFIG>.

- See AUTOGEN_BUILD_DIR <#prop_tgt:AUTOGEN_BUILD_DIR>.

The AUTOUIC <#prop_tgt:AUTOUIC> target property may be pre-set for all following targets by setting the CMAKE_AUTOUIC <#variable:CMAKE_AUTOUIC> variable. The AUTOUIC_OPTIONS <#prop_tgt:AUTOUIC_OPTIONS> target property may be populated to set options to pass to uic. The CMAKE_AUTOUIC_OPTIONS <#variable:CMAKE_AUTOUIC_OPTIONS> variable may be populated to pre-set the options for all following targets. The AUTOUIC_OPTIONS <#prop_sf:AUTOUIC_OPTIONS> source file property may be set on the <basename>.ui file to set particular options for the file. This overrides options from the AUTOUIC_OPTIONS <#prop_tgt:AUTOUIC_OPTIONS> target property.

A target may populate the INTERFACE_AUTOUIC_OPTIONS <#prop_tgt:INTERFACE_AUTOUIC_OPTIONS> target property with options that should be used when invoking uic. This must be consistent with the AUTOUIC_OPTIONS <#prop_tgt:AUTOUIC_OPTIONS> target property content of the depender target. The CMAKE_DEBUG_TARGET_PROPERTIES <#variable:CMAKE_DEBUG_TARGET_PROPERTIES> variable may be used to track the origin target of such INTERFACE_AUTOUIC_OPTIONS <#prop_tgt:INTERFACE_AUTOUIC_OPTIONS>. This means that a library which provides an alternative translation system for Qt may specify options which should be used when running uic:

```
add_library(KI18n klocalizedstring.cpp)
target_link_libraries(KI18n Qt6::Core)
# KI18n uses the tr2i18n() function instead of tr().  That function is
# declared in the klocalizedstring.h header.
set(autouic_options

  -tr tr2i18n

  -include klocalizedstring.h
)
set_property(TARGET KI18n APPEND PROPERTY

  INTERFACE_AUTOUIC_OPTIONS ${autouic_options}
)
```

A consuming project linking to the target exported from upstream automatically uses appropriate options when uic is run by AUTOUIC <#prop_tgt:AUTOUIC>, as a result of linking with the IMPORTED <#prop_tgt:IMPORTED> target:

```
set(CMAKE_AUTOUIC ON)
# Uses a libwidget.ui file:
add_library(LibWidget libwidget.cpp)
target_link_libraries(LibWidget

  KF5::KI18n

  Qt5::Widgets
)
```

Source files can be excluded from AUTOUIC <#prop_tgt:AUTOUIC> processing by enabling SKIP_AUTOUIC <#prop_sf:SKIP_AUTOUIC> or the broader SKIP_AUTOGEN <#prop_sf:SKIP_AUTOGEN>.

### AUTORCC
The AUTORCC <#prop_tgt:AUTORCC> target property controls whether cmake(1) <#manual:cmake(1)> creates rules to execute rcc at the appropriate time on source files which have the suffix .qrc.

```
add_executable(myexe main.cpp resource_file.qrc)
```

The AUTORCC <#prop_tgt:AUTORCC> target property may be pre-set for all following targets by setting the CMAKE_AUTORCC <#variable:CMAKE_AUTORCC> variable. The AUTORCC_OPTIONS <#prop_tgt:AUTORCC_OPTIONS> target property may be populated to set options to pass to rcc. The CMAKE_AUTORCC_OPTIONS <#variable:CMAKE_AUTORCC_OPTIONS> variable may be populated to pre-set the options for all following targets. The AUTORCC_OPTIONS <#prop_sf:AUTORCC_OPTIONS> source file property may be set on the <name>.qrc file to set particular options for the file. This overrides options from the AUTORCC_OPTIONS <#prop_tgt:AUTORCC_OPTIONS> target property.

Source files can be excluded from AUTORCC <#prop_tgt:AUTORCC> processing by enabling SKIP_AUTORCC <#prop_sf:SKIP_AUTORCC> or the broader SKIP_AUTOGEN <#prop_sf:SKIP_AUTOGEN>.

## THE <ORIGIN>_AUTOGEN TARGET
The moc and uic tools are executed as part of a synthesized <ORIGIN>_autogen custom target <#command:add_custom_target> generated by CMake. By default, that <ORIGIN>_autogen target inherits the dependencies of the <ORIGIN> target (see AUTOGEN_ORIGIN_DEPENDS <#prop_tgt:AUTOGEN_ORIGIN_DEPENDS>). Target dependencies may be added to the <ORIGIN>_autogen target by adding them to the AUTOGEN_TARGET_DEPENDS <#prop_tgt:AUTOGEN_TARGET_DEPENDS> target property.

Note:

If Qt 5.15 or later is used and the generator is either Ninja <#generator:Ninja> or Makefile Generators <#makefile-generators>, see The <ORIGIN>_autogen_timestamp_deps target.

## THE <ORIGIN>_AUTOGEN_TIMESTAMP_DEPS TARGET
If Qt 5.15 or later is used and the generator is either Ninja <#generator:Ninja> or Makefile Generators <#makefile-generators>, the <ORIGIN>_autogen_timestamp_deps target is also created in addition to the <ORIGIN>_autogen target. This target does not have any sources or commands to execute, but it has dependencies that were previously inherited by the pre-Qt 5.15 <ORIGIN>_autogen target. These dependencies will serve as a list of order-only dependencies for the custom command, without forcing the custom command to re-execute.

## VISUAL STUDIO GENERATORS
When using the Visual Studio Generators <#visual-studio-generators>, CMake generates a PRE_BUILD custom command <#command:add_custom_command> instead of the <ORIGIN>_autogen custom target <#command:add_custom_target> (for AUTOMOC <#prop_tgt:AUTOMOC> and AUTOUIC <#prop_tgt:AUTOUIC>). This isn't always possible though and an <ORIGIN>_autogen custom target <#command:add_custom_target> is used, when either

- the <ORIGIN> target depends on GENERATED <#prop_sf:GENERATED> files which aren't excluded from AUTOMOC <#prop_tgt:AUTOMOC> and AUTOUIC <#prop_tgt:AUTOUIC> by SKIP_AUTOMOC <#prop_sf:SKIP_AUTOMOC>, SKIP_AUTOUIC <#prop_sf:SKIP_AUTOUIC>, SKIP_AUTOGEN <#prop_sf:SKIP_AUTOGEN> or CMP0071 <#policy:CMP0071>

- AUTOGEN_TARGET_DEPENDS <#prop_tgt:AUTOGEN_TARGET_DEPENDS> lists a source file

- CMAKE_GLOBAL_AUTOGEN_TARGET <#variable:CMAKE_GLOBAL_AUTOGEN_TARGET> is enabled

## QTMAIN.LIB ON WINDOWS
The Qt 4 and 5 IMPORTED <#prop_tgt:IMPORTED> targets for the QtGui libraries specify that the qtmain.lib static library shipped with Qt will be linked by all dependent executables which have the WIN32_EXECUTABLE <#prop_tgt:WIN32_EXECUTABLE> enabled.

To disable this behavior, enable the Qt5_NO_LINK_QTMAIN target property for Qt 5 based targets or QT4_NO_LINK_QTMAIN target property for Qt 4 based targets.

```
add_executable(myexe WIN32 main.cpp)
target_link_libraries(myexe Qt4::QtGui)
add_executable(myexe_no_qtmain WIN32 main_no_qtmain.cpp)
set_property(TARGET main_no_qtmain PROPERTY QT4_NO_LINK_QTMAIN ON)
target_link_libraries(main_no_qtmain Qt4::QtGui)
```

## Copyright
2000-2026 Kitware, Inc. and Contributors

branch: sisyphus


cmake-server

title: cmake-server(7)

summary: CMake Server

text:
# cmake-server(7)

## NAME
cmake-server - CMake Server

The cmake(1) <#manual:cmake(1)> server mode has been removed since CMake 3.20. Clients should use the cmake-file-api(7) <#manual:cmake-file-api(7)> instead.

## Copyright
2000-2026 Kitware, Inc. and Contributors


cmake-toolchains

title: cmake-toolchains(7)

summary: CMake Toolchains Reference

text:
# cmake-toolchains(7)

## NAME
cmake-toolchains - CMake Toolchains Reference

## INTRODUCTION
CMake uses a toolchain of utilities to compile, link libraries and create archives, and other tasks to drive the build. The toolchain utilities available are determined by the languages enabled. In normal builds, CMake automatically determines the toolchain for host builds based on system introspection and defaults. In cross-compiling scenarios, a toolchain file may be specified with information about compiler and utility paths.

Added in version 3.19: One may use cmake-presets(7) <#manual:cmake-presets(7)> to specify toolchain files.

## LANGUAGES
Languages are enabled by the project() <#command:project> command. Language-specific built-in variables, such as CMAKE_CXX_COMPILER <#variable:CMAKE_<LANG>_COMPILER>, CMAKE_CXX_COMPILER_ID <#variable:CMAKE_<LANG>_COMPILER_ID> etc are set by invoking the project() <#command:project> command. If no project command is in the top-level CMakeLists file, one will be implicitly generated. By default the enabled languages are C and CXX:

```
project(C_Only C)
```

A special value of NONE can also be used with the project() <#command:project> command to enable no languages:

```
project(MyProject NONE)
```

The enable_language() <#command:enable_language> command can be used to enable languages after the project() <#command:project> command:

```
enable_language(CXX)
```

When a language is enabled, CMake finds a compiler for that language, and determines some information, such as the vendor and version of the compiler, the target architecture and bitwidth, the location of corresponding utilities etc.

The ENABLED_LANGUAGES <#prop_gbl:ENABLED_LANGUAGES> global property contains the languages which are currently enabled.

## VARIABLES AND PROPERTIES
Several variables relate to the language components of a toolchain which are enabled:

CMAKE_<LANG>_COMPILER <#variable:CMAKE_<LANG>_COMPILER>

The full path to the compiler used for <LANG>

CMAKE_<LANG>_COMPILER_ID <#variable:CMAKE_<LANG>_COMPILER_ID>

The compiler identifier used by CMake

CMAKE_<LANG>_COMPILER_VERSION <#variable:CMAKE_<LANG>_COMPILER_VERSION>

The version of the compiler.

CMAKE_<LANG>_FLAGS <#variable:CMAKE_<LANG>_FLAGS>

These variables and the configuration-specific equivalents contain flags that will be added to all invocations of the compiler for a particular language, including those driving compiling and linking.

CMAKE_<LANG>_LINK_FLAGS <#variable:CMAKE_<LANG>_LINK_FLAGS>

Added in version 4.3.

These variables and the configuration-specific equivalents contain flags that will be added to all invocations of the compiler for a particular language when driving linking only.

CMake needs a way to determine which compiler to use to invoke the linker. This is determined by the LANGUAGE <#prop_sf:LANGUAGE> property of source files of the target <#manual:cmake-buildsystem(7)>, and in the case of static libraries, the LANGUAGE of the dependent libraries. The choice CMake makes may be overridden with the LINKER_LANGUAGE <#prop_tgt:LINKER_LANGUAGE> target property.

## TOOLCHAIN FEATURES
CMake provides the try_compile() <#command:try_compile> command and modules such as CheckSourceCompiles <#module:CheckSourceCompiles>, CheckCXXSymbolExists <#module:CheckCXXSymbolExists> and CheckIncludeFile <#module:CheckIncludeFile> to test capability and availability of various toolchain features. These APIs test the toolchain in some way and cache the result so that the test does not have to be performed again the next time CMake runs.

Some toolchain features have built-in handling in CMake, and do not require compile-tests. For example, POSITION_INDEPENDENT_CODE <#prop_tgt:POSITION_INDEPENDENT_CODE> allows specifying that a target should be built as position-independent code, if the compiler supports that feature. The <LANG>_VISIBILITY_PRESET <#prop_tgt:<LANG>_VISIBILITY_PRESET> and VISIBILITY_INLINES_HIDDEN <#prop_tgt:VISIBILITY_INLINES_HIDDEN> target properties add flags for hidden visibility, if supported by the compiler.

## CROSS COMPILING
If cmake(1) <#manual:cmake(1)> is invoked with the command line parameter --toolchain path/to/file <#cmdoption-cmake-toolchain> or -DCMAKE_TOOLCHAIN_FILE=path/to/file <#cmdoption-cmake-D>, the file will be loaded early to set values for the compilers. The CMAKE_CROSSCOMPILING <#variable:CMAKE_CROSSCOMPILING> variable is set to true when CMake is cross-compiling.

Note that using the CMAKE_SOURCE_DIR <#variable:CMAKE_SOURCE_DIR> or CMAKE_BINARY_DIR <#variable:CMAKE_BINARY_DIR> variables inside a toolchain file is typically undesirable. The toolchain file is used in contexts where these variables have different values when used in different places (e.g. as part of a call to try_compile() <#command:try_compile>). In most cases, where there is a need to evaluate paths inside a toolchain file, the more appropriate variable to use would be CMAKE_CURRENT_LIST_DIR <#variable:CMAKE_CURRENT_LIST_DIR>, since it always has an unambiguous, predictable value.

### Cross Compiling for Linux
A typical cross-compiling toolchain for Linux has content such as:

```
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs)
set(CMAKE_STAGING_PREFIX /home/devel/stage)
set(tools /home/devel/gcc-4.7-linaro-rpi-gnueabihf)
set(CMAKE_C_COMPILER ${tools}/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER ${tools}/bin/arm-linux-gnueabihf-g++)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
```

Where:

CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME>

is the CMake-identifier of the target platform to build for.

CMAKE_SYSTEM_PROCESSOR <#variable:CMAKE_SYSTEM_PROCESSOR>

is the CMake-identifier of the target architecture.

CMAKE_SYSROOT <#variable:CMAKE_SYSROOT>

is optional, and may be specified if a sysroot is available.

CMAKE_STAGING_PREFIX <#variable:CMAKE_STAGING_PREFIX>

is also optional. It may be used to specify a path on the host to install to. The CMAKE_INSTALL_PREFIX <#variable:CMAKE_INSTALL_PREFIX> is always the runtime installation location, even when cross-compiling.

CMAKE_<LANG>_COMPILER <#variable:CMAKE_<LANG>_COMPILER>

variable may be set to full paths, or to names of compilers to search for in standard locations. For toolchains that do not support linking binaries without custom flags or scripts one may set the CMAKE_TRY_COMPILE_TARGET_TYPE <#variable:CMAKE_TRY_COMPILE_TARGET_TYPE> variable to STATIC_LIBRARY to tell CMake not to try to link executables during its checks.

CMake find_* commands will look in the sysroot, and the CMAKE_FIND_ROOT_PATH <#variable:CMAKE_FIND_ROOT_PATH> entries by default in all cases, as well as looking in the host system root prefix. Although this can be controlled on a case-by-case basis, when cross-compiling, it can be useful to exclude looking in either the host or the target for particular artifacts. Generally, includes, libraries and packages should be found in the target system prefixes, whereas executables which must be run as part of the build should be found only on the host and not on the target. This is the purpose of the CMAKE_FIND_ROOT_PATH_MODE_* variables.

### Cross Compiling for the Cray Linux Environment
Cross compiling for compute nodes in the Cray Linux Environment can be done without needing a separate toolchain file. Specifying -DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment on the CMake command line will ensure that the appropriate build settings and search paths are configured. The platform will pull its configuration from the current environment variables and will configure a project to use the compiler wrappers from the Cray Programming Environment's PrgEnv-* modules if present and loaded.

The default configuration of the Cray Programming Environment is to only support static libraries. This can be overridden and shared libraries enabled by setting the CRAYPE_LINK_TYPE environment variable to dynamic.

Running CMake without specifying CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME> will run the configure step in host mode assuming a standard Linux environment. If not overridden, the PrgEnv-* compiler wrappers will end up getting used, which if targeting the either the login node or compute node, is likely not the desired behavior. The exception to this would be if you are building directly on a NID instead of cross-compiling from a login node. If trying to build software for a login node, you will need to either first unload the currently loaded PrgEnv-* module or explicitly tell CMake to use the system compilers in /usr/bin instead of the Cray wrappers. If instead targeting a compute node is desired, just specify the CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME> as mentioned above.

### Cross Compiling using Clang
Some compilers such as Clang are inherently cross compilers. The CMAKE_<LANG>_COMPILER_TARGET <#variable:CMAKE_<LANG>_COMPILER_TARGET> can be set to pass a value to those supported compilers when compiling:

```
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(triple arm-linux-gnueabihf)
set(CMAKE_C_COMPILER clang)
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_CXX_COMPILER_TARGET ${triple})
```

Similarly, some compilers do not ship their own supplementary utilities such as linkers, but provide a way to specify the location of the external toolchain which will be used by the compiler driver. The CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN <#variable:CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN> variable can be set in a toolchain file to pass the path to the compiler driver.

### Cross Compiling for QNX
As the Clang compiler the QNX QCC compile is inherently a cross compiler. And the CMAKE_<LANG>_COMPILER_TARGET <#variable:CMAKE_<LANG>_COMPILER_TARGET> can be set to pass a value to those supported compilers when compiling:

```
set(CMAKE_SYSTEM_NAME QNX)
set(arch gcc_ntoaarch64)
set(CMAKE_C_COMPILER qcc)
set(CMAKE_C_COMPILER_TARGET ${arch})
set(CMAKE_CXX_COMPILER q++)
set(CMAKE_CXX_COMPILER_TARGET ${arch})
set(CMAKE_SYSROOT $ENV{QNX_TARGET})
```

### Cross Compiling for Windows CE
Cross compiling for Windows CE requires the corresponding SDK being installed on your system. These SDKs are usually installed under C:/Program Files (x86)/Windows CE Tools/SDKs.

A toolchain file to configure Visual Studio Generators <#visual-studio-generators> for Windows CE may look like this:

```
set(CMAKE_SYSTEM_NAME WindowsCE)
set(CMAKE_SYSTEM_VERSION 8.0)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0
set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310)
```

The CMAKE_GENERATOR_PLATFORM <#variable:CMAKE_GENERATOR_PLATFORM> tells the generator which SDK to use. Further CMAKE_SYSTEM_VERSION <#variable:CMAKE_SYSTEM_VERSION> tells the generator what version of Windows CE to use. Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions may require one to set CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> to the correct value.

### Cross Compiling for Windows 10 Universal Applications
A toolchain file to configure Visual Studio Generators <#visual-studio-generators> for a Windows 10 Universal Application may look like this:

```
set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 10.0)
```

A Windows 10 Universal Application targets both Windows Store and Windows Phone. Specify the CMAKE_SYSTEM_VERSION <#variable:CMAKE_SYSTEM_VERSION> variable to be 10.0 or higher.

CMake selects a Windows SDK as described by documentation of the CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION <#variable:CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION> variable.

### Cross Compiling for Windows Phone
A toolchain file to configure Visual Studio Generators <#visual-studio-generators> for Windows Phone may look like this:

```
set(CMAKE_SYSTEM_NAME WindowsPhone)
set(CMAKE_SYSTEM_VERSION 8.1)
```

### Cross Compiling for Windows Store
A toolchain file to configure a Visual Studio Generators <#visual-studio-generators> for Windows Store may look like this:

```
set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 8.1)
```

### Cross Compiling for ADSP SHARC/Blackfin
Cross-compiling for ADSP SHARC or Blackfin can be configured by setting the CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME> variable to ADSP and the CMAKE_SYSTEM_PROCESSOR <#variable:CMAKE_SYSTEM_PROCESSOR> variable to the "part number", excluding the ADSP- prefix, for example, 21594, SC589, etc. This value is case insensitive.

CMake will automatically search for CCES or VDSP++ installs in their default install locations and select the most recent version found. CCES will be selected over VDSP++ if both are installed. Custom install paths can be set via the CMAKE_ADSP_ROOT <#variable:CMAKE_ADSP_ROOT> variable or the ADSP_ROOT <#envvar:ADSP_ROOT> environment variable.

The compiler (cc21k vs. ccblkfn) is selected automatically based on the CMAKE_SYSTEM_PROCESSOR <#variable:CMAKE_SYSTEM_PROCESSOR> value provided.

### Cross Compiling for Android
A toolchain file may configure cross-compiling for Android by setting the CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME> variable to Android. Further configuration is specific to the Android development environment to be used.

For Visual Studio Generators <#visual-studio-generators>, CMake expects NVIDIA Nsight Tegra Visual Studio Edition or the Visual Studio tools for Android to be installed. See those sections for further configuration details.

For Makefile Generators <#makefile-generators> and the Ninja <#generator:Ninja> generator, CMake expects one of these environments:

- NDK

- Standalone Toolchain

CMake uses the following steps to select one of the environments:

- If the CMAKE_ANDROID_NDK <#variable:CMAKE_ANDROID_NDK> variable is set, the NDK at the specified location will be used.

- Else, if the CMAKE_ANDROID_STANDALONE_TOOLCHAIN <#variable:CMAKE_ANDROID_STANDALONE_TOOLCHAIN> variable is set, the Standalone Toolchain at the specified location will be used.

- Else, if the CMAKE_SYSROOT <#variable:CMAKE_SYSROOT> variable is set to a directory of the form <ndk>/platforms/android-<api>/arch-<arch>, the <ndk> part will be used as the value of CMAKE_ANDROID_NDK <#variable:CMAKE_ANDROID_NDK> and the NDK will be used.

- Else, if the CMAKE_SYSROOT <#variable:CMAKE_SYSROOT> variable is set to a directory of the form <standalone-toolchain>/sysroot, the <standalone-toolchain> part will be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN <#variable:CMAKE_ANDROID_STANDALONE_TOOLCHAIN> and the Standalone Toolchain will be used.

- Else, if a cmake variable ANDROID_NDK is set it will be used as the value of CMAKE_ANDROID_NDK <#variable:CMAKE_ANDROID_NDK>, and the NDK will be used.

- Else, if a cmake variable ANDROID_STANDALONE_TOOLCHAIN is set, it will be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN <#variable:CMAKE_ANDROID_STANDALONE_TOOLCHAIN>, and the Standalone Toolchain will be used.

- Else, if an environment variable ANDROID_NDK_ROOT or ANDROID_NDK is set, it will be used as the value of CMAKE_ANDROID_NDK <#variable:CMAKE_ANDROID_NDK>, and the NDK will be used.

- Else, if an environment variable ANDROID_STANDALONE_TOOLCHAIN is set then it will be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN <#variable:CMAKE_ANDROID_STANDALONE_TOOLCHAIN>, and the Standalone Toolchain will be used.

- Else, an error diagnostic will be issued that neither the NDK or Standalone Toolchain can be found.

Added in version 3.20: If an Android NDK is selected, its version number is reported in the CMAKE_ANDROID_NDK_VERSION <#variable:CMAKE_ANDROID_NDK_VERSION> variable.

### Cross Compiling for Android with the NDK
A toolchain file may configure Makefile Generators <#makefile-generators>, Ninja Generators <#ninja-generators>, or Visual Studio Generators <#visual-studio-generators> to target Android for cross-compiling.

Configure use of an Android NDK with the following variables:

CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME>

Set to Android. Must be specified to enable cross compiling for Android.

CMAKE_SYSTEM_VERSION <#variable:CMAKE_SYSTEM_VERSION>

Set to the Android API level. If not specified, the value is determined as follows:

- If the CMAKE_ANDROID_API <#variable:CMAKE_ANDROID_API> variable is set, its value is used as the API level.

- If the CMAKE_SYSROOT <#variable:CMAKE_SYSROOT> variable is set, the API level is detected from the NDK directory structure containing the sysroot.

- Otherwise, the latest API level available in the NDK is used.

CMAKE_ANDROID_ARCH_ABI <#variable:CMAKE_ANDROID_ARCH_ABI>

Set to the Android ABI (architecture). If not specified, this variable will default to the first supported ABI in the list of armeabi, armeabi-v7a and arm64-v8a. The CMAKE_ANDROID_ARCH <#variable:CMAKE_ANDROID_ARCH> variable will be computed from CMAKE_ANDROID_ARCH_ABI automatically. Also see the CMAKE_ANDROID_ARM_MODE <#variable:CMAKE_ANDROID_ARM_MODE> and CMAKE_ANDROID_ARM_NEON <#variable:CMAKE_ANDROID_ARM_NEON> variables.

CMAKE_ANDROID_NDK <#variable:CMAKE_ANDROID_NDK>

Set to the absolute path to the Android NDK root directory. If not specified, a default for this variable will be chosen as specified above.

CMAKE_ANDROID_NDK_DEPRECATED_HEADERS <#variable:CMAKE_ANDROID_NDK_DEPRECATED_HEADERS>

Set to a true value to use the deprecated per-api-level headers instead of the unified headers. If not specified, the default will be false unless using a NDK that does not provide unified headers.

CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION <#variable:CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION>

On NDK r19 or above, this variable must be unset or set to clang. On NDK r18 or below, set this to the version of the NDK toolchain to be selected as the compiler. If not specified, the default will be the latest available GCC toolchain.

CMAKE_ANDROID_STL_TYPE <#variable:CMAKE_ANDROID_STL_TYPE>

Set to specify which C++ standard library to use. If not specified, a default will be selected as described in the variable documentation.

The following variables will be computed and provided automatically:

CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX <#variable:CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX>

The absolute path prefix to the binutils in the NDK toolchain.

CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX <#variable:CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX>

The host platform suffix of the binutils in the NDK toolchain.

For example, a toolchain file might contain:

```
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 21) # API level
set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
set(CMAKE_ANDROID_NDK /path/to/android-ndk)
set(CMAKE_ANDROID_STL_TYPE gnustl_static)
```

Alternatively one may specify the values without a toolchain file:

```
$ cmake ../src \

  -DCMAKE_SYSTEM_NAME=Android \

  -DCMAKE_SYSTEM_VERSION=21 \

  -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \

  -DCMAKE_ANDROID_NDK=/path/to/android-ndk \

  -DCMAKE_ANDROID_STL_TYPE=gnustl_static
```

### Cross Compiling for Android with a Standalone Toolchain
A toolchain file may configure Makefile Generators <#makefile-generators> or the Ninja <#generator:Ninja> generator to target Android for cross-compiling using a standalone toolchain.

Configure use of an Android standalone toolchain with the following variables:

CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME>

Set to Android. Must be specified to enable cross compiling for Android.

CMAKE_ANDROID_STANDALONE_TOOLCHAIN <#variable:CMAKE_ANDROID_STANDALONE_TOOLCHAIN>

Set to the absolute path to the standalone toolchain root directory. A ${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot directory must exist. If not specified, a default for this variable will be chosen as specified above.

CMAKE_ANDROID_ARM_MODE <#variable:CMAKE_ANDROID_ARM_MODE>

When the standalone toolchain targets ARM, optionally set this to ON to target 32-bit ARM instead of 16-bit Thumb. See variable documentation for details.

CMAKE_ANDROID_ARM_NEON <#variable:CMAKE_ANDROID_ARM_NEON>

When the standalone toolchain targets ARM v7, optionally set thisto ON to target ARM NEON devices. See variable documentation for details.

The following variables will be computed and provided automatically:

CMAKE_SYSTEM_VERSION <#variable:CMAKE_SYSTEM_VERSION>

The Android API level detected from the standalone toolchain.

CMAKE_ANDROID_ARCH_ABI <#variable:CMAKE_ANDROID_ARCH_ABI>

The Android ABI detected from the standalone toolchain.

CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX <#variable:CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX>

The absolute path prefix to the binutils in the standalone toolchain.

CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX <#variable:CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX>

The host platform suffix of the binutils in the standalone toolchain.

For example, a toolchain file might contain:

```
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /path/to/android-toolchain)
```

Alternatively one may specify the values without a toolchain file:

```
$ cmake ../src \

  -DCMAKE_SYSTEM_NAME=Android \

  -DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/path/to/android-toolchain
```

### Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition
A toolchain file to configure one of the Visual Studio Generators <#visual-studio-generators> to build using NVIDIA Nsight Tegra targeting Android may look like this:

```
set(CMAKE_SYSTEM_NAME Android)
```

The CMAKE_GENERATOR_TOOLSET <#variable:CMAKE_GENERATOR_TOOLSET> may be set to select the Nsight Tegra "Toolchain Version" value.

See also target properties:

- ANDROID_ANT_ADDITIONAL_OPTIONS <#prop_tgt:ANDROID_ANT_ADDITIONAL_OPTIONS>

- ANDROID_API_MIN <#prop_tgt:ANDROID_API_MIN>

- ANDROID_API <#prop_tgt:ANDROID_API>

- ANDROID_ARCH <#prop_tgt:ANDROID_ARCH>

- ANDROID_ASSETS_DIRECTORIES <#prop_tgt:ANDROID_ASSETS_DIRECTORIES>

- ANDROID_GUI <#prop_tgt:ANDROID_GUI>

- ANDROID_JAR_DEPENDENCIES <#prop_tgt:ANDROID_JAR_DEPENDENCIES>

- ANDROID_JAR_DIRECTORIES <#prop_tgt:ANDROID_JAR_DIRECTORIES>

- ANDROID_JAVA_SOURCE_DIR <#prop_tgt:ANDROID_JAVA_SOURCE_DIR>

- ANDROID_NATIVE_LIB_DEPENDENCIES <#prop_tgt:ANDROID_NATIVE_LIB_DEPENDENCIES>

- ANDROID_NATIVE_LIB_DIRECTORIES <#prop_tgt:ANDROID_NATIVE_LIB_DIRECTORIES>

- ANDROID_PROCESS_MAX <#prop_tgt:ANDROID_PROCESS_MAX>

- ANDROID_PROGUARD_CONFIG_PATH <#prop_tgt:ANDROID_PROGUARD_CONFIG_PATH>

- ANDROID_PROGUARD <#prop_tgt:ANDROID_PROGUARD>

- ANDROID_SECURE_PROPS_PATH <#prop_tgt:ANDROID_SECURE_PROPS_PATH>

- ANDROID_SKIP_ANT_STEP <#prop_tgt:ANDROID_SKIP_ANT_STEP>

- ANDROID_STL_TYPE <#prop_tgt:ANDROID_STL_TYPE>

### Cross Compiling for iOS, tvOS, visionOS, or watchOS
For cross-compiling to iOS, tvOS, visionOS, or watchOS, the Xcode <#generator:Xcode> generator is recommended. The Unix Makefiles <#generator:Unix Makefiles> or Ninja <#generator:Ninja> generators can also be used, but they require the project to handle more areas like target CPU selection and code signing.

Any of the Apple device platforms can be targeted by setting the CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME> variable to a value from the table below. By default, the latest Device SDK is chosen. As for all Apple platforms, a different SDK (e.g. a simulator) can be selected by setting the CMAKE_OSX_SYSROOT <#variable:CMAKE_OSX_SYSROOT> variable, although this should rarely be necessary (see Switching Between Device and Simulator below). A list of available SDKs can be obtained by running xcodebuild -showsdks.

OS

CMAKE_SYSTEM_NAME

Device SDK (default)

Simulator SDK

Catalyst SDK

iOS

iOS

iphoneos

iphonesimulator

macosx

tvOS

tvOS

appletvos

appletvsimulator

N/A

visionOS

visionOS

xros

xrsimulator

N/A

watchOS

watchOS

watchos

watchsimulator

N/A

For example, to create a CMake configuration for iOS, the following command is sufficient:

```
cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS
```

Variable CMAKE_OSX_ARCHITECTURES <#variable:CMAKE_OSX_ARCHITECTURES> can be used to set architectures for both device and simulator. Variable CMAKE_OSX_DEPLOYMENT_TARGET <#variable:CMAKE_OSX_DEPLOYMENT_TARGET> can be used to set an iOS/tvOS/visionOS/watchOS deployment target.

The next example installs five architectures in a universal binary for an iOS library. It adds the relevant -miphoneos-version-min=9.3 or -mios-simulator-version-min=9.3 compiler flag where appropriate. Note that the CMAKE_IOS_INSTALL_COMBINED <#variable:CMAKE_IOS_INSTALL_COMBINED> variable used in the example is now deprecated, so this approach is no longer recommended.

```
$ cmake -S. -B_builds -GXcode \

    -DCMAKE_SYSTEM_NAME=iOS \

    "-DCMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64;i386;x86_64" \

    -DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 \

    -DCMAKE_INSTALL_PREFIX=`pwd`/_install \

    -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \

    -DCMAKE_IOS_INSTALL_COMBINED=YES
```

Example:

```
# CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(foo)
add_library(foo foo.cpp)
install(TARGETS foo DESTINATION lib)
```

Install:

```
$ cmake --build _builds --config Release --target install
```

Check library:

```
$ lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 armv7s x86_64 arm64
```

```
$ otool -l _install/lib/libfoo.a | grep -A2 LC_VERSION_MIN_IPHONEOS

      cmd LC_VERSION_MIN_IPHONEOS

  cmdsize 16

  version 9.3
```

### Code Signing
Some build artifacts for the embedded Apple platforms require mandatory code signing. If the Xcode <#generator:Xcode> generator is being used and code signing is required or desired, the development team ID can be specified via the CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM CMake variable. This team ID will then be included in the generated Xcode project. By default, CMake avoids the need for code signing during the internal configuration phase (i.e compiler ID and feature detection).

### Switching Between Device and Simulator
When configuring for any of the embedded platforms, one can target either real devices or the simulator. Both have their own separate SDK, but CMake only supports specifying a single SDK for the configuration phase. This means the developer must select one or the other at configuration time. When using the Xcode <#generator:Xcode> generator, this is less of a limitation because Xcode still allows you to build for either a device or a simulator, even though configuration was only performed for one of the two. From within the Xcode IDE, builds are performed for the selected "destination" platform. When building from the command line, the desired sdk can be specified directly by passing a -sdk option to the underlying build tool (xcodebuild). For example:

```
$ cmake --build ... -- -sdk iphonesimulator
```

Please note that checks made during configuration were performed against the configure-time SDK and might not hold true for other SDKs. Commands like find_package() <#command:find_package>, find_library() <#command:find_library>, etc. store and use details only for the configured SDK/platform, so they can be problematic if wanting to switch between device and simulator builds. You can follow the next rules to make device + simulator configuration work:

- Use explicit -l linker flag, e.g. target_link_libraries(foo PUBLIC "-lz")

- Use explicit -framework linker flag, e.g. target_link_libraries(foo PUBLIC "-framework CoreFoundation")

- Use find_package() <#command:find_package> only for libraries installed with CMAKE_IOS_INSTALL_COMBINED <#variable:CMAKE_IOS_INSTALL_COMBINED> feature

### Cross Compiling for Emscripten
Added in version 4.2.

A toolchain file may configure cross-compiling for Emscripten <https://emscripten.org/> by setting the CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME> variable to Emscripten. For example, a toolchain file might contain:

```
set(CMAKE_SYSTEM_NAME Emscripten)
set(CMAKE_C_COMPILER /path/to/emcc)
set(CMAKE_CXX_COMPILER /path/to/em++)
```

### Cross Compiling using Renesas compilers
For cross-compiling with Renesas compilers, specify at least:

CMAKE_SYSTEM_NAME <#variable:CMAKE_SYSTEM_NAME>

Set to Generic. Must be specified to enable cross compiling.

CMAKE_C_COMPILER <#variable:CMAKE_<LANG>_COMPILER>

Set to the path to the Renesas C compiler, e.g., ccrx, ccrl, or ccrh.

CMAKE_C_FLAGS <#variable:CMAKE_<LANG>_FLAGS>

Set to the -isa= or -cpu= flag the compiler requires.

See example toolchain files in the following sections.

### Renesas CC-RX

```
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER "ccrx.exe")
set(CMAKE_ASM_COMPILER "ccrx.exe") # if using ASM language
set(CMAKE_C_FLAGS "-isa=rxv3") # specify the version of target RX CPU
set(CMAKE_EXE_LINKER_FLAGS "-lnkopt=<your linker option here>")
```

### Renesas CC-RL

```
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER "ccrl.exe")
set(CMAKE_ASM_COMPILER "ccrl.exe") # if using ASM language
set(CMAKE_C_FLAGS "-cpu=S3") # specify the version of target RL CPU
# To avoid test executable runs out of const section's size.
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
# Specifying device file and section layout linker options through compiler driver.
set(CMAKE_EXE_LINKER_FLAGS "-lnkopt=-device=dr5f10y14.dvf -lnkopt=-auto_section_layout")
```

### Renesas CC-RH

```
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER "ccrh.exe")
set(CMAKE_ASM_COMPILER "ccrh.exe") # if using ASM language
set(CMAKE_C_FLAGS "-Xcommon=rh850") # specify the version of target RH850 CPU
set(CMAKE_EXE_LINKER_FLAGS "-lnkopt=<your linker option here>")
```

## Copyright
2000-2026 Kitware, Inc. and Contributors