1 <html><body><pre>Android.mk file syntax specification 2 3 Introduction: 4 ------------- 5 6 This document describes the syntax of Android.mk build file 7 written to describe your C and C++ source files to the Android 8 NDK. To understand what follows, it is assumed that you have 9 read the docs/OVERVIEW.html file that explains their role and 10 usage. 11 12 Overview: 13 --------- 14 15 An Android.mk file is written to describe your sources to the 16 build system. More specifically: 17 18 - The file is really a tiny GNU Makefile fragment that will be 19 parsed one or more times by the build system. As such, you 20 should try to minimize the variables you declare there and 21 do not assume that anything is not defined during parsing. 22 23 - The file syntax is designed to allow you to group your 24 sources into 'modules'. A module is one of the following: 25 26 - a static library 27 - a shared library 28 29 Only shared libraries will be installed/copied to your 30 application package. Static libraries can be used to generate 31 shared libraries though. 32 33 You can define one or more modules in each Android.mk file, 34 and you can use the same source file in several modules. 35 36 - The build system handles many details for you. For example, you 37 don't need to list header files or explicit dependencies between 38 generated files in your Android.mk. The NDK build system will 39 compute these automatically for you. 40 41 This also means that, when updating to newer releases of the NDK, 42 you should be able to benefit from new toolchain/platform support 43 without having to touch your Android.mk files. 44 45 Note that the syntax is *very* close to the one used in Android.mk files 46 distributed with the full open-source Android platform sources. While 47 the build system implementation that uses them is different, this is 48 an intentional design decision made to allow reuse of 'external' libraries' 49 source code easier for application developers. 50 51 Simple example: 52 --------------- 53 54 Before describing the syntax in details, let's consider the simple 55 "hello JNI" example, i.e. the files under: 56 57 apps/hello-jni/project 58 59 Here, we can see: 60 61 - The 'src' directory containing the Java sources for the 62 sample Android project. 63 64 - The 'jni' directory containing the native source for 65 the sample, i.e. 'jni/hello-jni.c' 66 67 This source file implements a simple shared library that 68 implements a native method that returns a string to the 69 VM application. 70 71 - The 'jni/Android.mk' file that describes the shared library 72 to the NDK build system. Its content is: 73 74 ---------- cut here ------------------ 75 LOCAL_PATH := $(call my-dir) 76 77 include $(CLEAR_VARS) 78 79 LOCAL_MODULE := hello-jni 80 LOCAL_SRC_FILES := hello-jni.c 81 82 include $(BUILD_SHARED_LIBRARY) 83 ---------- cut here ------------------ 84 85 Now, let's explain these lines: 86 87 LOCAL_PATH := $(call my-dir) 88 89 An Android.mk file must begin with the definition of the LOCAL_PATH variable. 90 It is used to locate source files in the development tree. In this example, 91 the macro function 'my-dir', provided by the build system, is used to return 92 the path of the current directory (i.e. the directory containing the 93 Android.mk file itself). 94 95 include $(CLEAR_VARS) 96 97 The CLEAR_VARS variable is provided by the build system and points to a 98 special GNU Makefile that will clear many LOCAL_XXX variables for you 99 (e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...), 100 with the exception of LOCAL_PATH. This is needed because all build 101 control files are parsed in a single GNU Make execution context where 102 all variables are global. 103 104 LOCAL_MODULE := hello-jni 105 106 The LOCAL_MODULE variable must be defined to identify each module you 107 describe in your Android.mk. The name must be *unique* and not contain 108 any spaces. Note that the build system will automatically add proper 109 prefix and suffix to the corresponding generated file. In other words, 110 a shared library module named 'foo' will generate 'libfoo.so'. 111 112 IMPORTANT NOTE: 113 If you name your module 'libfoo', the build system will not 114 add another 'lib' prefix and will generate libfoo.so as well. 115 This is to support Android.mk files that originate from the 116 Android platform sources, would you need to use these. 117 118 LOCAL_SRC_FILES := hello-jni.c 119 120 The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source 121 files that will be built and assembled into a module. Note that you should 122 not list header and included files here, because the build system will 123 compute dependencies automatically for you; just list the source files 124 that will be passed directly to a compiler, and you should be good. 125 126 Note that the default extension for C++ source files is '.cpp'. It is 127 however possible to specify a different one by defining the variable 128 LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will 129 work, but not 'cxx'). 130 131 include $(BUILD_SHARED_LIBRARY) 132 133 The BUILD_SHARED_LIBRARY is a variable provided by the build system that 134 points to a GNU Makefile script that is in charge of collecting all the 135 information you defined in LOCAL_XXX variables since the latest 136 'include $(CLEAR_VARS)' and determine what to build, and how to do it 137 exactly. There is also BUILD_STATIC_LIBRARY to generate a static library. 138 139 There are more complex examples in the samples directories, with commented 140 Android.mk files that you can look at. 141 142 Reference: 143 ---------- 144 145 This is the list of variables you should either rely on or define in 146 an Android.mk. You can define other variables for your own usage, but 147 the NDK build system reserves the following variable names: 148 149 - names that begin with LOCAL_ (e.g. LOCAL_MODULE) 150 - names that begin with PRIVATE_, NDK_ or APP_ (used internally) 151 - lower-case names (used internally, e.g. 'my-dir') 152 153 If you need to define your own convenience variables in an Android.mk 154 file, we recommend using the MY_ prefix, for a trivial example: 155 156 ---------- cut here ------------------ 157 MY_SOURCES := foo.c 158 ifneq ($(MY_CONFIG_BAR),) 159 MY_SOURCES += bar.c 160 endif 161 162 LOCAL_SRC_FILES += $(MY_SOURCES) 163 ---------- cut here ------------------ 164 165 So, here we go: 166 167 168 NDK-provided variables: 169 - - - - - - - - - - - - 170 171 These GNU Make variables are defined by the build system before 172 your Android.mk file is parsed. Note that under certain circumstances 173 the NDK might parse your Android.mk several times, each with different 174 definition for some of these variables. 175 176 CLEAR_VARS 177 Points to a build script that undefines nearly all LOCAL_XXX variables 178 listed in the "Module-description" section below. You must include 179 the script before starting a new module, e.g.: 180 181 include $(CLEAR_VARS) 182 183 BUILD_SHARED_LIBRARY 184 Points to a build script that collects all the information about the 185 module you provided in LOCAL_XXX variables and determines how to build 186 a target shared library from the sources you listed. Note that you 187 must have LOCAL_MODULE and LOCAL_SRC_FILES defined, at a minimum before 188 including this file. Example usage: 189 190 include $(BUILD_SHARED_LIBRARY) 191 192 note that this will generate a file named lib$(LOCAL_MODULE).so 193 194 BUILD_STATIC_LIBRARY 195 A variant of BUILD_SHARED_LIBRARY that is used to build a target static 196 library instead. Static libraries are not copied into your 197 project/packages but can be used to build shared libraries (see 198 LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES described below). 199 Example usage: 200 201 include $(BUILD_STATIC_LIBRARY) 202 203 Note that this will generate a file named lib$(LOCAL_MODULE).a 204 205 PREBUILT_SHARED_LIBRARY 206 Points to a build script used to specify a prebuilt shared library. 207 Unlike BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value 208 of LOCAL_SRC_FILES must be a single path to a prebuilt shared 209 library (e.g. foo/libfoo.so), instead of a source file. 210 211 You can reference the prebuilt library in another module using 212 the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more 213 information). 214 215 PREBUILT_STATIC_LIBRARY 216 This is the same as PREBUILT_SHARED_LIBRARY, but for a static library 217 file instead. See docs/PREBUILTS.html for more. 218 219 TARGET_ARCH 220 Name of the target CPU architecture as it is specified by the 221 full Android open-source build. This is 'arm' for any ARM-compatible 222 build, independent of the CPU architecture revision. 223 224 TARGET_PLATFORM 225 Name of the target Android platform when this Android.mk is parsed. 226 For example, 'android-3' correspond to Android 1.5 system images. For 227 a complete list of platform names and corresponding Android system 228 images, read docs/STABLE-APIS.html. 229 230 TARGET_ARCH_ABI 231 Name of the target CPU+ABI when this Android.mk is parsed. 232 Two values are supported at the moment: 233 234 armeabi 235 For ARMv5TE 236 237 armeabi-v7a 238 239 NOTE: Up to Android NDK 1.6_r1, this variable was simply defined 240 as 'arm'. However, the value has been redefined to better 241 match what is used internally by the Android platform. 242 243 For more details about architecture ABIs and corresponding 244 compatibility issues, please read docs/CPU-ARCH-ABIS.html 245 246 Other target ABIs will be introduced in future releases of the NDK 247 and will have a different name. Note that all ARM-based ABIs will 248 have 'TARGET_ARCH' defined to 'arm', but may have different 249 'TARGET_ARCH_ABI' 250 251 TARGET_ABI 252 The concatenation of target platform and ABI, it really is defined 253 as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want 254 to test against a specific target system image for a real device. 255 256 By default, this will be 'android-3-armeabi' 257 258 (Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default) 259 260 NDK-provided function macros: 261 - - - - - - - - - - - - - - - 262 263 The following are GNU Make 'function' macros, and must be evaluated 264 by using '$(call <function>)'. They return textual information. 265 266 my-dir 267 Returns the path of the last included Makefile, which typically is 268 the current Android.mk's directory. This is useful to define 269 LOCAL_PATH at the start of your Android.mk as with: 270 271 LOCAL_PATH := $(call my-dir) 272 273 IMPORTANT NOTE: Due to the way GNU Make works, this really returns 274 the path of the *last* *included* *Makefile* during the parsing of 275 build scripts. Do not call my-dir after including another file. 276 277 For example, consider the following example: 278 279 LOCAL_PATH := $(call my-dir) 280 281 ... declare one module 282 283 include $(LOCAL_PATH)/foo/Android.mk 284 285 LOCAL_PATH := $(call my-dir) 286 287 ... declare another module 288 289 The problem here is that the second call to 'my-dir' will define 290 LOCAL_PATH to $PATH/foo instead of $PATH, due to the include that 291 was performed before that. 292 293 For this reason, it's better to put additional includes after 294 everything else in an Android.mk, as in: 295 296 LOCAL_PATH := $(call my-dir) 297 298 ... declare one module 299 300 LOCAL_PATH := $(call my-dir) 301 302 ... declare another module 303 304 # extra includes at the end of the Android.mk 305 include $(LOCAL_PATH)/foo/Android.mk 306 307 If this is not convenient, save the value of the first my-dir call 308 into another variable, for example: 309 310 MY_LOCAL_PATH := $(call my-dir) 311 312 LOCAL_PATH := $(MY_LOCAL_PATH) 313 314 ... declare one module 315 316 include $(LOCAL_PATH)/foo/Android.mk 317 318 LOCAL_PATH := $(MY_LOCAL_PATH) 319 320 ... declare another module 321 322 323 324 all-subdir-makefiles 325 Returns a list of Android.mk located in all sub-directories of 326 the current 'my-dir' path. For example, consider the following 327 hierarchy: 328 329 sources/foo/Android.mk 330 sources/foo/lib1/Android.mk 331 sources/foo/lib2/Android.mk 332 333 If sources/foo/Android.mk contains the single line: 334 335 include $(call all-subdir-makefiles) 336 337 Then it will include automatically sources/foo/lib1/Android.mk and 338 sources/foo/lib2/Android.mk 339 340 This function can be used to provide deep-nested source directory 341 hierarchies to the build system. Note that by default, the NDK 342 will only look for files in sources/*/Android.mk 343 344 this-makefile 345 Returns the path of the current Makefile (i.e. where the function 346 is called). 347 348 parent-makefile 349 Returns the path of the parent Makefile in the inclusion tree, 350 i.e. the path of the Makefile that included the current one. 351 352 grand-parent-makefile 353 Guess what... 354 355 import-module 356 A function that allows you to find and include the Android.mk 357 of another module by name. A typical example is: 358 359 $(call import-module,<name>) 360 361 And this will look for the module tagged <name> in the list of 362 directories referenced by your NDK_MODULE_PATH environment 363 variable, and include its Android.mk automatically for you. 364 365 Read docs/IMPORT-MODULE.html for more details. 366 367 Module-description variables: 368 - - - - - - - - - - - - - - - 369 370 The following variables are used to describe your module to the build 371 system. You should define some of them between an 'include $(CLEAR_VARS)' 372 and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is 373 a script that will undefine/clear all of these variables, unless explicitly 374 noted in their description. 375 376 LOCAL_PATH 377 This variable is used to give the path of the current file. 378 You MUST define it at the start of your Android.mk, which can 379 be done with: 380 381 LOCAL_PATH := $(call my-dir) 382 383 This variable is *not* cleared by $(CLEAR_VARS) so only one 384 definition per Android.mk is needed (in case you define several 385 modules in a single file). 386 387 LOCAL_MODULE 388 This is the name of your module. It must be unique among all 389 module names, and shall not contain any space. You MUST define 390 it before including any $(BUILD_XXXX) script. 391 392 By default, the module name determines the name of generated files, 393 e.g. lib<foo>.so for a shared library module named <foo>. However 394 you should only refer to other modules with their 'normal' 395 name (e.g. <foo>) in your NDK build files (either Android.mk 396 or Application.mk) 397 398 You can override this default with LOCAL_MODULE_FILENAME (see below) 399 400 LOCAL_MODULE_FILENAME 401 This variable is optional, and allows you to redefine the name of 402 generated files. By default, module <foo> will always generate a 403 static library named lib<foo>.a or a shared library named lib<foo>.so, 404 which are standard Unix conventions. 405 406 You can override this by defining LOCAL_MODULE_FILENAME, For example: 407 408 LOCAL_MODULE := foo-version-1 409 LOCAL_MODULE_FILENAME := libfoo 410 411 NOTE: You should not put a path or file extension in your 412 LOCAL_MODULE_FILENAME, these will be handled automatically by the 413 build system. 414 415 LOCAL_SRC_FILES 416 This is a list of source files that will be built for your module. 417 Only list the files that will be passed to a compiler, since the 418 build system automatically computes dependencies for you. 419 420 Note that source files names are all relative to LOCAL_PATH and 421 you can use path components, e.g.: 422 423 LOCAL_SRC_FILES := foo.c \ 424 toto/bar.c 425 426 NOTE: Always use Unix-style forward slashes (/) in build files. 427 Windows-style back-slashes will not be handled properly. 428 429 LOCAL_CPP_EXTENSION 430 This is an optional variable that can be defined to indicate 431 the file extension(s) of C++ source files. They must begin with a dot. 432 The default is '.cpp' but you can change it. For example: 433 434 LOCAL_CPP_EXTENSION := .cxx 435 436 Since NDK r7, you can list several extensions in this variable, as in: 437 438 LOCAL_CPP_EXTENSION := .cxx .cpp .cc 439 440 LOCAL_CPP_FEATURES 441 This is an optional variable that can be defined to indicate 442 that your code relies on specific C++ features. To indicate that 443 your code uses RTTI (RunTime Type Information), use the following: 444 445 LOCAL_CPP_FEATURES := rtti 446 447 To indicate that your code uses C++ exceptions, use: 448 449 LOCAL_CPP_FEATURES := exceptions 450 451 You can also use both of them with (order is not important): 452 453 LOCAL_CPP_FEATURES := rtti features 454 455 The effect of this variable is to enable the right compiler/linker 456 flags when building your modules from sources. For prebuilt binaries, 457 this also helps declare which features the binary relies on to ensure 458 the final link works correctly. 459 460 It is recommended to use this variable instead of enabling -frtti and 461 -fexceptions directly in your LOCAL_CPPFLAGS definition. 462 463 LOCAL_C_INCLUDES 464 An optional list of paths, relative to the NDK *root* directory, 465 which will be appended to the include search path when compiling 466 all sources (C, C++ and Assembly). For example: 467 468 LOCAL_C_INCLUDES := sources/foo 469 470 Or even: 471 472 LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo 473 474 These are placed before any corresponding inclusion flag in 475 LOCAL_CFLAGS / LOCAL_CPPFLAGS 476 477 The LOCAL_C_INCLUDES path are also used automatically when 478 launching native debugging with ndk-gdb. 479 480 481 LOCAL_CFLAGS 482 An optional set of compiler flags that will be passed when building 483 C *and* C++ source files. 484 485 This can be useful to specify additional macro definitions or 486 compile options. 487 488 IMPORTANT: Try not to change the optimization/debugging level in 489 your Android.mk, this can be handled automatically for 490 you by specifying the appropriate information in 491 your Application.mk, and will let the NDK generate 492 useful data files used during debugging. 493 494 NOTE: In android-ndk-1.5_r1, the corresponding flags only applied 495 to C source files, not C++ ones. This has been corrected to 496 match the full Android build system behaviour. (You can use 497 LOCAL_CPPFLAGS to specify flags for C++ sources only now). 498 499 It is possible to specify additional include paths with 500 LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES 501 for this, since the paths will then also be used during native 502 debugging with ndk-gdb. 503 504 505 LOCAL_CXXFLAGS 506 An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete 507 as it may disappear in future releases of the NDK. 508 509 LOCAL_CPPFLAGS 510 An optional set of compiler flags that will be passed when building 511 C++ source files *only*. They will appear after the LOCAL_CFLAGS 512 on the compiler's command-line. 513 514 NOTE: In android-ndk-1.5_r1, the corresponding flags applied to 515 both C and C++ sources. This has been corrected to match the 516 full Android build system. (You can use LOCAL_CFLAGS to specify 517 flags for both C and C++ sources now). 518 519 LOCAL_STATIC_LIBRARIES 520 The list of static libraries modules (built with BUILD_STATIC_LIBRARY) 521 that should be linked to this module. This only makes sense in 522 shared library modules. 523 524 LOCAL_SHARED_LIBRARIES 525 The list of shared libraries *modules* this module depends on at runtime. 526 This is necessary at link time and to embed the corresponding information 527 in the generated file. 528 529 LOCAL_WHOLE_STATIC_LIBRARIES 530 A variant of LOCAL_STATIC_LIBRARIES used to express that the corresponding 531 library module should be used as "whole archives" to the linker. See the 532 GNU linker's documentation for the --whole-archive flag. 533 534 This is generally useful when there are circular dependencies between 535 several static libraries. Note that when used to build a shared library, 536 this will force all object files from your whole static libraries to be 537 added to the final binary. This is not true when generating executables 538 though. 539 540 LOCAL_LDLIBS 541 The list of additional linker flags to be used when building your 542 module. This is useful to pass the name of specific system libraries 543 with the "-l" prefix. For example, the following will tell the linker 544 to generate a module that links to /system/lib/libz.so at load time: 545 546 LOCAL_LDLIBS := -lz 547 548 See docs/STABLE-APIS.html for the list of exposed system libraries you 549 can linked against with this NDK release. 550 551 LOCAL_ALLOW_UNDEFINED_SYMBOLS 552 By default, any undefined reference encountered when trying to build 553 a shared library will result in an "undefined symbol" error. This is a 554 great help to catch bugs in your source code. 555 556 However, if for some reason you need to disable this check, set this 557 variable to 'true'. Note that the corresponding shared library may fail 558 to load at runtime. 559 560 LOCAL_ARM_MODE 561 By default, ARM target binaries will be generated in 'thumb' mode, where 562 each instruction are 16-bit wide. You can define this variable to 'arm' 563 if you want to force the generation of the module's object files in 564 'arm' (32-bit instructions) mode. E.g.: 565 566 LOCAL_ARM_MODE := arm 567 568 Note that you can also instruct the build system to only build specific 569 sources in ARM mode by appending an '.arm' suffix to its source file 570 name. For example, with: 571 572 LOCAL_SRC_FILES := foo.c bar.c.arm 573 574 Tells the build system to always compile 'bar.c' in ARM mode, and to 575 build foo.c according to the value of LOCAL_ARM_MODE. 576 577 NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force 578 the generation of ARM binaries as well. This is due to bugs in the 579 toolchain debugger that don't deal too well with thumb code. 580 581 LOCAL_ARM_NEON 582 Defining this variable to 'true' allows the use of ARM Advanced SIMD 583 (a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as 584 NEON instructions in Assembly files. 585 586 You should only define it when targeting the 'armeabi-v7a' ABI that 587 corresponds to the ARMv7 instruction set. Note that not all ARMv7 588 based CPUs support the NEON instruction set extensions and that you 589 should perform runtime detection to be able to use this code at runtime 590 safely. To learn more about this, please read the documentation at 591 docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html. 592 593 Alternatively, you can also specify that only specific source files 594 may be compiled with NEON support by using the '.neon' suffix, as 595 in: 596 597 LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon 598 599 In this example, 'foo.c' will be compiled in thumb+neon mode, 600 'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be 601 compiled in 'arm+neon' mode. 602 603 Note that the '.neon' suffix must appear after the '.arm' suffix 604 if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !) 605 606 LOCAL_DISABLE_NO_EXECUTE 607 Android NDK r4 added support for the "NX bit" security feature. 608 It is enabled by default, but you can disable it if you *really* 609 need to by setting this variable to 'true'. 610 611 NOTE: This feature does not modify the ABI and is only enabled on 612 kernels targeting ARMv6+ CPU devices. Machine code generated 613 with this feature enabled will run unmodified on devices 614 running earlier CPU architectures. 615 616 For more information, see: 617 618 http://en.wikipedia.org/wiki/NX_bit 619 http://www.gentoo.org/proj/en/hardened/gnu-stack.xml 620 621 LOCAL_EXPORT_CFLAGS 622 Define this variable to record a set of C/C++ compiler flags that will 623 be added to the LOCAL_CFLAGS definition of any other module that uses 624 this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES. 625 626 For example, consider the module 'foo' with the following definition: 627 628 include $(CLEAR_VARS) 629 LOCAL_MODULE := foo 630 LOCAL_SRC_FILES := foo/foo.c 631 LOCAL_EXPORT_CFLAGS := -DFOO=1 632 include $(BUILD_STATIC_LIBRARY) 633 634 And another module, named 'bar' that depends on it as: 635 636 include $(CLEAR_VARS) 637 LOCAL_MODULE := bar 638 LOCAL_SRC_FILES := bar.c 639 LOCAL_CFLAGS := -DBAR=2 640 LOCAL_STATIC_LIBRARIES := foo 641 include $(BUILD_SHARED_LIBRARY) 642 643 Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when 644 building bar.c 645 646 Exported flags are prepended to your module's LOCAL_CFLAGS so you can 647 easily override them. They are also transitive: if 'zoo' depends on 648 'bar' which depends on 'foo', then 'zoo' will also inherit all flags 649 exported by 'foo'. 650 651 Finally, exported flags are *not* used when building the module that 652 exports them. In the above example, -DFOO=1 would not be passed to the 653 compiler when building foo/foo.c. 654 655 LOCAL_EXPORT_CPPFLAGS 656 Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only. 657 658 LOCAL_EXPORT_C_INCLUDES 659 Same as LOCAL_EXPORT_CFLAGS, but for C include paths. 660 This can be useful if 'bar.c' wants to include headers 661 that are provided by module 'foo'. 662 663 LOCAL_EXPORT_LDLIBS 664 Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the 665 imported linker flags will be appended to your module's LOCAL_LDLIBS 666 though, due to the way Unix linkers work. 667 668 This is typically useful when module 'foo' is a static library and has 669 code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be 670 used to export the dependency. For example: 671 672 include $(CLEAR_VARS) 673 LOCAL_MODULE := foo 674 LOCAL_SRC_FILES := foo/foo.c 675 LOCAL_EXPORT_LDLIBS := -llog 676 include $(BUILD_STATIC_LIBRARY) 677 678 include $(CLEAR_VARS) 679 LOCAL_MODULE := bar 680 LOCAL_SRC_FILES := bar.c 681 LOCAL_STATIC_LIBRARIES := foo 682 include $(BUILD_SHARED_LIBRARY) 683 684 There, libbar.so will be built with a -llog at the end of the linker 685 command to indicate that it depends on the system logging library, 686 because it depends on 'foo'. 687 688 LOCAL_SHORT_COMMANDS 689 Set this variable to 'true' when your module has a very high number of 690 sources and/or dependent static or shared libraries. This forces the 691 build system to use an intermediate list file, and use it with the 692 library archiver or static linker with the @$(listfile) syntax. 693 694 This can be useful on Windows, where the command-line only accepts 695 a maximum of 8191 characters, which can be too small for complex 696 projects. 697 698 This also impacts the compilation of individual source files, placing 699 nearly all compiler flags inside list files too. 700 701 Note that any other value than 'true' will revert to the default 702 behaviour. You can also define APP_SHORT_COMMANDS in your 703 Application.mk to force this behaviour for all modules in your 704 project. 705 706 NOTE: We do not recommend enabling this feature by default, since it 707 makes the build slower. 708 709 LOCAL_FILTER_ASM 710 Define this variable to a shell command that will be used to filter 711 the assembly files from, or generated from, your LOCAL_SRC_FILES. 712 713 When it is defined, the following happens: 714 715 - Any C or C++ source file is generated into a temporary assembly 716 file (instead of being compiled into an object file). 717 718 - Any temporary assembly file, and any assembly file listed in 719 LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command 720 to generate _another_ temporary assembly file. 721 722 - These filtered assembly files are compiled into object file. 723 724 In other words, If you have: 725 726 LOCAL_SRC_FILES := foo.c bar.S 727 LOCAL_FILTER_ASM := myasmfilter 728 729 foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o 730 bar.S --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o 731 732 Were "1" corresponds to the compiler, "2" to the filter, and "3" to the 733 assembler. The filter must be a standalone shell command that takes the 734 name of the input file as its first argument, and the name of the output 735 file as the second one, as in: 736 737 myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S 738 myasmfilter bar.S $OBJS_DIR/bar.S 739 </pre></body></html> 740
