Android.mk 编译流程分析--android的build系统

关于Android.mk,可以很容易找到关于它怎么编写的资料,不过最近在移植一个开源的linux项目,抛弃源工程的configure+make机制放入android源码里面用 mm命令来来编译,总是各种坑,在android源码里面编译要求很高比如 一个int 函数没有return,也会报错,编译的模块需要依赖一个自己私自开发的so库时候,用参数 LOCAL_LDFLAGS来指定,也是种种问题,这些问题比如最终发现多了一个空格等等,甚至于解决了也是不知其然,被迫无奈,来探究一下mm这个命令到底是干了啥:

具体的分析细节不赘述,直接上理论成果吧(请忽略上下文,直接看4.0):

1.0 编译首要的工作都是一个 source build/envsetup.sh 和 lunch,这个source 命令当然是linux的shell所支持的,他的作用就是把后面的 build/envsetup.sh 脚本文件中定义的变量和函数 导出来,可以直接在当前shell上调用。 这其中的函数就有                            m mm mmm 和lunch等等,然后我们就可以直接在终端里面敲这些函数。详细分析 参考:https://blog.csdn.net/Luoshengyang/article/details/19023609

2.0 那么mm函数做了什么? 一句shell命令而已: make -C /home/XXX  -f build/core/main.mk all_modules ,就是在前面先定义了几个变量,然后执行make ,所以后续所有的工作,就是makefile的工作,那么实际上还是linux的 make,只是这个makefile,可是相当庞大,可以当做一个project去分析了,完整的具备了变量,函数,条件判断+系统命令。看这个工程需要足够的makefile知识,后续单独总结一篇吧。

3.0 makefile中基本就三种东西:依赖关系、命令规则、变量和函数,它的执行顺序,多线程的,可不是像shell脚本一样顺序执行,而是直接根据目标文件,查找依赖关系,然后执行命令规则生成文件,里面唯一可以执行的,就是命令规则,在这里面可以用shell脚本的命令,可以调用shell里面的语法,至于 makefile中的变量和函数,也只有在这个命令规则中使用的时候才会调用,函数其实和变量用法一样,所以就不要想着突然在Android.mk文件中echo 了,这不是shell,除非echo放在命令规则里面,而且该命令规则会被执行

4.0 终极问题:拿一个 hello_world.c文件编译成一个 test_hello库来看,编写Android.mk文件,最终怎么 用什么路径的gcc把这个.c文件怎么个编译连接成一个 so库并且放到什么目录下面了?注:个人的android源码 工程 为7.0

使用Android.mk文件:

...
LOCAL_SRC_FILES:= hello.c 
LOCAL_MODULE:= libhello_test23
include $(BUILD_SHARED_LIBRARY)
...#呵呵,就是不完整

在shared_library_internal.mk文件中,有这么一条规则

(找到这个地方可是花费了不少时间,开始当然是从源头而下,结果在makefile众多的变量嵌套里面一下子就跟丢了线索,就开始另谋出路,在build目录下grep“:”,企图逐一查看所有的命令规则,结果太多太多,想到Android.mk中的句法include $(BUILD_SHARED_LIBRARY),通过$(warning "BUILD_SHARED_LIBRARY $(BUILD_SHARED_LIBRARY)") 查看了下build/core/shared_library.mk 这个文件,没有什么线索,同样的还有两个句法LOCAL_LDFLAGS和LOCAL_CFLAGS,果然,顺着这两个变量的调用找到了想要的结果) 两个echo是我加上去跟踪信息的(notepad++里面设置把所有的符号都显示出来,比如看到上面的空格和tab,最后一个没有续航符号,下一行就是以tab开头,这就是一个典型的 make的命令规则)

扫描二维码关注公众号,回复: 5748866 查看本文章

这个transform-o-to-shared-lib, 是一个预定义的函数,看名字也能知道它的作用了,在definitions.mk文件中还有很多这样的定义

比如把.c文件编译成.o文件的函数,如上图。要查看这些函数具体做了什么,直接在里面echo 

比如刚刚$(transform-o-to-shared-lib) 这个函数:

define transform-o-to-shared-lib
@echo "target SharedLib: $(PRIVATE_MODULE) ($@)"
@mkdir -p $(dir $@)
$(transform-o-to-shared-lib-inner)
endef

==>define transform-o-to-shared-lib-inner
echo "wang PRIVATE_CXX:$(PRIVATE_CXX)"  #当然这个又是我加进去的
$(hide) $(PRIVATE_CXX) \
    -nostdlib -Wl,-soname,$(notdir $@) \
    -Wl,--gc-sections \
    $(if $(filter true,$(PRIVATE_CLANG)),-shared,-Wl$(comma)-shared) \
    $(PRIVATE_TARGET_GLOBAL_LD_DIRS) \
    $(PRIVATE_TARGET_CRTBEGIN_SO_O) \
    $(PRIVATE_ALL_OBJECTS) \
    -Wl,--whole-archive \
    $(call normalize-target-libraries,$(PRIVATE_ALL_WHOLE_STATIC_LIBRARIES)) \
    -Wl,--no-whole-archive \
    $(if $(PRIVATE_GROUP_STATIC_LIBRARIES),-Wl$(comma)--start-group) \
    $(call normalize-target-libraries,$(PRIVATE_ALL_STATIC_LIBRARIES)) \
    $(if $(PRIVATE_GROUP_STATIC_LIBRARIES),-Wl$(comma)--end-group) \
    $(if $(filter true,$(NATIVE_COVERAGE)),$(PRIVATE_TARGET_COVERAGE_LIB)) \
    $(PRIVATE_TARGET_LIBATOMIC) \
    $(PRIVATE_TARGET_LIBGCC) \
    $(call normalize-target-libraries,$(PRIVATE_ALL_SHARED_LIBRARIES)) \
    -o $@ \
    $(PRIVATE_TARGET_GLOBAL_LDFLAGS) \
    $(PRIVATE_LDFLAGS) \
    $(PRIVATE_TARGET_CRTEND_SO_O) \
    $(PRIVATE_LDLIBS)

endef

上面这一大坨,可以直接用echo "XXXX" ,复制到xxx可以输出看到完整的实际展开的命令参数

输出了下,大概是这样子的。。。

嗯,很可怕,没敢贴完整。。这只是编译一个64位库的输出,还有一份同样的32bit的库的编译,所有其他的各种文件各种变量,无非就是根据具体情况来确定用什么编译器,文件的路径,连接什么库,需要什么参数。所以说整个编译架构,是一份完备的proj,用makefile写的proj,直接在linux终端上通过 grep来查看这些变量的定义和调用如:

在build目录下:grep "(transform" * -rn 查看这些函数的调用

分析这整个工程还需要其他更多的关于makefile的知识 

https://blog.csdn.net/u012459903/article/details/88345510

猜你喜欢

转载自blog.csdn.net/u012459903/article/details/88239561
今日推荐