1<html><body><pre>Android.mk file syntax specification 2 3Introduction: 4------------- 5 6This document describes the syntax of Android.mk build file 7written to describe your C and C++ source files to the Android 8NDK. To understand what follows, it is assumed that you have 9read the docs/OVERVIEW.html file that explains their role and 10usage. 11 12Overview: 13--------- 14 15An Android.mk file is written to describe your sources to the 16build 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 45Note that the syntax is *very* close to the one used in Android.mk files 46distributed with the full open-source Android platform sources. While 47the build system implementation that uses them is different, this is 48an intentional design decision made to allow reuse of 'external' libraries' 49source code easier for application developers. 50 51Simple example: 52--------------- 53 54Before 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 59Here, 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 85Now, let's explain these lines: 86 87 LOCAL_PATH := $(call my-dir) 88 89An Android.mk file must begin with the definition of the LOCAL_PATH variable. 90It is used to locate source files in the development tree. In this example, 91the macro function 'my-dir', provided by the build system, is used to return 92the path of the current directory (i.e. the directory containing the 93Android.mk file itself). 94 95 include $(CLEAR_VARS) 96 97The CLEAR_VARS variable is provided by the build system and points to a 98special GNU Makefile that will clear many LOCAL_XXX variables for you 99(e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...), 100with the exception of LOCAL_PATH. This is needed because all build 101control files are parsed in a single GNU Make execution context where 102all variables are global. 103 104 LOCAL_MODULE := hello-jni 105 106The LOCAL_MODULE variable must be defined to identify each module you 107describe in your Android.mk. The name must be *unique* and not contain 108any spaces. Note that the build system will automatically add proper 109prefix and suffix to the corresponding generated file. In other words, 110a shared library module named 'foo' will generate 'libfoo.so'. 111 112IMPORTANT NOTE: 113If you name your module 'libfoo', the build system will not 114add another 'lib' prefix and will generate libfoo.so as well. 115This is to support Android.mk files that originate from the 116Android platform sources, would you need to use these. 117 118 LOCAL_SRC_FILES := hello-jni.c 119 120The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source 121files that will be built and assembled into a module. Note that you should 122not list header and included files here, because the build system will 123compute dependencies automatically for you; just list the source files 124that will be passed directly to a compiler, and you should be good. 125 126Note that the default extension for C++ source files is '.cpp'. It is 127however possible to specify a different one by defining the variable 128LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will 129work, but not 'cxx'). 130 131 include $(BUILD_SHARED_LIBRARY) 132 133The BUILD_SHARED_LIBRARY is a variable provided by the build system that 134points to a GNU Makefile script that is in charge of collecting all the 135information you defined in LOCAL_XXX variables since the latest 136'include $(CLEAR_VARS)' and determine what to build, and how to do it 137exactly. There is also BUILD_STATIC_LIBRARY to generate a static library. 138 139There are more complex examples in the samples directories, with commented 140Android.mk files that you can look at. 141 142Reference: 143---------- 144 145This is the list of variables you should either rely on or define in 146an Android.mk. You can define other variables for your own usage, but 147the 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 153If you need to define your own convenience variables in an Android.mk 154file, 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 165So, here we go: 166 167 168NDK-provided variables: 169- - - - - - - - - - - - 170 171These GNU Make variables are defined by the build system before 172your Android.mk file is parsed. Note that under certain circumstances 173the NDK might parse your Android.mk several times, each with different 174definition for some of these variables. 175 176CLEAR_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 183BUILD_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 194BUILD_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 205PREBUILT_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 215PREBUILT_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 219TARGET_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 224TARGET_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 230TARGET_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 251TARGET_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 260NDK-provided function macros: 261- - - - - - - - - - - - - - - 262 263The following are GNU Make 'function' macros, and must be evaluated 264by using '$(call <function>)'. They return textual information. 265 266my-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 324all-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 344this-makefile 345 Returns the path of the current Makefile (i.e. where the function 346 is called). 347 348parent-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 352grand-parent-makefile 353 Guess what... 354 355import-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 367Module-description variables: 368- - - - - - - - - - - - - - - 369 370The following variables are used to describe your module to the build 371system. You should define some of them between an 'include $(CLEAR_VARS)' 372and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is 373a script that will undefine/clear all of these variables, unless explicitly 374noted in their description. 375 376LOCAL_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 387LOCAL_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 400LOCAL_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 415LOCAL_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 429LOCAL_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 440LOCAL_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 463LOCAL_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 481LOCAL_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 505LOCAL_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 509LOCAL_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 519LOCAL_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 524LOCAL_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 529LOCAL_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 540LOCAL_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 551LOCAL_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 560LOCAL_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 581LOCAL_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 606LOCAL_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 621LOCAL_DISABLE_RELRO 622 By default, NDK compiled code is built with read-only relocations 623 and GOT protection. This instructs the runtime linker to mark 624 certain regions of memory as being read-only after relocation, 625 making certain security exploits (such as GOT overwrites) harder 626 to perform. 627 628 It is enabled by default, but you can disable it if you *really* 629 need to by setting this variable to 'true'. 630 631 NOTE: These protections are only effective on newer Android devices 632 ("Jelly Bean" and beyond). The code will still run on older 633 versions (albeit without memory protections). 634 635 For more information, see: 636 637 http://isisblogs.poly.edu/2011/06/01/relro-relocation-read-only/ 638 http://www.akkadia.org/drepper/nonselsec.pdf (section 6) 639 640LOCAL_EXPORT_CFLAGS 641 Define this variable to record a set of C/C++ compiler flags that will 642 be added to the LOCAL_CFLAGS definition of any other module that uses 643 this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES. 644 645 For example, consider the module 'foo' with the following definition: 646 647 include $(CLEAR_VARS) 648 LOCAL_MODULE := foo 649 LOCAL_SRC_FILES := foo/foo.c 650 LOCAL_EXPORT_CFLAGS := -DFOO=1 651 include $(BUILD_STATIC_LIBRARY) 652 653 And another module, named 'bar' that depends on it as: 654 655 include $(CLEAR_VARS) 656 LOCAL_MODULE := bar 657 LOCAL_SRC_FILES := bar.c 658 LOCAL_CFLAGS := -DBAR=2 659 LOCAL_STATIC_LIBRARIES := foo 660 include $(BUILD_SHARED_LIBRARY) 661 662 Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when 663 building bar.c 664 665 Exported flags are prepended to your module's LOCAL_CFLAGS so you can 666 easily override them. They are also transitive: if 'zoo' depends on 667 'bar' which depends on 'foo', then 'zoo' will also inherit all flags 668 exported by 'foo'. 669 670 Finally, exported flags are *not* used when building the module that 671 exports them. In the above example, -DFOO=1 would not be passed to the 672 compiler when building foo/foo.c. 673 674LOCAL_EXPORT_CPPFLAGS 675 Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only. 676 677LOCAL_EXPORT_C_INCLUDES 678 Same as LOCAL_EXPORT_CFLAGS, but for C include paths. 679 This can be useful if 'bar.c' wants to include headers 680 that are provided by module 'foo'. 681 682LOCAL_EXPORT_LDLIBS 683 Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the 684 imported linker flags will be appended to your module's LOCAL_LDLIBS 685 though, due to the way Unix linkers work. 686 687 This is typically useful when module 'foo' is a static library and has 688 code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be 689 used to export the dependency. For example: 690 691 include $(CLEAR_VARS) 692 LOCAL_MODULE := foo 693 LOCAL_SRC_FILES := foo/foo.c 694 LOCAL_EXPORT_LDLIBS := -llog 695 include $(BUILD_STATIC_LIBRARY) 696 697 include $(CLEAR_VARS) 698 LOCAL_MODULE := bar 699 LOCAL_SRC_FILES := bar.c 700 LOCAL_STATIC_LIBRARIES := foo 701 include $(BUILD_SHARED_LIBRARY) 702 703 There, libbar.so will be built with a -llog at the end of the linker 704 command to indicate that it depends on the system logging library, 705 because it depends on 'foo'. 706 707LOCAL_SHORT_COMMANDS 708 Set this variable to 'true' when your module has a very high number of 709 sources and/or dependent static or shared libraries. This forces the 710 build system to use an intermediate list file, and use it with the 711 library archiver or static linker with the @$(listfile) syntax. 712 713 This can be useful on Windows, where the command-line only accepts 714 a maximum of 8191 characters, which can be too small for complex 715 projects. 716 717 This also impacts the compilation of individual source files, placing 718 nearly all compiler flags inside list files too. 719 720 Note that any other value than 'true' will revert to the default 721 behaviour. You can also define APP_SHORT_COMMANDS in your 722 Application.mk to force this behaviour for all modules in your 723 project. 724 725 NOTE: We do not recommend enabling this feature by default, since it 726 makes the build slower. 727 728LOCAL_FILTER_ASM 729 Define this variable to a shell command that will be used to filter 730 the assembly files from, or generated from, your LOCAL_SRC_FILES. 731 732 When it is defined, the following happens: 733 734 - Any C or C++ source file is generated into a temporary assembly 735 file (instead of being compiled into an object file). 736 737 - Any temporary assembly file, and any assembly file listed in 738 LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command 739 to generate _another_ temporary assembly file. 740 741 - These filtered assembly files are compiled into object file. 742 743 In other words, If you have: 744 745 LOCAL_SRC_FILES := foo.c bar.S 746 LOCAL_FILTER_ASM := myasmfilter 747 748 foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o 749 bar.S --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o 750 751 Were "1" corresponds to the compiler, "2" to the filter, and "3" to the 752 assembler. The filter must be a standalone shell command that takes the 753 name of the input file as its first argument, and the name of the output 754 file as the second one, as in: 755 756 myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S 757 myasmfilter bar.S $OBJS_DIR/bar.S 758 759</pre></body></html> 760