"Go" android.mk file Syntax specification (android.mk files)

Original URL: http://blog.csdn.net/smfwuxiao/article/details/8530742

1. android.mk File Overview

The Android.mk file is used to tell the NDK how to compile the system and how the source code should be compiled. To be more precise, the document is actually a small makefile. The file will be parsed many times by the NDK's compilation tool, so be careful not to use environment variables too much, lest the variables generated at the first parse affect the subsequent parsing. Android.mk to organize the source code into different modules, each module can be a static library can also be a dynamic library. The dynamic library is copied to the installation package, and the static library can only be used for compiling the dynamic library.

The same android.mk file can define multiple modules, and different modules can share the same source file.

Note that the syntax of the android.mk file used by the NDK is very close to the ANDROID.MK syntax in the open source of the Android operating system, but the two compilation systems use different methods for ANDROID.MK, which is intended to facilitate reuse of the previous code by the application developer.

2. A simple example

Before we discuss the syntax of the android.mk file in detail, let's look at a simple "Hello JNI" example where the file is located in Apps/hello-jni/project. The SRC subdirectory holds the Java source code for Android projects, and the JNI subdirectory holds the C + + source file, which is jni/hello-jni.c (implements a function that returns a string to the virtual machine). The Jni/android.mk file is the compilation script for this module, which reads as follows:

[Plain]View Plaincopy

1. Local_path: = $ (call My-dir)
3. Include $ (clear_vars)
5. Local_module: = Hello-jni
6. Local_src_files: = Hello-jni.c
8. Include $ (build_shared_library)

The above explanations are as follows:

Local_path: = $ (call My-dir)

Each android.mk file must define the Local_path variable at the beginning. This variable is used to find the C + + source file. In this example, My-dir is a macro function provided by the compiled system that returns the path to the directory where the ANDROID.MK resides.

Include $ (clear_vars)

Clear_vars is a predefined variant of the compilation system that points to a special makefile that makefile is responsible for clearing local_xxx variables (for example Local_module, Local_src_files, Local_ Static_libraries, etc.) but will not clear the Local_path. These variables need to be cleaned up because all compilation control files are completed during a trip to make, and all variables are global and affect other android.mk files.

Local_module: = Hello-jni

Local_module is used to define a name for each module, the names of different modules cannot be the same, no spaces. The name will be passed to the NDK compilation system, then the LIB prefix and the. So suffix (for example, into libhello-jni.so). Note that if you add the Lib prefix yourself in the local_module definition, the NDK does not add the LIB prefix when processing it (for compatibility with some of the source code of the Android system).

Local_src_files: = Hello-jni.c

In the Local_src_files variable to enumerate the corresponding to the same module, to compile those files, here do not add the head file, the compilation system can automatically detect the header file dependencies. By default, the C + + source file extension should be CPP, if you want to modify it, change the variable local_cpp_extension to the extension you want, note the period. For example: local_cpp_extension: =. cxx

Include $ (build_shared_library)

This build_shared_library is also a predefined variable, and it also points to a makefile that collects the information you define in variables such as local_xxx, determines which files to compile, and how to compile them. If you are compiling a static library instead of a dynamic library, you can use Build_static_library.

There is a richer example in the Samples directory of the NDK installation directory, with detailed comments in it.

3. Limitation of variable name

The following variables are available for you to use directly or should be defined by you. You can also define your own variables, but you cannot use the variable names reserved by the following ndk:

Name beginning with Local_ (for example, Local_module)

Name starting with Private_, NDK_,APP_ (for NDK internal use)

The variable name of the lowercase letter is also not available (for NDK internal use, e.g. My-dir)

For example, you can use a variable name that starts with My_:

[Plain]View Plaincopy

1. My_sources: = foo.c
2. Ifneq ($ (my_config_bar),)
3. My_sources + = Bar.c
4. endif
6. Local_src_files + = $ (my_sources)

4. NDK pre-defined variables

The following variables are the NDK's pre-defined variables. Sometimes the NDK parses the same android.mk file multiple times, and the values of these variables may be different for each parsing.

Clear_vars

Point to a special makefile, responsible for cleaning up the local_xxx variable (except Local_path). This variable is typically used before a new module is defined, using:

Include $ (clear_vars)

Build_shared_library

The variable actually points to a makefile that collects the information from all the variables named local_xxx and then determines how the source code you provide is compiled into the target module. Usage: include $ (build_shared_library) Default file name: lib<local_module>.so

Build_static_library

