Android-ndk development-android. mk File Syntax specification javaeye)

Original article: http://gyht0808.javaeye.com/blog/765730

 

Introduction:

Android. mk is used to describe your C and C ++ source code files to Android ndk. This document describes its syntax. Before reading the following content, let's assume that you have read the docs/Overview. txt file and understood their roles and purposes.

Overview:

An android. mk file is used to describe your source code to the compilation system. Specifically:

-This file is a small part of GNU makefile and will be parsed once or multiple times by the compilation system,

Parse the build system once or more times. Therefore, you

Minimize the variables you declare and do not consider that some variables will not be defined during parsing.

-The syntax of this file allows you to organize your source code into modules. A module belongs to one of the following types:

-

Static Library

-

Shared Library

　　Only the shared library will be installed/copied to your application software package. Although static databases can be used to generate shared libraries.

You can define one or more modules in each android. mk file. You can also use the same source code file in several modules.

-The compilation system handles many details for you. For example, you do not need to list header files and dependent files in your android. mk file. The ndk compilation system automatically handles these problems for you. This also means that after you upgrade the ndk, you should get the new toolchain/platform support and do not need to change your android. mk file.

Note: This syntax is very similar to the open source code of the publicly released Android platform. However, the method for implementing the compilation system is different. This is designed on purpose, it makes it easier for program developers to reuse the source code of external libraries.

Simple Example:

---------------

Before describing the syntax details, let's look at a simple "Hello World" example, for example, the following file:

Sources/helloworld. c

Sources/helloworld/Android. mk

'Helloworld. c' is a JNI shared library that provides native methods to return the "Hello World" string.

The corresponding Android. mk file will look like the following:

---------- Cut here ------------------

Local_path: = $ (call my-DIR)

Include $ (clear_vars)

Local_module

: = Helloworld

Local_src_files: = helloworld. c

Include $ (build_shared_library)

---------- Cut here ------------------

Okay. Let's explain these lines of code:

Local_path: = $ (call my-DIR)

 

An android. mk file must first define the local_path variable. It is used to search for source files in the Development tree.. In this example,The Macro function 'my-dir' is provided by the compilation system and used to return the current path (that is, the directory containing the Android. mk file ).

Include $ (clear_vars)

　　Clear_vars is provided by the compilation system, specifying the GNU makefile to clear many local_xxx variables for you.(For example, local_module, local_src_files, local_static_libraries, etc ...),

Except local_path. This is necessary because all the compilation control files are in the same GNU make execution environment, and all the variables are global.

Local_module: = helloworld

　　The local_module variable must be defined to identify each module you describe in the Android. mk file. The name must be unique and contain no spaces. Note that the compilation system automatically generates the appropriate prefix and suffix. In other words, a shared library module named 'foo' will generate the 'libfoo. so' file.

Important Notes

If you name the library 'libfoo', the compiling system will not add any lib prefix or generate libfoo. so, this is to support Android from the source code of the Android platform. MK file, if you do need to do so.

Local_src_files: = helloworld. c

　　The local_src_files variable must contain the C or C ++ source code file to be compiled and packaged into the module.. Note that you do not need to list header files and contained files here, because the compilation system will automatically find the dependent files for you; just list the source code files directly transmitted to the compiler.

Note that the default C ++ source code file extension is '. CPP '. it is also possible to specify a different extension. As long as you define the local_default_cpp_extension variable, do not forget the starting dot (that is '. cxx ', not 'cxx ').

Include $ (build_shared_library)

　　Build_shared_library is the variable provided by the compilation system., Pointing to a GNU makefile script,Collects all the information defined in the local_xxx variable since the last call of 'include $ (clear_vars) ', determines what to compile, and how to do it correctly.. And B.Uild_static_library variable generation static library.

There are more complex examples in the sources/Samples Directory. You can see the Android. mk file with annotations.

Refer:

This is a list of variables that you should depend on or define in Android. mk. You can define other variables for your own use,

However, the ndk compilation system retains the following variable names:

-Name starting with local _ (for example, local_module)

-Name starting with private _, ndk _ or app _ (used internally)

 

-Lowercase name (for internal use, for example, 'My-dir ')

If you want to define your own variables in Android. mk for convenience, we recommend that you use the my _ prefix. A small example:

---------- Cut here ------------------

My_sources: = Foo. c

Ifneq ($ (my_config_bar ),)

My_sources + = bar. c

Endif

Local_src_files + = $ (my_sources)

---------- Cut here ------------------

In this way, we have achieved our goal.

Variables provided by ndk:

-

-----------

These GNU make variables are defined by the compilation system before parsing your android. mk file.

Note that in some cases, ndk may analyze Android. mk several times, and the definitions of some variables may vary.

　　Clear_vars

Point to a compilation script. Almost all undefined local_xxx variables are listed in "module-description. You must include this script before starting a new module.

Include $ (clear_vars)

　　Build_shared_library

　　Point to the compilation script to collect all the information you provide in the local_xxx variable, and decide how to compile the source code file you listed into a shared library.. Note that you must define local_module and local_src_files at least before including the file. Example:

Include $ (build_shared_library)

Note that this will generate a file named Lib $ (local_module). So.

Build_static_library

