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          set(CMAKE_SYSROOT $ENV{QNX_TARGET})
200
201   Cross Compiling for Windows CE
202       Cross  compiling  for  Windows  CE requires the corresponding SDK being
203       installed on your system.   These  SDKs  are  usually  installed  under
204       C:/Program Files (x86)/Windows CE Tools/SDKs.
205
206       A  toolchain file to configure a Visual Studio generator for Windows CE
207       may look like this:
208
209          set(CMAKE_SYSTEM_NAME WindowsCE)
210
211          set(CMAKE_SYSTEM_VERSION 8.0)
212          set(CMAKE_SYSTEM_PROCESSOR arm)
213
214          set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0
215          set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310)
216
217       The CMAKE_GENERATOR_PLATFORM tells the  generator  which  SDK  to  use.
218       Further  CMAKE_SYSTEM_VERSION  tells the generator what version of Win‐
219       dows CE to use.  Currently version 8.0 (Windows Embedded Compact  2013)
220       is  supported  out  of  the box.  Other versions may require one to set
221       CMAKE_GENERATOR_TOOLSET to the correct value.
222
223   Cross Compiling for Windows 10 Universal Applications
224       A toolchain file to configure a Visual Studio generator for  a  Windows
225       10 Universal Application may look like this:
226
227          set(CMAKE_SYSTEM_NAME WindowsStore)
228          set(CMAKE_SYSTEM_VERSION 10.0)
229
230       A  Windows 10 Universal Application targets both Windows Store and Win‐
231       dows Phone.  Specify the CMAKE_SYSTEM_VERSION variable to  be  10.0  to
232       build  with  the  latest available Windows 10 SDK.  Specify a more spe‐
233       cific version (e.g. 10.0.10240.0 for RTM) to build with the correspond‐
234       ing SDK.
235
236   Cross Compiling for Windows Phone
237       A  toolchain  file  to  configure a Visual Studio generator for Windows
238       Phone may look like this:
239
240          set(CMAKE_SYSTEM_NAME WindowsPhone)
241          set(CMAKE_SYSTEM_VERSION 8.1)
242
243   Cross Compiling for Windows Store
244       A toolchain file to configure a Visual  Studio  generator  for  Windows
245       Store may look like this:
246
247          set(CMAKE_SYSTEM_NAME WindowsStore)
248          set(CMAKE_SYSTEM_VERSION 8.1)
249
250   Cross Compiling for Android
251       A  toolchain  file may configure cross-compiling for Android by setting
252       the CMAKE_SYSTEM_NAME variable to Android.   Further  configuration  is
253       specific to the Android development environment to be used.
254
255       For  Visual Studio Generators, CMake expects NVIDIA Nsight Tegra Visual
256       Studio Edition to be installed.  See that section for further  configu‐
257       ration details.
258
259       For  Makefile  Generators and the Ninja generator, CMake expects one of
260       these environments:
261
262       · NDK
263
264       · Standalone Toolchain
265
266       CMake uses the following steps to select one of the environments:
267
268       · If the CMAKE_ANDROID_NDK variable is set, the NDK  at  the  specified
269         location will be used.
270
271       · Else,  if the CMAKE_ANDROID_STANDALONE_TOOLCHAIN variable is set, the
272         Standalone Toolchain at the specified location will be used.
273
274       · Else, if the CMAKE_SYSROOT variable is set to a directory of the form
275         <ndk>/platforms/android-<api>/arch-<arch>,  the  <ndk>  part  will be
276         used as the value of CMAKE_ANDROID_NDK and the NDK will be used.
277
278       · Else, if the CMAKE_SYSROOT variable is set to a directory of the form
279         <standalone-toolchain>/sysroot,  the <standalone-toolchain> part will
280         be used as the value of  CMAKE_ANDROID_STANDALONE_TOOLCHAIN  and  the
281         Standalone Toolchain will be used.
282
283       · Else,  if  a cmake variable ANDROID_NDK is set it will be used as the
284         value of CMAKE_ANDROID_NDK, and the NDK will be used.
285
286       · Else, if a cmake variable  ANDROID_STANDALONE_TOOLCHAIN  is  set,  it
287         will  be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN, and
288         the Standalone Toolchain will be used.
289
290       · Else, if an environment variable ANDROID_NDK_ROOT or  ANDROID_NDK  is
291         set,  it  will be used as the value of CMAKE_ANDROID_NDK, and the NDK
292         will be used.
293
294       · Else, if an environment variable ANDROID_STANDALONE_TOOLCHAIN is  set
295         then   it   will   be  used  as  the  value  of  CMAKE_ANDROID_STAND‐
296         ALONE_TOOLCHAIN, and the Standalone Toolchain will be used.
297
298       · Else, an error diagnostic will be issued  that  neither  the  NDK  or
299         Standalone Toolchain can be found.
300
301   Cross Compiling for Android with the NDK
302       A toolchain file may configure Makefile Generators or the Ninja genera‐
303       tor to target Android for cross-compiling.
304
305       Configure use of an Android NDK with the following variables:
306
307       CMAKE_SYSTEM_NAME
308              Set to Android.  Must be specified to enable cross compiling for
309              Android.
310
311       CMAKE_SYSTEM_VERSION
312              Set  to  the  Android API level.  If not specified, the value is
313              determined as follows:
314
315              · If the CMAKE_ANDROID_API variable is set, its value is used as
316                the API level.
317
318              · If  the  CMAKE_SYSROOT  variable  is  set,  the  API  level is
319                detected from the NDK directory structure containing the  sys‐
320                root.
321
322              · Otherwise, the latest API level available in the NDK is used.
323
324       CMAKE_ANDROID_ARCH_ABI
325              Set  to  the Android ABI (architecture).  If not specified, this
326              variable will default to armeabi.  The CMAKE_ANDROID_ARCH  vari‐
327              able will be computed from CMAKE_ANDROID_ARCH_ABI automatically.
328              Also see the CMAKE_ANDROID_ARM_MODE  and  CMAKE_ANDROID_ARM_NEON
329              variables.
330
331       CMAKE_ANDROID_NDK
332              Set  to  the absolute path to the Android NDK root directory.  A
333              ${CMAKE_ANDROID_NDK}/platforms directory  must  exist.   If  not
334              specified,  a default for this variable will be chosen as speci‐
335              fied above.
336
337       CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
338              Set to a true value to use the deprecated per-api-level  headers
339              instead  of  the unified headers.  If not specified, the default
340              will be false unless using a NDK that does not  provide  unified
341              headers.
342
343       CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
344              On  NDK  r19  or  above,  this  variable must be unset or set to
345              clang.  On NDK r18 or below, set this to the version of the  NDK
346              toolchain to be selected as the compiler.  If not specified, the
347              default will be the latest available GCC toolchain.
348
349       CMAKE_ANDROID_STL_TYPE
350              Set to specify which C++ standard library to use.  If not speci‐
351              fied,  a  default  will be selected as described in the variable
352              documentation.
353
354       The following variables will be computed and provided automatically:
355
356       CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
357              The absolute path prefix to the binutils in the NDK toolchain.
358
359       CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
360              The host platform suffix of the binutils in the NDK toolchain.
361
362       For example, a toolchain file might contain:
363
364          set(CMAKE_SYSTEM_NAME Android)
365          set(CMAKE_SYSTEM_VERSION 21) # API level
366          set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
367          set(CMAKE_ANDROID_NDK /path/to/android-ndk)
368          set(CMAKE_ANDROID_STL_TYPE gnustl_static)
369
370       Alternatively one may specify the values without a toolchain file:
371
372          $ cmake ../src \
373            -DCMAKE_SYSTEM_NAME=Android \
374            -DCMAKE_SYSTEM_VERSION=21 \
375            -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \
376            -DCMAKE_ANDROID_NDK=/path/to/android-ndk \
377            -DCMAKE_ANDROID_STL_TYPE=gnustl_static
378
379   Cross Compiling for Android with a Standalone Toolchain
380       A toolchain file may configure Makefile Generators or the Ninja genera‐
381       tor to target Android for cross-compiling using a standalone toolchain.
382
383       Configure  use  of  an  Android standalone toolchain with the following
384       variables:
385
386       CMAKE_SYSTEM_NAME
387              Set to Android.  Must be specified to enable cross compiling for
388              Android.
389
390       CMAKE_ANDROID_STANDALONE_TOOLCHAIN
391              Set to the absolute path to the standalone toolchain root direc‐
392              tory.  A ${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot directory
393              must  exist.  If not specified, a default for this variable will
394              be chosen as specified above.
395
396       CMAKE_ANDROID_ARM_MODE
397              When the standalone toolchain targets ARM, optionally  set  this
398              to  ON  to target 32-bit ARM instead of 16-bit Thumb.  See vari‐
399              able documentation for details.
400
401       CMAKE_ANDROID_ARM_NEON
402              When the standalone toolchain targets  ARM  v7,  optionally  set
403              thisto  ON  to target ARM NEON devices.  See variable documenta‐
404              tion for details.
405
406       The following variables will be computed and provided automatically:
407
408       CMAKE_SYSTEM_VERSION
409              The Android API level detected from the standalone toolchain.
410
411       CMAKE_ANDROID_ARCH_ABI
412              The Android ABI detected from the standalone toolchain.
413
414       CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
415              The absolute path prefix  to  the  binutils  in  the  standalone
416              toolchain.
417
418       CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
419              The  host  platform  suffix  of  the  binutils in the standalone
420              toolchain.
421
422       For example, a toolchain file might contain:
423
424          set(CMAKE_SYSTEM_NAME Android)
425          set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /path/to/android-toolchain)
426
427       Alternatively one may specify the values without a toolchain file:
428
429          $ cmake ../src \
430            -DCMAKE_SYSTEM_NAME=Android \
431            -DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/path/to/android-toolchain
432
433   Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition
434       A toolchain file to configure one of the Visual  Studio  Generators  to
435       build using NVIDIA Nsight Tegra targeting Android may look like this:
436
437          set(CMAKE_SYSTEM_NAME Android)
438
439       The  CMAKE_GENERATOR_TOOLSET  may  be  set  to  select the Nsight Tegra
440       “Toolchain Version” value.
441
442       See also target properties:
443
444       · ANDROID_ANT_ADDITIONAL_OPTIONS
445
446       · ANDROID_API_MIN
447
448       · ANDROID_API
449
450       · ANDROID_ARCH
451
452       · ANDROID_ASSETS_DIRECTORIES
453
454       · ANDROID_GUI
455
456       · ANDROID_JAR_DEPENDENCIES
457
458       · ANDROID_JAR_DIRECTORIES
459
460       · ANDROID_JAVA_SOURCE_DIR
461
462       · ANDROID_NATIVE_LIB_DEPENDENCIES
463
464       · ANDROID_NATIVE_LIB_DIRECTORIES
465
466       · ANDROID_PROCESS_MAX
467
468       · ANDROID_PROGUARD_CONFIG_PATH
469
470       · ANDROID_PROGUARD
471
472       · ANDROID_SECURE_PROPS_PATH
473
474       · ANDROID_SKIP_ANT_STEP
475
476       · ANDROID_STL_TYPE
477
478   Cross Compiling for iOS, tvOS, or watchOS
479       For cross-compiling to iOS, tvOS, or watchOS, the  Xcode  generator  is
480       recommended.   The Unix Makefiles or Ninja generators can also be used,
481       but they require the project to  handle  more  areas  like  target  CPU
482       selection and code signing.
483
484       Any  of  the  three  systems  can be targeted by setting the CMAKE_SYS‐
485       TEM_NAME variable to a value from the table  below.   By  default,  the
486       latest  Device  SDK is chosen.  As for all Apple platforms, a different
487       SDK (e.g. a simulator) can be selected by setting the CMAKE_OSX_SYSROOT
488       variable,  although  this  should  rarely  be  necessary (see Switching
489       Between Device and Simulator below).  A list of available SDKs  can  be
490       obtained by running xcodebuild -showsdks.
491
492            ┌────────┬────────────┬──────────────────┬──────────────────┐
493            │OS      │ CMAKE_SYS‐ │ Device       SDK │ Simulator SDK    │
494            │        │ TEM_NAME   │ (default)        │                  │
495            ├────────┼────────────┼──────────────────┼──────────────────┤
496            │iOS     │ iOS        │ iphoneos         │ iphonesimulator  │
497            ├────────┼────────────┼──────────────────┼──────────────────┤
498            │tvOS    │ tvOS       │ appletvos        │ appletvsimulator │
499            ├────────┼────────────┼──────────────────┼──────────────────┤
500            │watchOS │ watchOS    │ watchos          │ watchsimulator   │
501            └────────┴────────────┴──────────────────┴──────────────────┘
502
503       For  example,  to  create  a CMake configuration for iOS, the following
504       command is sufficient:
505
506          cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS
507
508       Variable CMAKE_OSX_ARCHITECTURES can be used to set  architectures  for
509       both  device and simulator. Variable CMAKE_OSX_DEPLOYMENT_TARGET can be
510       used to set an iOS/tvOS/watchOS deployment target.
511
512       Next configuration will install fat 5 architectures iOS library and add
513       the -miphoneos-version-min=9.3/-mios-simulator-version-min=9.3 flags to
514       the compiler:
515
516          $ cmake -S. -B_builds -GXcode \
517              -DCMAKE_SYSTEM_NAME=iOS \
518              "-DCMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64;i386;x86_64" \
519              -DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 \
520              -DCMAKE_INSTALL_PREFIX=`pwd`/_install \
521              -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
522              -DCMAKE_IOS_INSTALL_COMBINED=YES
523
524       Example:
525
526          # CMakeLists.txt
527          cmake_minimum_required(VERSION 3.14)
528          project(foo)
529          add_library(foo foo.cpp)
530          install(TARGETS foo DESTINATION lib)
531
532       Install:
533
534          $ cmake --build _builds --config Release --target install
535
536       Check library:
537
538          $ lipo -info _install/lib/libfoo.a
539          Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 armv7s x86_64 arm64
540
541          $ otool -l _install/lib/libfoo.a | grep -A2 LC_VERSION_MIN_IPHONEOS
542                cmd LC_VERSION_MIN_IPHONEOS
543            cmdsize 16
544            version 9.3
545
546   Code Signing
547       Some build artifacts for the embedded Apple platforms require mandatory
548       code signing.  If the Xcode generator is being used and code signing is
549       required or desired, the development team ID can be specified  via  the
550       CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM  CMake  variable.   This team ID
551       will then be included in the  generated  Xcode  project.   By  default,
552       CMake  avoids  the need for code signing during the internal configura‐
553       tion phase (i.e compiler ID and feature detection).
554
555   Switching Between Device and Simulator
556       When configuring for any of the  embedded  platforms,  one  can  target
557       either  real  devices  or  the simulator.  Both have their own separate
558       SDK, but CMake only supports specifying a single SDK for the configura‐
559       tion  phase.   This means the developer must select one or the other at
560       configuration time.  When using the Xcode generator, this is less of  a
561       limitation  because Xcode still allows you to build for either a device
562       or a simulator, even though configuration was only performed for one of
563       the  two.   From  within  the  Xcode  IDE, builds are performed for the
564       selected “destination” platform.  When building from the command  line,
565       the  desired  sdk can be specified directly by passing a -sdk option to
566       the underlying build tool (xcodebuild).  For example:
567
568          $ cmake --build ... -- -sdk iphonesimulator
569
570       Please note  that  checks  made  during  configuration  were  performed
571       against  the configure-time SDK and might not hold true for other SDKs.
572       Commands  like  find_package(),  find_library(),  etc.  store  and  use
573       details  only  for the configured SDK/platform, so they can be problem‐
574       atic if wanting to switch between device and simulator builds. You  can
575       follow the next rules to make device + simulator configuration work:
576
577       · Use  explicit  -l  linker flag, e.g. target_link_libraries(foo PUBLIC
578         "-lz")
579
580       · Use explicit -framework linker flag,  e.g.  target_link_libraries(foo
581         PUBLIC "-framework CoreFoundation")
582
583       · Use    find_package()    only    for    libraries    installed   with
584         CMAKE_IOS_INSTALL_COMBINED feature
585
587       2000-2020 Kitware, Inc. and Contributors
588
589
590
591
5923.17.2                           Apr 28, 2020              CMAKE-TOOLCHAINS(7)
Impressum