Similar to Build_shared_library, but it is used to compile static libraries. A static library is not copied to your installation package, it is often used to compile other dynamic libraries. Usage: include $ (build_static_library) Default file name: LIB<LOCAL_MODULE>.A

Prebuilt_shared_library

This variable points to a compiled shared library. Unlike Build_shared_library and Build_static_library, when the corresponding local_src_files no longer specifies the source file, it points to the precompiled shared library file (for example, foo/libfoo.so). This precompiled module can be referenced in other modules by using the Local_prebuilts variable. Refer to prebuilt.

Prebuilt_static_library

Same as prebuilt_shared_library, except this is a static library. Refer to prebuilt.

Target_arch

The name of the target CPU architecture, consistent with the CPU schema name of the Android operating system. If you want to be compatible with all arm CPUs, you can use the name "arm".

Target_platform

The name of the target Android platform. For example, android-3 corresponds to an Android 1.5 system image (cupcake). The names of all system images and the corresponding system images can refer to the stable APIs.

Target_arch_abi

The name of the target CPU and ABI combination, currently only 2 values can be used:

Armeabi for ARMv5TE

armeabi-v7a

Note that all the time to the Android NDK 1.6_r1, here the value is "arm". However, this value has been redefined to better match the internal use of the Android platform.

For schema and Abi and compatibility issues, refer to document CPU Arch ABIs.

The other target ABI will be added in the future NDK version, and is a different name. Note that all arm-compatible ABI Target_arch are arm, but Target_arch_abi is different.

Target_abi

The combination of the target platform and the ABI, defined as $ (target_platform)-$ (Target_arch_abi). Useful when you want to test a system image on a real machine. The default value for this variable is Android-3-armeabi.

Until Android NDK 1.6_R1, this value has been android-3-arm.

5. NDK pre-defined macro functions

The following is the NDK predefined "function" macro, using $ (call <function>), which returns text information

My-dir

Returns the path to the last contained makefile, typically the path where the Android.mk file resides. This function is particularly useful for defining local_path, for example:

Local_path: = $ (call My-dir)

Note: Because of how make works, the function returns exactly the path of the previous contained makefile (that is, the returned result may not be the directory where the Android.mk is located). So, once you've included another file, don't use My-dir anymore.

For example, the following example:

[Plain]View Plaincopy

1. Local_path: = $ (call My-dir)
2. Other declarations of the module
4. Include $ (local_path)/foo/android.mk
5. Local_path: = $ (call My-dir)
6. Declaration of another module

The problem is that when you call My-dir the second time, you get $PATH/foo instead of $PATH because it has an include statement in front of it.

Therefore, it is best to define LOCAL_PATH before all include statements:

[Plain]View Plaincopy

1. Local_path: = $ (call My-dir)
2. ... declare one module
3. Local_path: = $ (call My-dir)
4. ... declare another module
5. # Extra includes at the end of the ANDROID.MK
6. Include $ (local_path)/foo/android.mk

If you find this inconvenient, you can save the result of the first call to a variable, for example:

[Plain]View Plaincopy

1. My_local_path: = $ (call My-dir)
2. Local_path: = $ (My_local_path)
3. ... declare one module
4. Include $ (local_path)/foo/android.mk
5. Local_path: = $ (My_local_path)
6. ... declare another module

All-subdir-makefiles

Returns a list of the android.mk files for all subdirectories under the current My-dir directory. For example, the file organization is as follows:

        Sources/foo/android.mk        sources/foo/lib1/android.mk        sources/foo/lib2/android.mk

If SOURCES/FOO/ANDROID.MK contains the following line:

        Include $ (call All-subdir-makefiles)

