Makefile

前言：

android的Android.mk就是一段段Makefile单元，很多第三方库直接提供makefile，需要能够大致的读懂makefile文件,如增量更新的bspath库提供的makefile就有错误，需要修改。另外虽说现在google推荐使用cmake，但是如果遇见Android.mk还是需要能够读懂。

什么是Makefile

无论是c、c++首先要把源文件编译成中间代码文件，在Windows下也就是 .obj 文件，UNIX下是 .o 文件，即 Object File，这个动作叫做编译（compile），然后再把大量的Object File合成执行文件或者静动态库，这个动作叫作链接（link）。

个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，如何进行链接等等操作。
makefile 就是“自动化编译”，告诉make命令如何编译和链接,即make工具的配置脚本。
默认的情况下，gnu make命令会在当前目录下按顺序找寻文件:
"GNUmakefile”、“makefile”、“Makefile”
备注：最好不要用“GNUmakefile”，这个文件是GNU的make识别的（Windows Nmake就不识别）

当然，也可以使用别的文件名来书写Makefile，比如：“Make.Linux”，“Make.android”。这样在使用时候就需要 make -f XX 或者 make --file XX。

Android.mk

微小 GNU makefile 片段。
将源文件分组为模块。 模块是静态库、共享库或独立可执行文件。 可在每个 Android.mk 文件中定义一个或多个模块，也可在多个模块中使用同一个源文件。

#源文件在的位置。宏函数 my-dir 返回当前目录（包含 Android.mk 文件本身的目录）的路径。
LOCAL_PATH := $(call my-dir)
#引入其他makefile文件。CLEAR_VARS 变量指向特殊 GNU Makefile，可为您清除许多 LOCAL_XXX 变量
#不会清理 LOCAL_PATH 变量
include $(CLEAR_VARS)
#存储您要构建的模块的名称 每个模块名称必须唯一，且不含任何空格
#如果模块名称的开头已是 lib，则构建系统不会附加额外的前缀 lib；而是按原样采用模块名称，并添加 .so 扩展名。
LOCAL_MODULE := hello-jni
#包含要构建到模块中的 C 和/或 C++ 源文件列表 以空格分开
LOCAL_SRC_FILES := hello-jni.c
#构建动态库
include $(BUILD_SHARED_LIBRARY) 

变量和宏

定义自己的任意变量。在定义变量时请注意，NDK 构建系统会预留以下变量名称：
- 以 LOCAL_ 开头的名称，例如 LOCAL_MODULE。
- 以 PRIVATE_、NDK_ 或 APP 开头的名称。构建系统在内部使用这些变量。
- 小写名称，例如 my-dir。构建系统也是在内部使用这些变量。
如果为了方便而需要在 Android.mk 文件中定义自己的变量，建议在名称前附加 MY_。

常用内置变量

image.png

模块描述变量

image.png

导出给引入模块的模块使用：
LOCAL_EXPORT_CFLAGS
LOCAL_EXPORT_CPPFLAGS
LOCAL_EXPORT_C_INCLUDES
LOCAL_EXPORT_LDLIBS

引入其他模块

#将一个新的路径加入NDK_MODULE_PATH变量
#NDK_MODULE_PATH 变量是系统环境变量
$(call import-add-path,$(LOCAL_PATH)/platform/third_party/android/prebuilt)
#包含CocosDenshion/android目录下的mk文件
$(call import-module,CocosDenshion/android)
#这里即为 我需要引入 CocosDenshion/android 下面的Android.mk
#CocosDenshion/android 的路径会从 $(LOCAL_PATH)/platform/third_party/android/prebuilt 去查找

Application.mk

同样是GNU Makefile 片段,在Application.mk中定义一些全局(整个项目)的配置

APP_OPTIM

将此可选变量定义为 release 或 debug。在构建应用的模块时可使用它来更改优化级别。发行模式是默认模式，可生成高度优化的二进制文件。调试模式会生成未优化的二进制文件，更容易调试。

APP_CFLAGS

为任何模块编译任何 C 或 C++ 源代码时传递到编译器的一组 C 编译器标志

APP_CPPFLAGS

构建 C++ 源文件时传递到编译器的一组 C++ 编译器标志。

APP_ABI

需要生成的cpu架构(ndk r17 只支持：armeabi-v7a, arm64-v8a, x86, x86_64)

image.png

不同 Android 手机使用不同的 CPU，因此支持不同的指令集。

armeabi

此 ABI 适用于基于 ARM、至少支持 ARMv5TE 指令集的 CPU。此 ABI 不支持硬件辅助的浮点计算。 相反，所有浮点运算都使用编译器 libgcc.a 静态库中的软件帮助程序函数。

armeabi-v7a

armeabi-v7a ABI 使用 -mfloat-abi=softfp 开关强制实施规则，要求编译器在函数调用时必须传递核心寄存器对中的所有双精度值，而不是专用浮点值。 系统可以使用 FP 寄存器执行所有内部计算。 这样可极大地加速计算。
如果要以 armeabi-v7a ABI 为目标，则必须设置下列标志：
CFLAGS= -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16

arm64-v8a

此 ABI 适用于基于 ARMv8、支持 AArch64 的 CPU。它还包含 NEON 和 VFPv4 指令集。

x86

此 ABI 适用于支持通常称为“x86”或“IA-32”的指令集的 CPU。设置的标志如：
-march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32

x86_64

-march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel
现在手机主要是armeabi-v7a。查看手机cpu：

adb shell cat /proc/cpuinfo
adb shell getprop ro.product.cpu.abi

apk在安装的时候，如果手机是armeabi-v7a的，则会首先查看apk中是否存在armeabi-v7a目录，如果没有就会查找armeabi。

保证cpu目录下so数量一致。

如果目标是armeabi-v7a，但是拥有一个armeabi的，也可以把它放到armeabi-v7a目录下。但是反过来不行

image.png

APP_PLATFORM

此变量包含目标 Android 平台的名称。例如，android-3 指定 Android 1.5 系统映像

APP_STL

默认情况下，NDK 构建系统为 Android 系统提供的最小 C++ 运行时库 (system/lib/libstdc++.so) 提供 C++ 功能。

image.png