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 &lt;function&gt;)'. 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,&lt;name&gt;)
360
361    And this will look for the module tagged &lt;name&gt; 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&lt;foo&gt;.so for a shared library module named &lt;foo&gt;. However
394    you should only refer to other modules with their 'normal'
395    name (e.g. &lt;foo&gt;) 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 &lt;foo&gt; will always generate a
403    static library named lib&lt;foo&gt;.a or a shared library named lib&lt;foo&gt;.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&lt;path&gt;, 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_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
655LOCAL_EXPORT_CPPFLAGS
656    Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.
657
658LOCAL_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
663LOCAL_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
688LOCAL_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
709LOCAL_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--&gt; $OBJS_DIR/foo.S.original --2--&gt; $OBJS_DIR/foo.S --3--&gt; $OBJS_DIR/foo.o
730    bar.S                                 --2--&gt; $OBJS_DIR/bar.S --3--&gt; $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