Then, the file will automatically include Sources/foo/lib1/android.mk and sources/foo/lib2/android.mk. This function can be used when the source code is organized into many levels, and by default the NDK will only look for sources/*/android.mk.

This-makefile

Returns the path of the current makefile (that is, where the function was called)

Parent-makefile

If the current makefile is contained by another makefile, it returns the path that contains its own makefile (that is, parent)

Grand-parent-makefile

(Guess ...)

Import-module

This function is used to find the Android.mk file of another module by module name and is included in it. Use the following:

$ (call import-module,<name>)

The above will look for a module named <name> in the list of directories specified by the Ndk_module_path variable, which will be included when found.

You can refer to the Import Module.

6. Module Description Variable

These variables are used to describe the modules, which should be defined between include $ (clear_vars) and include $ (build_xxxx).

Local_path (required)

This variable represents the path where the current file (typically Android.mk) is located, which is important and must be defined (defined at the beginning of the Android.mk file). The common wording is as follows:

Local_path: = $ (call My-dir)

The variable is not emptied by the include $ (clear_vars), so no matter android.mk defines several modules, a android.mk only needs to be defined at the beginning.

Local_module (required)

The variable defines the name of the current module and must have a unique name and no spaces. This variable must be defined before the include $ (build_xxx). By default, this name is used to get the name of the output file. For example, if the module name is foo, the resulting output file is libfoo.so. However, if you want to refer to this module in the Android.mk file or application.mk of other modules, you should use the module name Foo instead of the libfoo.so file name.

Local_module_filename (optional)

This variable can be used to redefine the name of the output file. By default, the Foo module gets the static library name LIBFOO.A, and the dynamic library name is libfoo.so (Unix specification). When Local_module_filename is defined, the output file name is the name specified by the variable, for example:

[Plain]View Plaincopy

1. Local_module: = foo-version-1
2. Local_module_filename: = Libfoo

Note: Local_module_filename does not support file paths (so there is no slash), do not write extensions (file paths and file extensions are automatically added by the compilation tool)

Local_src_files (required)

This variable is used to specify the source file for the module, only the source filename that needs to be passed to the compiler is added to the local_src_files, and the compiler automatically handles the header file dependency. The filenames here are in Local_path as the current directory (that is, relative to the Local_path directory), for example:

Local_src_files: = foo.c toto/bar.c
Note: You must use a Unix-style slash, and the Windows-style slash is not handled correctly.

Local_cpp_extension (optional)

The extension used to define the C + + code file. Must start with a period (that is, "." ), the default value is ". cpp", which can be modified, for example:

Local_cpp_extension: =. cxx

Starting with this version of NDK R7, this variable can support multiple extensions, such as:

Local_cpp_extension: =. cxx. CPP. cc

Local_cpp_features (optional)

This variable is used to specify the special C + + characteristics that C + + code relies on. For example, if you want to tell the compiler that your C + + code uses RTTI (RunTime Type information):

Local_cpp_features: = Rtti

If you want to specify that your C + + code uses a C + + exception, then:

Local_cpp_features: = Exceptions

The variable can specify multiple attributes at the same time. Example: local_cpp_features: = Rtti FEATURES

The function of this variable is to open the corresponding compiler/linker flag when compiling the module. For precompiled files, this variable indicates that the precompiled library relies on these features to ensure that the last link works correctly. The equivalent of this variable is to write the-frtti-fexceptions and other flag options in Local_cppflags. However, it is recommended to use this method.

Local_c_includes

A list of paths that are the relative paths to the ndk root directory (files in local_src_files are relative to Local_path). These paths are appended to the list of search paths to the header when compiling C + + and assembly files. For example:

Local_c_includes: = Sources/foo

Or, Local_c_includes: = $ (Local_path)/. /foo

The search path here is placed in front of the flags such as Local_cflags/local_cppfalgs. When using NDK-GDB, the paths in the Local_c_includes are also used.

Local_cflags

Specifies the flags that are passed to the compiler when compiling the C + + source code. It is typically used to specify additional compilation options and macro definitions.

Note: Try not to modify the optimization/debug level in ANDROID.MK because the compilation system automatically handles these issues after the information is defined in APPLICATION.MK.

Local_cxxflags (abolished, local_cppflags alias) local_cppflags (optional)

The option to pass to the compiler when compiling C + + code (compiling C code will not use the options here). In the last command-line option, the option specified here is followed by the option specified in Local_cflags.

Local_static_libraries

Specifies a static library that should be linked to the current module (multiple can be specified). This option makes sense when the current module is a dynamic library.

Local_shared_libraries

Specifies that a shared library is dependent on the module at run time (multiple can be specified). This information is required for the link phase.

Local_whole_static_libraries

It is a variant of local_static_libraries to indicate that its corresponding module should be a "whole archive" for linker (see GNU Linker documentation, information on--whole-archive). This option is used when there is a cyclic dependency between the static libraries. Note that this option forces all object files to be assembled when the dynamic library is compiled, but this is not the case when compiling the executable file.

Local_ldlibs

Used to specify the remaining connector flags when the module compiles. For example:

Local_ldlibs: =-lz

Tells the linker to link/system/lib/libz.so to this shared library when it loads the shared library.

If you want to know which shared libraries on your Android system can be linked, refer to Stable APIs.

Local_allow_undefined_symbols

By default, when a shared library is compiled, a "undefined symbol" error is reported when an undefined symbol reference is encountered. This helps to fix bugs that exist in your code.

If for some reason the detection must be disabled, you can set this variable to true. Note that the compiled shared library may cause the program to exit when it is loaded with an error.

Local_arm_mode

Local_arm_neon

Local_disable_no_execute

Android NDK R4 adds support for the "NX bit" security feature. It's turned on by default, and if you're sure you don't need the feature, you can turn it off, that is:

Local_disable_no_execute: = True

This variable does not modify the ABI and is only enabled on the kernel of CPUs above ARMv6. Turning on this feature compiles code that does not need to be modified to run on older CPUs (that is, all arm CPUs can run).

Reference information:

Http://en.wikipedia.org/wiki/NX_bit
Http://www.gentoo.org/proj/en/hardened/gnu-stack.xml

Local_export_cflags

This variable defines a number of C + + compiler flags. These flags are appended to the LOCAL_CFLAGS definition of the module using the module (using Local_static_libraries and local_shared_libraries).

If the Foo module is declared as follows:

[Plain]View Plaincopy

1. Include $ (clear_vars)
2. Local_module: = Foo
3. Local_src_files: = foo/foo.c
4. Local_export_cflags: =-dfoo=1
5. Include $ (build_static_library)

The bar module relies on the Foo module, declared as follows:

[Plain]View Plaincopy

1. Include $ (clear_vars)
2. Local_module: = Bar
3. Local_src_files: = bar.c
4. Local_cflags: =-dbar=2
5. Local_static_libraries: = Foo
6. Include $ (build_shared_library)

Therefore, when compiling the bar module, its compiler flag is "-dfoo=1-dbar=2". The exported flags plus the local_cflags of this module become the last flags to be passed to the compiler. It's easy to change it. This dependency is transitive, for example, if the zoo relies on Bar,bar for Foo, then the zoo will have both bar and Foo export flags.

Note that the flags that it exports are not used when compiling the module itself. For example, when compiling the Foo module above,-dfoo=1 is not passed to the compiler.

Local_export_cppflags

The same as Local_export_cflags, is a C + + related flag.

Local_export_c_includes

Same as Local_export_cflags, but only for header file search paths. Useful when you have multiple modules in a shared library and have a header file dependency on each other. See Import Module for usage.

Local_export_ldlibs

Same as Local_export_cflags, but only for the flag of the connector. Note that the linker flags here are appended to the local_ldlibs of the module.

This variable is useful, for example, when the Foo module is a static library and the code relies on the system library. Local_export_ldlibs can be used to export the dependency:

[Plain]View Plaincopy

1. Include $ (clear_vars)
2. Local_module: = Foo
3. Local_src_files: = foo/foo.c
4. Local_export_ldlibs: =-llog
5. Include $ (build_static_library)
7. Include $ (clear_vars)
8. Local_module: = Bar
9. Local_src_files: = bar.c
10. Local_static_libraries: = Foo
11. Include $ (build_shared_library)

Here when the bar module is compiled, its linker flag is added with a-llog, indicating that it relies on the system-provided liblog.so because it relies on the Foo module.

local_filter_asm

This variable specifies a shell command to filter the assembly files that are listed in the Local_src_files or compiled by local_src_files files listed. After the variable is defined, the following behavior is caused:

1) all the C + + source code is first translated into a temporary assembly file (if you do not define LOCAL_FILTER_ASM, C + + source code directly compiled to obj file)

2) These assembly files are passed to the shell command specified by local_filter_asm, and a batch of new assembly files are obtained.

3) These new assembly files are then compiled into the obj file.

In other words, if you define:

[Plain]View Plaincopy

1. Local_src_files: = foo.c bar. S
2. Local_filter_asm: = Myasmfilter

The FOO.C is first passed to the compiler (GCC) to get foo. S.orignal, and then this foo. S.original is passed to your specified filter (local_asm_filter) to get foo. S, and then passed to the assembler (for example, as) to get foo.o. Bar. The S is passed directly to the filter to get bar. S.new, and then pass it on to the assembler and get BAR.O. That is, from the *. The process of compiling s to *.o adds a filtering link.

The filter must be a stand-alone shell command, the input file as its first command-line argument, and the output file as the second command-line argument, for example:

[Plain]View Plaincopy

1. Myasmfilter $OBJS _dir/foo. S.original $OBJS _dir/foo. S
2. Myasmfilter Bar. S $OBJS _dir/bar. S

"Go" android.mk file Syntax specification (android.mk files)