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 samples/hello-jni 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 Four values are supported at the moment: 233 234 armeabi 235 For ARMv5TE 236 237 armeabi-v7a 238 For ARMv7 239 240 x86 241 For i686 242 243 mips 244 For mips-r1 245 246 NOTE: Up to Android NDK 1.6_r1, this variable was simply defined 247 as 'arm'. However, the value has been redefined to better 248 match what is used internally by the Android platform. 249 250 For more details about architecture ABIs and corresponding 251 compatibility issues, please read docs/CPU-ARCH-ABIS.html 252 253 Other target ABIs will be introduced in future releases of the NDK 254 and will have a different name. Note that all ARM-based ABIs will 255 have 'TARGET_ARCH' defined to 'arm', but may have different 256 'TARGET_ARCH_ABI' 257 258TARGET_ABI 259 The concatenation of target platform and ABI, it really is defined 260 as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want 261 to test against a specific target system image for a real device. 262 263 By default, this will be 'android-3-armeabi' 264 265 (Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default) 266 267NDK-provided function macros: 268- - - - - - - - - - - - - - - 269 270The following are GNU Make 'function' macros, and must be evaluated 271by using '$(call <function>)'. They return textual information. 272 273my-dir 274 Returns the path of the last included Makefile, which typically is 275 the current Android.mk's directory. This is useful to define 276 LOCAL_PATH at the start of your Android.mk as with: 277 278 LOCAL_PATH := $(call my-dir) 279 280 IMPORTANT NOTE: Due to the way GNU Make works, this really returns 281 the path of the *last* *included* *Makefile* during the parsing of 282 build scripts. Do not call my-dir after including another file. 283 284 For example, consider the following example: 285 286 LOCAL_PATH := $(call my-dir) 287 288 ... declare one module 289 290 include $(LOCAL_PATH)/foo/Android.mk 291 292 LOCAL_PATH := $(call my-dir) 293 294 ... declare another module 295 296 The problem here is that the second call to 'my-dir' will define 297 LOCAL_PATH to $PATH/foo instead of $PATH, due to the include that 298 was performed before that. 299 300 For this reason, it's better to put additional includes after 301 everything else in an Android.mk, as in: 302 303 LOCAL_PATH := $(call my-dir) 304 305 ... declare one module 306 307 LOCAL_PATH := $(call my-dir) 308 309 ... declare another module 310 311 # extra includes at the end of the Android.mk 312 include $(LOCAL_PATH)/foo/Android.mk 313 314 If this is not convenient, save the value of the first my-dir call 315 into another variable, for example: 316 317 MY_LOCAL_PATH := $(call my-dir) 318 319 LOCAL_PATH := $(MY_LOCAL_PATH) 320 321 ... declare one module 322 323 include $(LOCAL_PATH)/foo/Android.mk 324 325 LOCAL_PATH := $(MY_LOCAL_PATH) 326 327 ... declare another module 328 329 330 331all-subdir-makefiles 332 Returns a list of Android.mk located in all sub-directories of 333 the current 'my-dir' path. For example, consider the following 334 hierarchy: 335 336 sources/foo/Android.mk 337 sources/foo/lib1/Android.mk 338 sources/foo/lib2/Android.mk 339 340 If sources/foo/Android.mk contains the single line: 341 342 include $(call all-subdir-makefiles) 343 344 Then it will include automatically sources/foo/lib1/Android.mk and 345 sources/foo/lib2/Android.mk 346 347 This function can be used to provide deep-nested source directory 348 hierarchies to the build system. Note that by default, the NDK 349 will only look for files in sources/*/Android.mk 350 351this-makefile 352 Returns the path of the current Makefile (i.e. where the function 353 is called). 354 355parent-makefile 356 Returns the path of the parent Makefile in the inclusion tree, 357 i.e. the path of the Makefile that included the current one. 358 359grand-parent-makefile 360 Guess what... 361 362import-module 363 A function that allows you to find and include the Android.mk 364 of another module by name. A typical example is: 365 366 $(call import-module,<name>) 367 368 And this will look for the module tagged <name> in the list of 369 directories referenced by your NDK_MODULE_PATH environment 370 variable, and include its Android.mk automatically for you. 371 372 Read docs/IMPORT-MODULE.html for more details. 373 374Module-description variables: 375- - - - - - - - - - - - - - - 376 377The following variables are used to describe your module to the build 378system. You should define some of them between an 'include $(CLEAR_VARS)' 379and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is 380a script that will undefine/clear all of these variables, unless explicitly 381noted in their description. 382 383LOCAL_PATH 384 This variable is used to give the path of the current file. 385 You MUST define it at the start of your Android.mk, which can 386 be done with: 387 388 LOCAL_PATH := $(call my-dir) 389 390 This variable is *not* cleared by $(CLEAR_VARS) so only one 391 definition per Android.mk is needed (in case you define several 392 modules in a single file). 393 394LOCAL_MODULE 395 This is the name of your module. It must be unique among all 396 module names, and shall not contain any space. You MUST define 397 it before including any $(BUILD_XXXX) script. 398 399 By default, the module name determines the name of generated files, 400 e.g. lib<foo>.so for a shared library module named <foo>. However 401 you should only refer to other modules with their 'normal' 402 name (e.g. <foo>) in your NDK build files (either Android.mk 403 or Application.mk) 404 405 You can override this default with LOCAL_MODULE_FILENAME (see below) 406 407LOCAL_MODULE_FILENAME 408 This variable is optional, and allows you to redefine the name of 409 generated files. By default, module <foo> will always generate a 410 static library named lib<foo>.a or a shared library named lib<foo>.so, 411 which are standard Unix conventions. 412 413 You can override this by defining LOCAL_MODULE_FILENAME, For example: 414 415 LOCAL_MODULE := foo-version-1 416 LOCAL_MODULE_FILENAME := libfoo 417 418 NOTE: You should not put a path or file extension in your 419 LOCAL_MODULE_FILENAME, these will be handled automatically by the 420 build system. 421 422LOCAL_SRC_FILES 423 This is a list of source files that will be built for your module. 424 Only list the files that will be passed to a compiler, since the 425 build system automatically computes dependencies for you. 426 427 Note that source files names are all relative to LOCAL_PATH and 428 you can use path components, e.g.: 429 430 LOCAL_SRC_FILES := foo.c \ 431 toto/bar.c 432 433 NOTE: Always use Unix-style forward slashes (/) in build files. 434 Windows-style back-slashes will not be handled properly. 435 436LOCAL_CPP_EXTENSION 437 This is an optional variable that can be defined to indicate 438 the file extension(s) of C++ source files. They must begin with a dot. 439 The default is '.cpp' but you can change it. For example: 440 441 LOCAL_CPP_EXTENSION := .cxx 442 443 Since NDK r7, you can list several extensions in this variable, as in: 444 445 LOCAL_CPP_EXTENSION := .cxx .cpp .cc 446 447LOCAL_CPP_FEATURES 448 This is an optional variable that can be defined to indicate 449 that your code relies on specific C++ features. To indicate that 450 your code uses RTTI (RunTime Type Information), use the following: 451 452 LOCAL_CPP_FEATURES := rtti 453 454 To indicate that your code uses C++ exceptions, use: 455 456 LOCAL_CPP_FEATURES := exceptions 457 458 You can also use both of them with (order is not important): 459 460 LOCAL_CPP_FEATURES := rtti features 461 462 The effect of this variable is to enable the right compiler/linker 463 flags when building your modules from sources. For prebuilt binaries, 464 this also helps declare which features the binary relies on to ensure 465 the final link works correctly. 466 467 It is recommended to use this variable instead of enabling -frtti and 468 -fexceptions directly in your LOCAL_CPPFLAGS definition. 469 470LOCAL_C_INCLUDES 471 An optional list of paths, relative to the NDK *root* directory, 472 which will be appended to the include search path when compiling 473 all sources (C, C++ and Assembly). For example: 474 475 LOCAL_C_INCLUDES := sources/foo 476 477 Or even: 478 479 LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo 480 481 These are placed before any corresponding inclusion flag in 482 LOCAL_CFLAGS / LOCAL_CPPFLAGS 483 484 The LOCAL_C_INCLUDES path are also used automatically when 485 launching native debugging with ndk-gdb. 486 487 488LOCAL_CFLAGS 489 An optional set of compiler flags that will be passed when building 490 C *and* C++ source files. 491 492 This can be useful to specify additional macro definitions or 493 compile options. 494 495 IMPORTANT: Try not to change the optimization/debugging level in 496 your Android.mk, this can be handled automatically for 497 you by specifying the appropriate information in 498 your Application.mk, and will let the NDK generate 499 useful data files used during debugging. 500 501 NOTE: In android-ndk-1.5_r1, the corresponding flags only applied 502 to C source files, not C++ ones. This has been corrected to 503 match the full Android build system behaviour. (You can use 504 LOCAL_CPPFLAGS to specify flags for C++ sources only now). 505 506 It is possible to specify additional include paths with 507 LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES 508 for this, since the paths will then also be used during native 509 debugging with ndk-gdb. 510 511 512LOCAL_CXXFLAGS 513 An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete 514 as it may disappear in future releases of the NDK. 515 516LOCAL_CPPFLAGS 517 An optional set of compiler flags that will be passed when building 518 C++ source files *only*. They will appear after the LOCAL_CFLAGS 519 on the compiler's command-line. 520 521 NOTE: In android-ndk-1.5_r1, the corresponding flags applied to 522 both C and C++ sources. This has been corrected to match the 523 full Android build system. (You can use LOCAL_CFLAGS to specify 524 flags for both C and C++ sources now). 525 526LOCAL_STATIC_LIBRARIES 527 The list of static libraries modules (built with BUILD_STATIC_LIBRARY) 528 that should be linked to this module. This only makes sense in 529 shared library modules. 530 531LOCAL_SHARED_LIBRARIES 532 The list of shared libraries *modules* this module depends on at runtime. 533 This is necessary at link time and to embed the corresponding information 534 in the generated file. 535 536LOCAL_WHOLE_STATIC_LIBRARIES 537 A variant of LOCAL_STATIC_LIBRARIES used to express that the corresponding 538 library module should be used as "whole archives" to the linker. See the 539 GNU linker's documentation for the --whole-archive flag. 540 541 This is generally useful when there are circular dependencies between 542 several static libraries. Note that when used to build a shared library, 543 this will force all object files from your whole static libraries to be 544 added to the final binary. This is not true when generating executables 545 though. 546 547LOCAL_LDLIBS 548 The list of additional linker flags to be used when building your 549 module. This is useful to pass the name of specific system libraries 550 with the "-l" prefix. For example, the following will tell the linker 551 to generate a module that links to /system/lib/libz.so at load time: 552 553 LOCAL_LDLIBS := -lz 554 555 See docs/STABLE-APIS.html for the list of exposed system libraries you 556 can linked against with this NDK release. 557 558LOCAL_LDFLAGS 559 The list of other linker flags to be used when building your module. 560 For example, the following will use linker ld.bfd on ARM/X86 GCC 4.6/4.7 561 where ld.gold is the default 562 563 LOCAL_LDFLAGS += -fuse-ld=bfd 564 565LOCAL_ALLOW_UNDEFINED_SYMBOLS 566 By default, any undefined reference encountered when trying to build 567 a shared library will result in an "undefined symbol" error. This is a 568 great help to catch bugs in your source code. 569 570 However, if for some reason you need to disable this check, set this 571 variable to 'true'. Note that the corresponding shared library may fail 572 to load at runtime. 573 574LOCAL_ARM_MODE 575 By default, ARM target binaries will be generated in 'thumb' mode, where 576 each instruction are 16-bit wide. You can define this variable to 'arm' 577 if you want to force the generation of the module's object files in 578 'arm' (32-bit instructions) mode. E.g.: 579 580 LOCAL_ARM_MODE := arm 581 582 Note that you can also instruct the build system to only build specific 583 sources in ARM mode by appending an '.arm' suffix to its source file 584 name. For example, with: 585 586 LOCAL_SRC_FILES := foo.c bar.c.arm 587 588 Tells the build system to always compile 'bar.c' in ARM mode, and to 589 build foo.c according to the value of LOCAL_ARM_MODE. 590 591 NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force 592 the generation of ARM binaries as well. This is due to bugs in the 593 toolchain debugger that don't deal too well with thumb code. 594 595LOCAL_ARM_NEON 596 Defining this variable to 'true' allows the use of ARM Advanced SIMD 597 (a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as 598 NEON instructions in Assembly files. 599 600 You should only define it when targeting the 'armeabi-v7a' ABI that 601 corresponds to the ARMv7 instruction set. Note that not all ARMv7 602 based CPUs support the NEON instruction set extensions and that you 603 should perform runtime detection to be able to use this code at runtime 604 safely. To learn more about this, please read the documentation at 605 docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html. 606 607 Alternatively, you can also specify that only specific source files 608 may be compiled with NEON support by using the '.neon' suffix, as 609 in: 610 611 LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon 612 613 In this example, 'foo.c' will be compiled in thumb+neon mode, 614 'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be 615 compiled in 'arm+neon' mode. 616 617 Note that the '.neon' suffix must appear after the '.arm' suffix 618 if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !) 619 620LOCAL_DISABLE_NO_EXECUTE 621 Android NDK r4 added support for the "NX bit" security feature. 622 It is enabled by default, but you can disable it if you *really* 623 need to by setting this variable to 'true'. 624 625 NOTE: This feature does not modify the ABI and is only enabled on 626 kernels targeting ARMv6+ CPU devices. Machine code generated 627 with this feature enabled will run unmodified on devices 628 running earlier CPU architectures. 629 630 For more information, see: 631 632 http://en.wikipedia.org/wiki/NX_bit 633 http://www.gentoo.org/proj/en/hardened/gnu-stack.xml 634 635LOCAL_DISABLE_RELRO 636 By default, NDK compiled code is built with read-only relocations 637 and GOT protection. This instructs the runtime linker to mark 638 certain regions of memory as being read-only after relocation, 639 making certain security exploits (such as GOT overwrites) harder 640 to perform. 641 642 It is enabled by default, but you can disable it if you *really* 643 need to by setting this variable to 'true'. 644 645 NOTE: These protections are only effective on newer Android devices 646 ("Jelly Bean" and beyond). The code will still run on older 647 versions (albeit without memory protections). 648 649 For more information, see: 650 651 http://isisblogs.poly.edu/2011/06/01/relro-relocation-read-only/ 652 http://www.akkadia.org/drepper/nonselsec.pdf (section 6) 653 654LOCAL_EXPORT_CFLAGS 655 Define this variable to record a set of C/C++ compiler flags that will 656 be added to the LOCAL_CFLAGS definition of any other module that uses 657 this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES. 658 659 For example, consider the module 'foo' with the following definition: 660 661 include $(CLEAR_VARS) 662 LOCAL_MODULE := foo 663 LOCAL_SRC_FILES := foo/foo.c 664 LOCAL_EXPORT_CFLAGS := -DFOO=1 665 include $(BUILD_STATIC_LIBRARY) 666 667 And another module, named 'bar' that depends on it as: 668 669 include $(CLEAR_VARS) 670 LOCAL_MODULE := bar 671 LOCAL_SRC_FILES := bar.c 672 LOCAL_CFLAGS := -DBAR=2 673 LOCAL_STATIC_LIBRARIES := foo 674 include $(BUILD_SHARED_LIBRARY) 675 676 Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when 677 building bar.c 678 679 Exported flags are prepended to your module's LOCAL_CFLAGS so you can 680 easily override them. They are also transitive: if 'zoo' depends on 681 'bar' which depends on 'foo', then 'zoo' will also inherit all flags 682 exported by 'foo'. 683 684 Finally, exported flags are *not* used when building the module that 685 exports them. In the above example, -DFOO=1 would not be passed to the 686 compiler when building foo/foo.c. 687 688LOCAL_EXPORT_CPPFLAGS 689 Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only. 690 691LOCAL_EXPORT_C_INCLUDES 692 Same as LOCAL_EXPORT_CFLAGS, but for C include paths. 693 This can be useful if 'bar.c' wants to include headers 694 that are provided by module 'foo'. 695 696LOCAL_EXPORT_LDLIBS 697 Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the 698 imported linker flags will be appended to your module's LOCAL_LDLIBS 699 though, due to the way Unix linkers work. 700 701 This is typically useful when module 'foo' is a static library and has 702 code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be 703 used to export the dependency. For example: 704 705 include $(CLEAR_VARS) 706 LOCAL_MODULE := foo 707 LOCAL_SRC_FILES := foo/foo.c 708 LOCAL_EXPORT_LDLIBS := -llog 709 include $(BUILD_STATIC_LIBRARY) 710 711 include $(CLEAR_VARS) 712 LOCAL_MODULE := bar 713 LOCAL_SRC_FILES := bar.c 714 LOCAL_STATIC_LIBRARIES := foo 715 include $(BUILD_SHARED_LIBRARY) 716 717 There, libbar.so will be built with a -llog at the end of the linker 718 command to indicate that it depends on the system logging library, 719 because it depends on 'foo'. 720 721LOCAL_SHORT_COMMANDS 722 Set this variable to 'true' when your module has a very high number of 723 sources and/or dependent static or shared libraries. This forces the 724 build system to use an intermediate list file, and use it with the 725 library archiver or static linker with the @$(listfile) syntax. 726 727 This can be useful on Windows, where the command-line only accepts 728 a maximum of 8191 characters, which can be too small for complex 729 projects. 730 731 This also impacts the compilation of individual source files, placing 732 nearly all compiler flags inside list files too. 733 734 Note that any other value than 'true' will revert to the default 735 behaviour. You can also define APP_SHORT_COMMANDS in your 736 Application.mk to force this behaviour for all modules in your 737 project. 738 739 NOTE: We do not recommend enabling this feature by default, since it 740 makes the build slower. 741 742LOCAL_FILTER_ASM 743 Define this variable to a shell command that will be used to filter 744 the assembly files from, or generated from, your LOCAL_SRC_FILES. 745 746 When it is defined, the following happens: 747 748 - Any C or C++ source file is generated into a temporary assembly 749 file (instead of being compiled into an object file). 750 751 - Any temporary assembly file, and any assembly file listed in 752 LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command 753 to generate _another_ temporary assembly file. 754 755 - These filtered assembly files are compiled into object file. 756 757 In other words, If you have: 758 759 LOCAL_SRC_FILES := foo.c bar.S 760 LOCAL_FILTER_ASM := myasmfilter 761 762 foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o 763 bar.S --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o 764 765 Were "1" corresponds to the compiler, "2" to the filter, and "3" to the 766 assembler. The filter must be a standalone shell command that takes the 767 name of the input file as its first argument, and the name of the output 768 file as the second one, as in: 769 770 myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S 771 myasmfilter bar.S $OBJS_DIR/bar.S 772 773</pre></body></html> 774