Android.mk 变量_local_generated_sources

Android.mk 变量

 

(1)LOCAL_------这些变量在每个模块中都被设置。他们被命令include $(CLEAR_VARS)清理，所以你可以在包含include $(CLEAR_VARS)命令后，相信他们是空的。在你会使用的大多数的模块中的大多数变量都是LOCAL_变量。

(2)PRIVATE_------这些变量是编译指定目标的变量。那意味着他们只在特定模块的命令当中是有用的。这也意味着他们不太可能在你所包含的模块结束后发生改变。这个链接与编译的文档(http://www.gnu.org/software/make/manual/make.html#Target_002dspecific)描述了更多的指定目标的变量。请记住有些源码树中的私有变量没有以PRIVATE_作为前缀。这是安全的，并且他们会在他们被发现的时候被修复。对于造成的疑惑道歉。

(3)INTERNAL_------这些变量是对编译系统的功能至关重要的，所以你不应该创建以这个作为前缀的变量，并且你也许也并不应该在你的makefile文件中弄乱这些变量。

(4)HOST_和TARGET_------这些变量包含了明确指向主机以及目标的目录以及定义。不要在你的makefile文件当中设置以HOST_或者TARGET开始的变量。

(5)BUILD_和CLEAR_VARS------这些变量包含了需要包含的定义好的模板makefile文件。一些例子是CLEAR_VARS和BUILD_HOST_PACKAGE。

(6)任何在你的Android.mk文件当中的其他名称的使用都是公平的。然而，记住这是一个不可回归的编译系统，所以你的变量可能会被另一个更晚包含的Android.mk文件修改，并且在你的规则或者模块的命令执行时变得不一样。

 

LOCAL_ASSET_FILES：

在Android.mk文件当中include $(BUILD_PACKAGE)将下面的句子设置到了你想要设置到的你的app的文件集合当中，通常是：

LOCAL_ASSET_FILES += $(call find-subdir-assets)

当我们选择ant作为app的编译系统时，这个可能会改变。

 

LOCAL_CC：

如果你想要在模块当中使用一个不同的C编译器，设置LOCAL_CC为编译器的路径。如果LOCAL_CC是空白的，适合的默认编译器将被使用。

 

LOCAL_CXX：

如果你想要在模块中使用一个不一样的C++编译器，把LOCAL_CXX设置为编译器的路径。如果LOCAL_CXX是空白的，适合的默认编译器将被使用。

 

LOCAL_CFLAGS:

如果你有额外的标签来传递到C/C++编译器，把他们加到这里。比如说：

LOCAL_CFLAGS += -DLIBUTILS_NATIVE=1

 

LOCAL_CPPFLAGS：

如果你有只传递给C++编译器的额外标签，把他们加到这。比如说：

LOCAL_CPPFLAGS += -ffriend-injection

LOCAL_CPPFLAGS 被保证会放在LOCAL_CFLAGS的编译行之后，所以你可以使用它来覆盖LOCAL_CFLAGS列表中的标签。

 

LOCAL_CPP_EXTENSION：

如果你的C++文件以非”.cpp”来结尾，你可以在这里指明自定义扩展名;现在混合不同的扩展名是不可能的。

 

LOCAL_NO_DEFAULT_COMPILER_FLAGS：

通常的，这条编译命令在C/C++文件中包含了全局包含路径和全局CFLAGS。如果LOCAL_NO_DEFAULT_COMPILER_FLAGS非空，当前模块模块的C/C++文件的编译时没有默认的包含或者标签会被使用。LOCAL_C_INCLUDES,LOCAL_CFLAGS,和LOCAL_CPPFLAGS依然会载这个模块中被使用，同时任何在模块中被定义的DEBUG_CFLAGS也都会被使用。

 

LOCAL_COPY_HEADERS：

即将被移除

需要被复制到安装的包含树的文件集合。你同时也必须要支持LOCAL_COPY_HEADERS_TO。

此变量将被移除的原因是复制头文件使得错误信息变得混乱，并且可能会导致人们编辑那些不正确的头文件。这也会导致系统中更容易出现错误的层级，这是我们想要避免的。我们也没有在制作一个C/C++ SDK,所以这里没有一个复制任何头文件的根本需求。

 

LOCAL_COPY_HEADERS_TO

即将被移除

一个把LOCAL_COPY_HEADER中列举的头文件所复制到的目录。

此变量将被移除的原因是复制头文件使得错误信息变得混乱，并且可能会导致人们编辑那些不正确的头文件。这也会导致系统中更容易出现错误的层级，这是我们想要避免的。我们也没有在制作一个C/C++ SDK,所以这里没有一个复制任何头文件的根本需求。

 

LOCAL_C_INCLUDES：

额外的目录来通知C/C++编译器在其中寻找头文件。这些路径起始于源代码树的根目录。如果你想要把你自己的子目录加入到包含路径当中，使用LOCAL_PATH变量。比如说：

LOCAL_C_INCLUDES += extlibs/zlib-1.2.3

LOCAL_C_INCLUDES += $(LOCAL_PATH)/src

但是你不应该把包含的子目录再加入到LOCAL_C_INCLUDES当中，同时你应该把那些文件引用到他们的子目录中的#include状态当中。比如说：

#include <utils/KeyedVector.h>

而不是 #include <KeyedVector.h>

有一些组件在处理这个变量时是错误的，并且应当被清除。

 

LOCAL_REQUIRED_MODULES:

用任何以空白分开的模块名设置LOCAL_REQUIRED_MODULES，比如”libblah”或者”Email”。如果这个模块被安装了，所有它需求的模块都会被安装。这个变量可以被用来确认当一个给予的app安装时必要的共享库或者提供者被安装了。

 

LOCAL_FORCE_STATIC_EXECUTABLE:

如果你的可执行文件需要被静态链接，设置LOCAL_FORCE_STATOC_EXECUTABLE:=true。有一个我们采用静态模式执行的非常小的库的列表（现在只有libc）。这个变量只被用于根目录下的/sbin的可执行文件。

 

LOCAL_GENERATED_SOURCES：

被添加到LOCAL_GENERATED_SOURCES当中的文件会在你的模块被编译的时候自动的生成并链接。阅读自定义工具（build-system.html#custom-tools）模块中的makefile文件来获取一个例子。

 

LOCAL_JAVACFLAGS：

如果你有要传递给javac编译器的额外的标签，把他们加到这里。比如说：

LOCAL_JAVACFLAGS += -Xlint:deprecation

 

LOCAL_JAVA_LIBRARIES：

当链接Java apps和库的时候，LOCAL_JAVA_LIBRARIES明确了需要包含的java类集合。现在这些集合有两个：core和framework。在大多数的场合，它会看起来像接下来的东西：

LOCAL_JAVA_LIBRARIES := core framework

记住在通过”include $(BUILD_PACKAGE)”编译一个APK时设置LOCAL_JAVA_LIBRARIES是不必要的（同时也是不允许的）。适合的库会被自动的包含。

 

LOCAL_LDFLAGS：

你可以通过设置LOCAL_LDFLAGS来把额外的标签传递给连接器。记住参数的顺序对于ld是十分重要的，所以不管你做了什么，在所有的平台上进行测试。

 

LOCAL_LDLIBS：

LOCAL_LDLIBS允许你指明不属于你的可执行文件或者库的编译部分的额外的库。用-lxxx的形式来指明你想要的库；他们会被直接传递到链接的命令行。然而，记住不会有任何的依赖产生到这些库上面。当你想要使用一个在主机上预先安装的库来编译一个仿真机的时候，这个变量将会非常有用。连接器是一个非常挑剔的老顽固，所以有时候传递一些其他的标签到这里会变得非常重要，如果你在做一些鬼鬼祟祟的小动作的话。比如说：

LOCAL_LDLIBS += -lcurses -lpthread

LOCAL_LDLIBS += -Wl, -z, origin

 

LOCAL_NO_MANIFEST：

如果你的包不包含一个manifest(AndroidManigest.xml)，那么设置LOCAL_NO_MANIFEST := true。普通的资源包这么做了。

 

LOCAL_PACKAGE_NAME：

LOCAL_PACKAGE_NAME是app的名字。比如说，Dialer，Contacts，等等。它可能

会改变或者消失，当我们切换到一个基于ant的app编译系统时。

 

LOCAL_PATH：

你的Android.mk文件所在的目录。你可以通过把接下来的内容放到你的Android.mk文件的第一行来设置它：

LOCAL_PATH := $(my-dir)

my-dir大量地使用了MAKEFILE_LIST(http://www.gnu.org/software/make/manual/make.html#MAKEFILE_005fLIST-Variable)文件中的变量，所以在你包含任何其他的makefile文件前调用它。同时，

考虑到你包含的任何子目录都可能重置LOCAL_PATH，所以在包含他们之前设置好这些内容。这同样也意味着如果你想要写入几行include来引用LOCAL_PATH，它不会生效，因为那些引用到的makefile文件可能会重置LOCAL_PATH。

 

LOCAL_POST_PROCESS_COMMAND：

对于可执行的主机文件，你可以指定一个命令行使得一个模块被链接后直接运行。你可能不得不经过一些曲折的道路来使得变量名正确，由于一些或早或晚的变量诊断：

module := $(HOST_OUT_EXECUTABLES)/$(LOCAL_MODULE)

LOCAL_POST_PROCESS_COMMAND := /Developer/Tools/Rez -d __DARWIN__ -t APPL\

       -d __WXMAC__ -o $(module) Carbon.r

LOCAL_PREBUILT_EXECUTABLES：

当包含$(BUILD_PREBUILT)或者$(BUILD_HOST_PREBUILT)的时候，把这些设置到你想要复制的可执行文件里。他们会自动的置入到正确的bin目录下。

 

LOCAL_PREBUILT_LIBS：

当包含$(BUILD_PREBUILT)或者$(BUILD_HOST_PREBUILT)的时候，把这些库设置到你想要复制的可执行文件里。他们会自动的置入到正确的bin目录下。

 

LOCAL_SHARED_LIBRAIES：

这些是你将要直接链接的库。你不需要过渡性的传递包含的库。不加后缀的指明这些文件：

LOCAL_SHARED_LIBRARIES := \

     libutils \

    libui \

     libaudio \

     libexpat \

     libsgl

 

LOCAL_SRC_FILES：

编译系统通过查看LOCAL_SRC_FILES来知道哪些源文件需要被编译-----.cpp/.c/.y/.l/.java。对于lex和yacc文件，他知道如何正确的自动进行.h/和.c/.cpp文件的中转。如果文件是在一个包含了Android.mk的子目录当中，在他们前面加上目录的名称：

LOCAL_SRC_FILES := \

     file1.cpp \

      dir/file2.cpp

 

LOCAL_STATIC_LIBRARIES：

这些是你想要加入到你的模块当中的静态库。总的来说，我们使用共享库，但是有些地方，比如bin目录下的可执行文件以及主机可执行文件，我们使用了静态库来替代。

LOCAL_STATIC_LIBRARIES := \

     libutils \

      libtinyxml

 

LOCAL_MODULE： 

LOCAL_MODULE是被期望于产生在你的Android.mk当中(编译后生成)的名字。比如说，对于libkjs，LOCAL_MODULE是”libkjs”(编译系统添加了合适的后缀------.so/.dylib/.dll)。对于app模块，使用LOCAL_PACKAGE_NAME而不是LOCAL_MODULE。我们正在计划切换到ant来编译app，所以这个还是值得讨论的。

 

LOCAL_MODULE_PATH：

通知编译系统来将模块放置到对于它的类型不是通常要放到的地方。如果你覆写了这个变量，确定你也设置了LOCAL_UNSTRIPPED_PATH，因为如果它不是一个可执行文件或者共享库，至少这个未拆开的二进制有地方来进行存放。如果你忘记了设置LOCAL_UNSTRIPPED_PATH，一个错误会被报出来。

阅读本文的把模块放到其他地方来获取更多信息。

 

LOCAL_MODULE_RELATIVE_PATH：

通知编译系统来将一个模块放置到它的类型通常需要放到的目录的子目录下。如果你设置了这个，你就可以不需要设置LOCAL_UNSTRIPPED_PATH，未拆分的二进制文件也会使用关联的路径。

阅读本文的把模块放到其他地方来获取更多信息。

 

LOCAL_UNSTRIPPED_PATH：

通知编译系统来把未明确版本的模块来放到对于它的版本不通常放到的地方。通常的，你覆写了这个是因为你为了一个可执行文件或者共享库修改了LOCAL_MODULE_PATH变量。如果你覆写了LOCAL_MODULE_PATH变量，但是没有覆写LOCAL_UNSTRIPPED变量，一个错误将会发生。

阅读本文的把模块放到其他地方来获取更多信息。

 

LOCAL_WHOLE_STATIC_LIBRARIES：

这些是一些你想要在不允许连接器删除掉过时的代码的情况下包含到你的模块中的静态库。它最有用的地方是当你想要把一个静态库加入到共享库而且使得这个静态库的内容暴露给共享库时。

LOCAL_WHOLE_STATIC_LIBRARIES := \

Libsqlite3_android

 

LOCAL_YACCFLAGS：

任何传递给你的模块的yacc调用。这里一个已知的限制是你的模块中的所有YACC的调用都是相同的。这个可以被修复。如果你曾经希望它变成这样，只需要问我们。

LOCAL_YACCFLAGS := -o kjsyy

 

实现细节：

 

除非你正在添加一个新的平台、工具或者添加新的特性到编译系统，你永远也不应该接触到配置目录中的任何内容。总的来说，在你走入android编译系统的泥潭前，请先请教编译系统的拥有者（android编译小队mailto:android-build-team）。也就是说，这里有一些在表面之下的笔记。

 

环境配置/buildspec.mk 版本：

 

为了使得人们能够更简单地修改编译系统，当改变buildspec.mk或者重新运行环境配置脚本变得必要时，他们在BUILD_ENV_SEQUENCE_NUMBER当中包含了一个版本号。如果这个变量并不与编译系统预期的相对应，编译就会失败并打印出错误信息来解释发生了什么。如果你做了一个需要更新的改动，你需要更新两个地方，然后消息才会被打印。

(1)在config/envsetup.make中，增长CORRECT_BUILD_ENV_SEQUENCE_NUMBER的定义。

(2)在buildspec.mk.default中，更新BUILD_ENV_SEQUENCE_DUMBER定义来与config/envsetup.make中的其中一个进行对应。

自动化脚本从编译系统当中取得值，所以他们也会触发警告。

 

额外的makefile变量：

 

你也许不应该使用这些变量。在使用他们之前请去请教android编译小队。这些主要是为了其他重大问题的工作或者是并没有完全正确运行的东西。

 

LOCAL_ADDITIONAL_DEPENDENCIES：

如果你的模块需要依赖于任何并不在其中编译的东西，你可以把这些编译目标加入到LOCAL_ADDITIONAL_DEPENDENCIES当中。通常的这是一个为了一些非自动化创建的依赖关系工作的工作区。

 

LOCAL_BUILT_MODULE：

当一个模块被编译时，这个模块被创建到一个中间目录然后复制到最终的位置。LOCAL_BUILT_MODULE是中间文件的全路径。查看LOCAL_INSTALLED_MODULE来了解模块的最终安装位置的路径。

 

LOCAL_HOST：

通过host_xxx.make的包含关系的设置来告诉base_rules.make和其他的我们正在为主机编译的包含文件。Kenneth把这个做成了openbinder的一部分，并且我更喜欢将它清空所以规则、包含关系和定义不会在主机和目标之间重复。

 

LOCAL_INSTALLED_MODULE：

模块最终所处的位置的路径的全称。查看LOCAL_BUILT_MODULE来了解中间文件的位置，这些文件实际表明了变异规则构造的方式。

 

LOCAL_REPLACE_VARS：

用于一些遗留的openbinder的特殊值集合的编译脚本的资料。

 

LOCAL_SCRIPTS：

用于一些openbinder编译系统中我们也许会发现方便的脚本文件。

LOCAL_MODULE_CLASS：

这是一种模块。这个变量被用于创建其他的用来放置模块的其他变量名。查看base_rules.make和envsetup.make。

 

LOCAL_MODULE_NAME：

设置为LOCAL_BUILT_MODULE的叶名字。我不确定，但是看起来它被用在WHO_AM_I变量来确定漂亮的打印出什么在被编译。

 

LOCAL_MODULE_SUFFIX：

后缀会被追加到LOCAL_MODULE来形成LOCAL_MODULE_NAME。比如说，.so/.a/.dylib。

 

LOCAL_STRIP_MODULE：

通过在base_rules.make文件中计算来指明是否这个模块应该真正的被剥离，基于是否LOCAL_STRIPPABLE_MODULE被设置，以及是否这个组合在曾经的剥离模块当中被配置。在Iliyan的剥离工具中，这个可能会改变。

 

LOCAL_STRIPPABLE_MODULE：

通过包含makefile文件来设置，如果模块是可剥离的。可执行文件和共享库都是这样。

 

LOCAL_SYSTEM_SHARED_LIBRARIES：

当编译基本库:libc、libm、libdl时被使用。通常它被设置为”none”，正如在$(CLEAR_VARS)中。当编译这些库的时候，它被设置为他们链接的目标。比如说,libc，libstdc++和libdl并不和其他任何东西链接，并且libm链接到libc。通常的，当值为none的时候，这些变量会自动的链接到可执行文件和库，所以你不需要手动的指明他们。