A build_shared_library variable is used to compile a static library. The static library will not be copied to your project/packages and can be used to compile the Shared Library (see the local_static_libraries and local_static_whole_libraries described below)

Example:

　　Include $ (build_static_library)

Note that this will generate a file named Lib $ (local_module)..

Target_arch

　　Name of the target CPU PlatformAs specified in the android open source code. If it is 'arm', it indicates that the arm-compatible command is to be generated and is irrelevant to the CPU architecture revision.

　　Target_platform

When parsing Android. mk,Target Android platform nameCurrently, only 'android-1.5 'is supported '.

　Target_arch_abi

　　CPU + Abi name, only 'arm 'is supported', Which means:

Armv5te or more advanced CPU, with 'softfloat' floating point support.

Other Abi files will be described in later ndk versions. They will have different names. Note that all ARM-based Abi will define 'target _ arch 'As 'arm', but there will be different 'target _ arch_abi'

Target_abi

 

The combination of the Target Platform and Abi, which is actually defined as $ (target_platform)-$ (target_arch_abi)

It is useful when you want to test a particular target system on a real device.

By default, it will be 'android-1.5-arm'

///////////////////

Ndk-function macros

-

--------------

The following is the GNU make 'function' macro, which must be evaluated using '$ (CALL)'. They return regionalized information.

　　My-Dir

　　Returns the path of the current Android. mk directory., Relative to the top layer of the ndk compilation system. This is useful. It is defined at the beginning of the android. mk file:

Local_path: = $ (call my-DIR)

　　All-subdir-makefiles

　　Returns a list of subdirectories in the current 'my-dir' path.. For example, you can view the following directory levels:

Sources/Foo/Android. mk

Sources/Foo/lib1/Android. mk

Sources/Foo/lib2/Android. mk

If sources/Foo/Android. mk contains one line:

Include $ (call all-subdir-makefiles)

Then it automatically contains sources/Foo/lib1/Android. mk and

Sources/Foo/lib2/Android. mk

This function provides the compilation system with a deep nested code directory hierarchy. Note that by default, ndk will only search for files in sources/*/Android. mk.

　　This-makefile

　　Returns the path of the current makefile.(Where this function is called)

　　Parent-makefile

　　Returns the path of the parent makefile in the call tree.. That is, the makefile path that contains the current makefile.

　　Grand-parent-makefile

Guess...

Module description variable:

-

--------------

The following variables are used to describe your module to the compilation system. You should define it between 'include $ (clear_vars) 'and 'include $ (build_xxxxx. As described above, $ (clear_vars is a script that clears all these variables unless explicitly stated in the description.

　　Local_path

　　This variable is used to show the path of the current file.. You must define it at the beginning of Android. mk, which can be used as follows:

Local_path: = $ (call my-DIR)

　　This variable will not be cleared by $ (clear_vars)Therefore, each android. mk only needs to be defined once (when you define several modules in a file ).

Local_module

　　This is the name of your module. It must be unique and cannot contain spaces. You must define it before including any $ (build_xxxx) script. The module name determines the name of the generated file. For example, if the name of a shared library module is, the name of the generated file is Lib. So. However, in your ndk generated file (or android. mk or application. mk), you should only involve (reference) other modules with normal names.

　　Local_src_files

　　This is the list of source code files to be compiled. You only need to list the files to be passed to the compiler, because the compilation system automatically calculates dependencies for you.

Note that the source code file names are relative to local_path. You can use the path section, for example:

Local_src_files: = Foo. c

Toto/bar. c

Note: Unix-style slashes (/) must be used in the generated files. The windows-style backslash will not be correctly processed.

　　Local_cpp_extension

　　This is an optional variable used to specify the extension of the C ++ code file.The default value is '. cpp', but you can change it, for example:

Local_cpp_extension: =. cxx

　　Local_cflags

　　Optional compiler options, used when compiling C code files.

This may be useful, specifying an additional include path (relative to the top-level directory of the ndk), macro definition, or compilation options.

Important information: do not go to Android. in MK, you only need to change the optimization/debugging level in application. if you specify the appropriate information in MK, the problem will be automatically handled for you. During debugging, The ndk will automatically generate useful data files.

Local_cxxflags

Same as local_cflags for C ++ source files

Local_cppflags

Same as local_cflags, but applicable to both C and C ++ source files.

　　Local_static_libraries

　　Should be linked to the static library list of this module(Generated using build_static_library), which is only meaningful to the shared library module.

　　Local_shared_libraries

　　List of shared library modules that this module depends on during runningThe information embedded when the file is generated.

Note: This will not append the listed modules to the compilation graph, that is, you still need to add them to the modules required by the program in application. mk.

　　Local_ldlibs

　　Additional Linker Options to be used to compile your module. This is useful for passing the name of the specified database using the "-l" prefix.. For example, the following will tell the module generated by the linker to link to/system/lib/libz. So at the time of loading.

Local_ldlibs: =-LZ

Look at the docs/STABLE-APIS.TXT to get a list of open system libraries that you can link to using the ndk release.

　　Local_allow_undefined_symbols

By default, when attempting to compile a shared library, any undefined reference will cause an "undefined symbol" error. This will be of great help for capturing errors in your source code files.

However, if you do not need to start this check for some reason, set this variable to 'true '. Note that the corresponding shared library may fail to be loaded at runtime.