Lines Matching refs:to
7 written to describe your C and C++ source files to the Android
15 An `Android.mk` file is written to describe your sources to the
20 should try to minimize the variables you declare there and
23 - The file syntax is designed to allow you to group your
30 Only shared libraries will be installed/copied to your
31 application package. Static libraries can be used to generate
38 don't need to list header files or explicit dependencies between
42 This also means that, when updating to newer releases of the NDK,
43 you should be able to benefit from new toolchain/platform support
44 without having to touch your `Android.mk` files.
46 Note that the syntax is *very* close to the one used in `Android.mk` files
49 an intentional design decision made to allow reuse of 'external' libraries'
69 implements a native method that returns a string to the
73 to the NDK build system. Its content is:
94 It is used to locate source files in the development tree. In this example,
95 the macro function 'my-dir', provided by the build system, is used to return
101 The CLEAR_VARS variable is provided by the build system and points to a
110 The LOCAL_MODULE variable must be defined to identify each module you
113 prefix and suffix to the corresponding generated file. In other words,
119 This is to support `Android.mk` files that originate from the
120 Android platform sources, would you need to use these.
128 that will be passed directly to a compiler, and you should be good.
131 however possible to specify a different one by defining the variable
138 points to a GNU Makefile script that is in charge of collecting all the
140 'include $(CLEAR_VARS)' and determine what to build, and how to do it
141 exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.
157 If you need to define your own convenience variables in an `Android.mk`
182 > Points to a build script that undefines nearly all LOCAL_XXX variables
190 > Points to a build script that collects all the information about the
191 > module you provided in LOCAL_XXX variables and determines how to build
202 > A variant of BUILD_SHARED_LIBRARY that is used to build a target static
204 > project/packages but can be used to build shared libraries (see
214 > Points to a build script used to specify a prebuilt shared library.
216 > of LOCAL_SRC_FILES must be a single path to a prebuilt shared
237 > For example, 'android-3' correspond to Android 1.5 system images. For
261 > NOTE: Up to Android NDK 1.6_r1, this variable was simply defined
262 > as '`arm`'. However, the value has been redefined to better
270 > have 'TARGET_ARCH' defined to '`arm`', but may have different
277 > to test against a specific target system image for a real device.
281 > (Up to Android NDK 1.6_r1, this used to be '`android-3-arm`' by default)
292 > the current `Android.mk`'s directory. This is useful to define
297 > IMPORTANT NOTE: Due to the way GNU Make works, this really returns
313 > The problem here is that the second call to `my-dir` will define
314 > LOCAL_PATH to `$PATH/foo` instead of `$PATH`, due to the include that
317 > For this reason, it's better to put additional includes after
364 > This function can be used to provide deep-nested source directory
365 > hierarchies to the build system. Note that by default, the NDK
384 > A function that allows you to find and include the `Android.mk`
400 The following variables are used to describe your module to the build
408 > This variable is used to give the path of the current file.
426 > you should only refer to other modules with their 'normal'
434 > This variable is optional, and allows you to redefine the name of
451 > Only list the files that will be passed to a compiler, since the
454 > Note that source files names are relative to LOCAL_PATH and
469 > `Android.mk` easy to reuse on a different machine / system.
476 > This is an optional variable that can be defined to indicate
488 > This is an optional variable that can be defined to indicate
502 > The effect of this variable is to enable the right compiler/linker
504 > this also helps declare which features the binary relies on to ensure
507 > It is recommended to use this variable instead of enabling `-frtti` and
512 > An optional list of paths, relative to the NDK *root* directory,
513 > which will be appended to the include search path when compiling
534 > This can be useful to specify additional macro definitions or
537 > **IMPORTANT**: Try not to change the optimization/debugging level in
544 > to C source files, not C++ ones. This has been corrected to
546 > LOCAL_CPPFLAGS to specify flags for C++ sources only now).
548 > It is possible to specify additional include paths with
549 > LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES
565 > NOTE: In android-ndk-1.5_r1, the corresponding flags applied to
566 > both C and C++ sources. This has been corrected to match the
567 > full Android build system. (You can use LOCAL_CFLAGS to specify
576 > force these libraries to be linked into the resulting binary.
585 > This is necessary at link time and to embed the corresponding information
591 > A variant of LOCAL_STATIC_LIBRARIES used to express that the corresponding
592 > library module should be used as "whole archives" to the linker. See the
596 > several static libraries. Note that when used to build a shared library,
597 > this will force all object files from your whole static libraries to be
598 > added to the final binary. This is not true when generating executables
603 > The list of additional linker flags to be used when building your
604 > shared library or executable. This is useful to pass the name of
606 > following will tell the linker to generate a module that links to
619 > The list of other linker flags to be used when building your shared
630 > By default, any undefined reference encountered when trying to build
632 > great help to catch bugs in your source code.
634 > However, if for some reason you need to disable this check, set this
635 > variable to '`true`'. Note that the corresponding shared library may fail
636 > to load at runtime.
644 > each instruction are 16-bit wide. You can define this variable to '`arm`'
645 > if you want to force the generation of the module's object files in
650 > Note that you can also instruct the build system to only build specific
651 > sources in ARM mode by appending an '`.arm`' suffix to its source file
656 > Tells the build system to always compile '`bar.c`' in ARM mode, and to
657 > build `foo.c` according to the value of LOCAL_ARM_MODE.
659 > NOTE: Setting APP_OPTIM to '`debug`' in your `Application.mk` will also force
660 > the generation of ARM binaries as well. This is due to bugs in the
665 > Defining this variable to '`true`' allows the use of ARM Advanced SIMD
670 > corresponds to the ARMv7 instruction set. Note that not all ARMv7
672 > should perform runtime detection to be able to use this code at runtime
693 > need to by setting this variable to 'true'.
708 > and GOT protection. This instructs the runtime linker to mark
711 > to perform.
714 > need to by setting this variable to '`true`'.
732 > need to by setting this variable to '`true`'.
736 > Define this variable to record a set of C/C++ compiler flags that will
737 > be added to the LOCAL_CFLAGS definition of any other module that uses
757 > Then, the flags '`-DFOO=1` `-DBAR=2`' will be passed to the compiler when
760 > Exported flags are prepended to your module's LOCAL_CFLAGS so you can
766 > exports them. In the above example, `-DFOO=1` would not be passed to the
776 > This can be useful if 'bar.c' wants to include headers
787 > imported linker flags will be appended to your module's LOCAL_LDLIBS
788 > though, due to the way Unix linkers work.
792 > used to export the dependency. For example:
807 > command to indicate that it depends on the system logging library,
812 > Set this variable to '`true`' when your module has a very high number of
814 > build system to use an intermediate list file, and use it with the
824 > Note that any other value than '`true`' will revert to the default
826 > Application.mk to force this behaviour for all modules in your
834 > Set this variable to '`true`' when building static libraries. This will
836 > doesn't contain object files, but simply file paths to the actual
839 > This is useful to reduce the size of your build output. The drawback
840 > is that such libraries _cannot_ be moved to a different location
851 > Define this variable to a shell command that will be used to filter
861 > to generate _another_ temporary assembly file.
873 > Were "1" corresponds to the compiler, "2" to the filter, and "3" to the