1CMAKE-TOOLCHAINS(7)                  CMake                 CMAKE-TOOLCHAINS(7)
2
3
4

NAME

6       cmake-toolchains - CMake Toolchains Reference
7

INTRODUCTION

9       CMake uses a toolchain of utilities to compile, link libraries and cre‐
10       ate archives, and other tasks to drive the build. The toolchain  utili‐
11       ties  available  are  determined  by  the  languages enabled. In normal
12       builds, CMake automatically determines the toolchain  for  host  builds
13       based  on system introspection and defaults. In cross-compiling scenar‐
14       ios, a toolchain file may be specified with information about  compiler
15       and utility paths.
16

LANGUAGES

18       Languages  are  enabled  by  the  project() command.  Language-specific
19       built-in variables, such as  CMAKE_CXX_COMPILER,  CMAKE_CXX_COMPILER_ID
20       etc  are  set by invoking the project() command.  If no project command
21       is in the top-level CMakeLists file, one will be implicitly  generated.
22       By default the enabled languages are C and CXX:
23
24          project(C_Only C)
25
26       A  special value of NONE can also be used with the project() command to
27       enable no languages:
28
29          project(MyProject NONE)
30
31       The enable_language() command can be used to enable languages after the
32       project() command:
33
34          enable_language(CXX)
35
36       When  a  language is enabled, CMake finds a compiler for that language,
37       and determines some information, such as the vendor and version of  the
38       compiler,  the target architecture and bitwidth, the location of corre‐
39       sponding utilities etc.
40
41       The ENABLED_LANGUAGES global property contains the languages which  are
42       currently enabled.
43

VARIABLES AND PROPERTIES

45       Several  variables  relate  to  the  language components of a toolchain
46       which are enabled. CMAKE_<LANG>_COMPILER is the full path to  the  com‐
47       piler  used for <LANG>. CMAKE_<LANG>_COMPILER_ID is the identifier used
48       by CMake for the compiler and CMAKE_<LANG>_COMPILER_VERSION is the ver‐
49       sion of the compiler.
50
51       The CMAKE_<LANG>_FLAGS variables and the configuration-specific equiva‐
52       lents contain flags that will be added to the compile command when com‐
53       piling a file of a particular language.
54
55       As  the  linker is invoked by the compiler driver, CMake needs a way to
56       determine which compiler to use to invoke the linker.  This  is  calcu‐
57       lated by the LANGUAGE of source files in the target, and in the case of
58       static libraries, the language of the dependent libraries.  The  choice
59       CMake makes may be overridden with the LINKER_LANGUAGE target property.
60

TOOLCHAIN FEATURES

62       CMake  provides  the  try_compile()  command and wrapper macros such as
63       CheckCXXSourceCompiles, CheckCXXSymbolExists  and  CheckIncludeFile  to
64       test  capability  and availability of various toolchain features. These
65       APIs test the toolchain in some way and cache the result  so  that  the
66       test does not have to be performed again the next time CMake runs.
67
68       Some  toolchain  features  have  built-in handling in CMake, and do not
69       require compile-tests. For  example,  POSITION_INDEPENDENT_CODE  allows
70       specifying  that a target should be built as position-independent code,
71       if the compiler supports that feature. The <LANG>_VISIBILITY_PRESET and
72       VISIBILITY_INLINES_HIDDEN  target properties add flags for hidden visi‐
73       bility, if supported by the compiler.
74

CROSS COMPILING

