1CMAKE-TOOLCHAINS(7) CMake CMAKE-TOOLCHAINS(7)
2
3
4
6 cmake-toolchains - CMake Toolchains Reference
7
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
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
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
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
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)