76       If   cmake(1)   is   invoked   with   the   command   line    parameter
77       -DCMAKE_TOOLCHAIN_FILE=path/to/file,  the  file will be loaded early to
78       set values for the compilers.  The CMAKE_CROSSCOMPILING variable is set
79       to true when CMake is cross-compiling.
80
81       Note  that  using  the  CMAKE_SOURCE_DIR  or CMAKE_BINARY_DIR variables
82       inside a toolchain file is typically undesirable.  The  toolchain  file
83       is  used  in  contexts where these variables have different values when
84       used in different places (e.g. as part of a call to try_compile()).  In
85       most  cases, where there is a need to evaluate paths inside a toolchain
86       file,  the  more  appropriate  variable  to  use  would  be  CMAKE_CUR‐
87       RENT_LIST_DIR, since it always has an unambiguous, predictable value.
88
89   Cross Compiling for Linux
90       A typical cross-compiling toolchain for Linux has content such as:
91
92          set(CMAKE_SYSTEM_NAME Linux)
93          set(CMAKE_SYSTEM_PROCESSOR arm)
94
95          set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs)
96          set(CMAKE_STAGING_PREFIX /home/devel/stage)
97
98          set(tools /home/devel/gcc-4.7-linaro-rpi-gnueabihf)
99          set(CMAKE_C_COMPILER ${tools}/bin/arm-linux-gnueabihf-gcc)
100          set(CMAKE_CXX_COMPILER ${tools}/bin/arm-linux-gnueabihf-g++)
101
102          set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
103          set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
104          set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
105          set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
106
107       The CMAKE_SYSTEM_NAME is the CMake-identifier of the target platform to
108       build for.
109
110       The CMAKE_SYSTEM_PROCESSOR is the CMake-identifier of the target archi‐
111       tecture to build for.
112
113       The  CMAKE_SYSROOT  is  optional,  and may be specified if a sysroot is
114       available.
115
116       The CMAKE_STAGING_PREFIX is also optional. It may be used to specify  a
117       path  on the host to install to. The CMAKE_INSTALL_PREFIX is always the
118       runtime installation location, even when cross-compiling.
119
120       The CMAKE_<LANG>_COMPILER variables may be set to  full  paths,  or  to
121       names   of  compilers  to  search  for  in  standard  locations.    For
122       toolchains that do not support linking binaries without custom flags or
123       scripts  one  may  set  the  CMAKE_TRY_COMPILE_TARGET_TYPE  variable to
124       STATIC_LIBRARY to tell CMake not to try to link executables during  its
125       checks.
126
127       CMake   find_*   commands   will   look   in   the   sysroot,  and  the
128       CMAKE_FIND_ROOT_PATH entries by default in all cases, as well as  look‐
129       ing in the host system root prefix.  Although this can be controlled on
130       a case-by-case basis, when cross-compiling, it can be useful to exclude
131       looking in either the host or the target for particular artifacts. Gen‐
132       erally, includes, libraries and packages should be found in the  target
133       system  prefixes,  whereas executables which must be run as part of the
134       build should be found only on the host and not on the target.  This  is
135       the purpose of the CMAKE_FIND_ROOT_PATH_MODE_* variables.
136
137   Cross Compiling for the Cray Linux Environment
138       Cross  compiling for compute nodes in the Cray Linux Environment can be
139       done  without  needing   a   separate   toolchain   file.    Specifying
140       -DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment on the CMake command line will
141       ensure that the appropriate build settings and search paths are config‐
142       ured.   The platform will pull its configuration from the current envi‐
143       ronment variables and will configure a  project  to  use  the  compiler
144       wrappers  from  the  Cray Programming Environment’s PrgEnv-* modules if
145       present and loaded.
146
147       The default configuration of the Cray  Programming  Environment  is  to
148       only  support  static  libraries.   This  can  be overridden and shared
149       libraries enabled by setting the CRAYPE_LINK_TYPE environment  variable
150       to dynamic.
151
152       Running CMake without specifying CMAKE_SYSTEM_NAME will run the config‐
153       ure step in host mode assuming a standard Linux  environment.   If  not
154       overridden,  the  PrgEnv-*  compiler wrappers will end up getting used,
155       which if targeting the either the login node or compute node, is likely
156       not  the  desired  behavior.  The exception to this would be if you are
157       building directly on a NID instead  of  cross-compiling  from  a  login
158       node.  If  trying  to build software for a login node, you will need to
159       either first unload the currently loaded PrgEnv-* module or  explicitly
160       tell  CMake to use the system compilers in /usr/bin instead of the Cray
161       wrappers.  If instead targeting a compute node is desired, just specify
162       the CMAKE_SYSTEM_NAME as mentioned above.
163
164   Cross Compiling using Clang
165       Some  compilers  such  as  Clang  are  inherently cross compilers.  The
166       CMAKE_<LANG>_COMPILER_TARGET can be set to pass a value to  those  sup‐
167       ported compilers when compiling:
168
169          set(CMAKE_SYSTEM_NAME Linux)
170          set(CMAKE_SYSTEM_PROCESSOR arm)
171
172          set(triple arm-linux-gnueabihf)
173
174          set(CMAKE_C_COMPILER clang)
175          set(CMAKE_C_COMPILER_TARGET ${triple})
176          set(CMAKE_CXX_COMPILER clang++)
177          set(CMAKE_CXX_COMPILER_TARGET ${triple})
178
179       Similarly, some compilers do not ship their own supplementary utilities
180       such as linkers, but provide a way  to  specify  the  location  of  the
181       external  toolchain  which  will  be  used  by the compiler driver. The
182       CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN  variable  can  be  set  in  a
183       toolchain file to pass the path to the compiler driver.
184
185   Cross Compiling for QNX
186       As  the  Clang  compiler the QNX QCC compile is inherently a cross com‐
187       piler.  And the CMAKE_<LANG>_COMPILER_TARGET can be set to pass a value
188       to those supported compilers when compiling:
189
190          set(CMAKE_SYSTEM_NAME QNX)
191
192          set(arch gcc_ntoarmv7le)
193
194          set(CMAKE_C_COMPILER qcc)
195          set(CMAKE_C_COMPILER_TARGET ${arch})
196          set(CMAKE_CXX_COMPILER QCC)
197          set(CMAKE_CXX_COMPILER_TARGET ${arch})
198
199   Cross Compiling for Windows CE
200       Cross  compiling  for  Windows  CE requires the corresponding SDK being
201       installed on your system.   These  SDKs  are  usually  installed  under
202       C:/Program Files (x86)/Windows CE Tools/SDKs.
203
204       A  toolchain file to configure a Visual Studio generator for Windows CE
205       may look like this:
206
207          set(CMAKE_SYSTEM_NAME WindowsCE)
208
209          set(CMAKE_SYSTEM_VERSION 8.0)
210          set(CMAKE_SYSTEM_PROCESSOR arm)
211
212          set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0
213          set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310)
214
215       The CMAKE_GENERATOR_PLATFORM tells the  generator  which  SDK  to  use.
216       Further  CMAKE_SYSTEM_VERSION  tells the generator what version of Win‐
217       dows CE to use.  Currently version 8.0 (Windows Embedded Compact  2013)
218       is  supported  out  of  the box.  Other versions may require one to set
219       CMAKE_GENERATOR_TOOLSET to the correct value.
220
221   Cross Compiling for Windows 10 Universal Applications
222       A toolchain file to configure a Visual Studio generator for  a  Windows
223       10 Universal Application may look like this:
224
225          set(CMAKE_SYSTEM_NAME WindowsStore)
226          set(CMAKE_SYSTEM_VERSION 10.0)
227
228       A  Windows 10 Universal Application targets both Windows Store and Win‐
229       dows Phone.  Specify the CMAKE_SYSTEM_VERSION variable to  be  10.0  to
230       build  with  the  latest available Windows 10 SDK.  Specify a more spe‐
231       cific version (e.g. 10.0.10240.0 for RTM) to build with the correspond‐
232       ing SDK.
233
234   Cross Compiling for Windows Phone
235       A  toolchain  file  to  configure a Visual Studio generator for Windows
236       Phone may look like this:
237
238          set(CMAKE_SYSTEM_NAME WindowsPhone)
239          set(CMAKE_SYSTEM_VERSION 8.1)
240
241   Cross Compiling for Windows Store
242       A toolchain file to configure a Visual  Studio  generator  for  Windows
243       Store may look like this:
244
245          set(CMAKE_SYSTEM_NAME WindowsStore)
246          set(CMAKE_SYSTEM_VERSION 8.1)
247
248   Cross Compiling for Android
249       A  toolchain  file may configure cross-compiling for Android by setting
250       the CMAKE_SYSTEM_NAME variable to Android.   Further  configuration  is
251       specific to the Android development environment to be used.
252
253       For  Visual Studio Generators, CMake expects NVIDIA Nsight Tegra Visual
254       Studio Edition to be installed.  See that section for further  configu‐
255       ration details.
256
257       For  Makefile  Generators and the Ninja generator, CMake expects one of
258       these environments:
259
260       · NDK
261
262       · Standalone Toolchain
263
264       CMake uses the following steps to select one of the environments:
265
266       · If the CMAKE_ANDROID_NDK variable is set, the NDK  at  the  specified
267         location will be used.
268
269       · Else,  if the CMAKE_ANDROID_STANDALONE_TOOLCHAIN variable is set, the
270         Standalone Toolchain at the specified location will be used.
271
272       · Else, if the CMAKE_SYSROOT variable is set to a directory of the form
273         <ndk>/platforms/android-<api>/arch-<arch>,  the  <ndk>  part  will be
274         used as the value of CMAKE_ANDROID_NDK and the NDK will be used.
275
276       · Else, if the CMAKE_SYSROOT variable is set to a directory of the form
277         <standalone-toolchain>/sysroot,  the <standalone-toolchain> part will
278         be used as the value of  CMAKE_ANDROID_STANDALONE_TOOLCHAIN  and  the
279         Standalone Toolchain will be used.
280
281       · Else,  if  a cmake variable ANDROID_NDK is set it will be used as the
282         value of CMAKE_ANDROID_NDK, and the NDK will be used.
283
284       · Else, if a cmake variable  ANDROID_STANDALONE_TOOLCHAIN  is  set,  it
285         will  be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN, and
286         the Standalone Toolchain will be used.
287
288       · Else, if an environment variable ANDROID_NDK_ROOT or  ANDROID_NDK  is
289         set,  it  will be used as the value of CMAKE_ANDROID_NDK, and the NDK
290         will be used.
291
292       · Else, if an environment variable ANDROID_STANDALONE_TOOLCHAIN is  set
293         then   it   will   be  used  as  the  value  of  CMAKE_ANDROID_STAND‐
294         ALONE_TOOLCHAIN, and the Standalone Toolchain will be used.
295
296       · Else, an error diagnostic will be issued  that  neither  the  NDK  or
297         Standalone Toolchain can be found.
298
299   Cross Compiling for Android with the NDK
300       A toolchain file may configure Makefile Generators or the Ninja genera‐
301       tor to target Android for cross-compiling.
302
303       Configure use of an Android NDK with the following variables:
304
305       CMAKE_SYSTEM_NAME
306              Set to Android.  Must be specified to enable cross compiling for
307              Android.
308
309       CMAKE_SYSTEM_VERSION
310              Set  to  the  Android API level.  If not specified, the value is
311              determined as follows:
312
313              · If the CMAKE_ANDROID_API variable is set, its value is used as
314                the API level.
315
316              · If  the  CMAKE_SYSROOT  variable  is  set,  the  API  level is
317                detected from the NDK directory structure containing the  sys‐
318                root.
319
320              · Otherwise, the latest API level available in the NDK is used.
321
322       CMAKE_ANDROID_ARCH_ABI
323              Set  to  the Android ABI (architecture).  If not specified, this
324              variable will default to armeabi.  The CMAKE_ANDROID_ARCH  vari‐
325              able will be computed from CMAKE_ANDROID_ARCH_ABI automatically.
326              Also see the CMAKE_ANDROID_ARM_MODE  and  CMAKE_ANDROID_ARM_NEON
327              variables.
328
329       CMAKE_ANDROID_NDK
330              Set  to  the absolute path to the Android NDK root directory.  A
331              ${CMAKE_ANDROID_NDK}/platforms directory  must  exist.   If  not
332              specified,  a default for this variable will be chosen as speci‐
333              fied above.
334
335       CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
336              Set to a true value to use the deprecated per-api-level  headers
337              instead  of  the unified headers.  If not specified, the default
338              will be false unless using a NDK that does not  provide  unified
339              headers.
340
341       CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
342              On  NDK  r19  or  above,  this  variable must be unset or set to
343              clang.  On NDK r18 or below, set this to the version of the  NDK
344              toolchain to be selected as the compiler.  If not specified, the
345              default will be the latest available GCC toolchain.
346
347       CMAKE_ANDROID_STL_TYPE
348              Set to specify which C++ standard library to use.  If not speci‐
349              fied,  a  default  will be selected as described in the variable
350              documentation.
351
352       The following variables will be computed and provided automatically:
353
354       CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
355              The absolute path prefix to the binutils in the NDK toolchain.
356
357       CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
358              The host platform suffix of the binutils in the NDK toolchain.
359
360       For example, a toolchain file might contain:
361
362          set(CMAKE_SYSTEM_NAME Android)
363          set(CMAKE_SYSTEM_VERSION 21) # API level
364          set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
365          set(CMAKE_ANDROID_NDK /path/to/android-ndk)
366          set(CMAKE_ANDROID_STL_TYPE gnustl_static)
367
368       Alternatively one may specify the values without a toolchain file:
369
370          $ cmake ../src \
371            -DCMAKE_SYSTEM_NAME=Android \
372            -DCMAKE_SYSTEM_VERSION=21 \
373            -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \
374            -DCMAKE_ANDROID_NDK=/path/to/android-ndk \
375            -DCMAKE_ANDROID_STL_TYPE=gnustl_static
376
377   Cross Compiling for Android with a Standalone Toolchain
378       A toolchain file may configure Makefile Generators or the Ninja genera‐
379       tor to target Android for cross-compiling using a standalone toolchain.
380
381       Configure  use  of  an  Android standalone toolchain with the following
382       variables:
383
384       CMAKE_SYSTEM_NAME
385              Set to Android.  Must be specified to enable cross compiling for
386              Android.
387
388       CMAKE_ANDROID_STANDALONE_TOOLCHAIN
389              Set to the absolute path to the standalone toolchain root direc‐
390              tory.  A ${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot directory
391              must  exist.  If not specified, a default for this variable will
392              be chosen as specified above.
393
394       CMAKE_ANDROID_ARM_MODE
395              When the standalone toolchain targets ARM, optionally  set  this
396              to  ON  to target 32-bit ARM instead of 16-bit Thumb.  See vari‐
397              able documentation for details.
398
399       CMAKE_ANDROID_ARM_NEON
400              When the standalone toolchain targets  ARM  v7,  optionally  set
401              thisto  ON  to target ARM NEON devices.  See variable documenta‐
402              tion for details.
403
404       The following variables will be computed and provided automatically:
405
406       CMAKE_SYSTEM_VERSION
407              The Android API level detected from the standalone toolchain.
408
409       CMAKE_ANDROID_ARCH_ABI
410              The Android ABI detected from the standalone toolchain.
411
412       CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
413              The absolute path prefix  to  the  binutils  in  the  standalone
414              toolchain.
415
416       CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
417              The  host  platform  suffix  of  the  binutils in the standalone
418              toolchain.
419
420       For example, a toolchain file might contain:
421
422          set(CMAKE_SYSTEM_NAME Android)
423          set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /path/to/android-toolchain)
424
425       Alternatively one may specify the values without a toolchain file:
426
427          $ cmake ../src \
428            -DCMAKE_SYSTEM_NAME=Android \
429            -DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/path/to/android-toolchain
430
431   Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition
432       A toolchain file to configure one of the Visual  Studio  Generators  to
433       build using NVIDIA Nsight Tegra targeting Android may look like this:
434
435          set(CMAKE_SYSTEM_NAME Android)
436
437       The  CMAKE_GENERATOR_TOOLSET  may  be  set  to  select the Nsight Tegra
438       “Toolchain Version” value.
439
440       See also target properties:
441
442       · ANDROID_ANT_ADDITIONAL_OPTIONS
443
444       · ANDROID_API_MIN
445
446       · ANDROID_API
447
448       · ANDROID_ARCH
449
450       · ANDROID_ASSETS_DIRECTORIES
451
452       · ANDROID_GUI
453
454       · ANDROID_JAR_DEPENDENCIES
455
456       · ANDROID_JAR_DIRECTORIES
457
458       · ANDROID_JAVA_SOURCE_DIR
459
460       · ANDROID_NATIVE_LIB_DEPENDENCIES
461
462       · ANDROID_NATIVE_LIB_DIRECTORIES
463
464       · ANDROID_PROCESS_MAX
465
466       · ANDROID_PROGUARD_CONFIG_PATH
467
468       · ANDROID_PROGUARD
469
470       · ANDROID_SECURE_PROPS_PATH
471
472       · ANDROID_SKIP_ANT_STEP
473
474       · ANDROID_STL_TYPE
475
476   Cross Compiling for iOS, tvOS, or watchOS
477       For cross-compiling to iOS, tvOS, or watchOS, the  Xcode  generator  is
478       recommended.   The Unix Makefiles or Ninja generators can also be used,
479       but they require the project to  handle  more  areas  like  target  CPU
480       selection and code signing.
481
482       Any  of  the  three  systems  can be targeted by setting the CMAKE_SYS‐
483       TEM_NAME variable to a value from the table  below.   By  default,  the
484       latest  Device  SDK is chosen.  As for all Apple platforms, a different
485       SDK (e.g. a simulator) can be selected by setting the CMAKE_OSX_SYSROOT
486       variable,  although  this  should  rarely  be  necessary (see Switching
487       Between Device and Simulator below).  A list of available SDKs  can  be
488       obtained by running xcodebuild -showsdks.
489
490            ┌────────┬────────────┬──────────────────┬──────────────────┐
491            │OS      │ CMAKE_SYS‐ │ Device       SDK │ Simulator SDK    │
492            │        │ TEM_NAME   │ (default)        │                  │
493            ├────────┼────────────┼──────────────────┼──────────────────┤
494            │iOS     │ iOS        │ iphoneos         │ iphonesimulator  │
495            ├────────┼────────────┼──────────────────┼──────────────────┤
496            │tvOS    │ tvOS       │ appletvos        │ appletvsimulator │
497            ├────────┼────────────┼──────────────────┼──────────────────┤
498            │watchOS │ watchOS    │ watchos          │ watchsimulator   │
499            └────────┴────────────┴──────────────────┴──────────────────┘
500
501       For  example,  to  create  a CMake configuration for iOS, the following
502       command is sufficient:
503
504          cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS
505
506       Variable CMAKE_OSX_ARCHITECTURES can be used to set  architectures  for
507       both  device and simulator. Variable CMAKE_OSX_DEPLOYMENT_TARGET can be
508       used to set an iOS/tvOS/watchOS deployment target.
509
510       Next configuration will install fat 5 architectures iOS library and add
511       the -miphoneos-version-min=9.3/-mios-simulator-version-min=9.3 flags to
512       the compiler:
513
514          $ cmake -S. -B_builds -GXcode \
515              -DCMAKE_SYSTEM_NAME=iOS \
516              "-DCMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64;i386;x86_64" \
517              -DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 \
518              -DCMAKE_INSTALL_PREFIX=`pwd`/_install \
519              -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
520              -DCMAKE_IOS_INSTALL_COMBINED=YES
521
522       Example:
523
524          # CMakeLists.txt
525          cmake_minimum_required(VERSION 3.14)
526          project(foo)
527          add_library(foo foo.cpp)
528          install(TARGETS foo DESTINATION lib)
529
530       Install:
531
532          $ cmake --build _builds --config Release --target install
533
534       Check library:
535
536          $ lipo -info _install/lib/libfoo.a
537          Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 armv7s x86_64 arm64
538
539          $ otool -l _install/lib/libfoo.a | grep -A2 LC_VERSION_MIN_IPHONEOS
540                cmd LC_VERSION_MIN_IPHONEOS
541            cmdsize 16
542            version 9.3
543
544   Code Signing
545       Some build artifacts for the embedded Apple platforms require mandatory
546       code signing.  If the Xcode generator is being used and code signing is
547       required or desired, the development team ID can be specified  via  the
548       CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM  CMake  variable.   This team ID
549       will then be included in the  generated  Xcode  project.   By  default,
550       CMake  avoids  the need for code signing during the internal configura‐
551       tion phase (i.e compiler ID and feature detection).
552
553   Switching Between Device and Simulator
554       When configuring for any of the  embedded  platforms,  one  can  target
555       either  real  devices  or  the simulator.  Both have their own separate
556       SDK, but CMake only supports specifying a single SDK for the configura‐
557       tion  phase.   This means the developer must select one or the other at
558       configuration time.  When using the Xcode generator, this is less of  a
559       limitation  because Xcode still allows you to build for either a device
560       or a simulator, even though configuration was only performed for one of
561       the  two.   From  within  the  Xcode  IDE, builds are performed for the
562       selected “destination” platform.  When building from the command  line,
563       the  desired  sdk can be specified directly by passing a -sdk option to
564       the underlying build tool (xcodebuild).  For example:
565
566          $ cmake --build ... -- -sdk iphonesimulator
567
568       Please note  that  checks  made  during  configuration  were  performed
569       against  the configure-time SDK and might not hold true for other SDKs.
570       Commands  like  find_package(),  find_library(),  etc.  store  and  use
571       details  only  for the configured SDK/platform, so they can be problem‐
572       atic if wanting to switch between device and simulator builds. You  can
573       follow the next rules to make device + simulator configuration work:
574
575       · Use  explicit  -l  linker flag, e.g. target_link_libraries(foo PUBLIC
576         "-lz")
577
578       · Use explicit -framework linker flag,  e.g.  target_link_libraries(foo
579         PUBLIC "-framework CoreFoundation")
580
581       · Use    find_package()    only    for    libraries    installed   with
582         CMAKE_IOS_INSTALL_COMBINED feature
583
585       2000-2019 Kitware, Inc. and Contributors
586
587
588
589
5903.16.1                           Dec 14, 2019              CMAKE-TOOLCHAINS(7)
Impressum