4. Tina SDK目录结构解析
说实话，刚接触全志Tina这套构建系统时，我也有点懵。三个东西搅在一起——Makefile、Kconfig、Buildroot。它们各自干什么？怎么配合的？
今天咱们就把这层窗户纸捅破。你搞懂了这三个核心机制，Tina的构建流程在你眼里就是透明的。
4.1 Makefile体系：构建的骨架
Tina的Makefile不是单个文件，而是一整套体系。我习惯把它分成三层：
| 层级 | 位置 | 职责 |
|---|---|---|
| 顶层Makefile | tina/目录下 | 入口调度，解析命令行参数，调用子模块 |
| 包级Makefile | package/xxx/Makefile | 定义单个软件包的下载、编译、安装规则 |
| 规则Makefile | buildroot/support/下的*.mk | 通用编译模板，autotools、cmake、meson等框架支持 |
顶层Makefile其实很薄。你执行 make 时，它主要做两件事：加载Buildroot的配置，然后跳转到Buildroot的构建流程里。
# tina/Makefile 简化示意
include buildroot/build/Makefile.in
%:
@$(MAKE) -C buildroot $@嗯，这里要注意。Tina的顶层Makefile本质上是个代理。真正的编译逻辑在Buildroot那边。我刚开始不知道，直接在顶层Makefile里加自定义目标，结果死活不生效。后来才明白——你得去Buildroot的Makefile体系里加。
4.2 Kconfig配置系统：选择的艺术
Kconfig是Linux内核那边传过来的配置系统。Tina用它来管理所有可选项——芯片型号、外设驱动、文件系统、应用包……说白了，它就是你的「菜单」。
Kconfig文件散布在各个目录下：
- target/allwinner/ — 芯片级配置，选CPU、DDR、启动方式
- package/ — 包级配置，每个包的Config.in
- buildroot/configs/ — 板级默认配置，比如
tina_t113_defconfig
执行 make menuconfig 时，系统会递归读取所有Kconfig文件，生成一个树形菜单。你选完保存，结果写到 .config 文件里。
我曾经踩过一个坑：在menuconfig里选了一个包，但编译时没生效。查了半天，发现那个包的Config.in里依赖了另一个包，我没选。Kconfig的依赖链是自动检查的，但如果你手动改了.config文件，它不会帮你校验。
make menuconfig 或 make defconfig 来修改配置。直接编辑 .config 文件，依赖关系会乱掉。我曾经这么干过，结果编译到一半报错，浪费了半小时。
4.3 Buildroot集成原理：一切皆包
Buildroot是Tina构建系统的核心引擎。它的哲学很简单——一切皆包。
Linux内核是一个包。U-Boot是一个包。busybox是一个包。你的应用程序也是一个包。每个包都有自己的Makefile，定义怎么下载、怎么编译、怎么安装。
Buildroot的构建流程大致分四步：
- 配置阶段 — 读取.config，确定要编译哪些包
- 下载阶段 — 从网络或本地缓存拉取源码
- 编译阶段 — 按依赖顺序逐个编译包
- 打包阶段 — 生成rootfs、固件镜像
每个包的编译又分三步：configure → build → install。Buildroot提供了通用模板，你只需要填几个变量就行。
# package/hello/Makefile 示例
HELLO_VERSION = 1.0
HELLO_SITE = /path/to/source
HELLO_INSTALL_TARGET = YES
define HELLO_BUILD_CMDS
$(MAKE) -C $(@D)
endef
define HELLO_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(@D)/hello $(TARGET_DIR)/usr/bin/
endef
$(eval $(generic-package))你看，就这么几行。Buildroot的 generic-package 模板帮你处理了下载、解压、依赖检查、交叉编译环境设置。你只需要写编译和安装命令。
核心理解： Tina = Kconfig（选什么） + Makefile（怎么编） + Buildroot（编出来放哪）。三者缺一不可。
4.4 三者如何协同工作？
我画了一张图，帮你理清它们的关系：
说白了，你执行 make menuconfig 时，是在跟Kconfig打交道。你选完保存，系统生成 .config。然后你执行 make，顶层Makefile读取 .config，把任务交给Buildroot。Buildroot根据配置，按依赖顺序编译每个包，最后打包成固件。
我刚开始调优时，总想跳过某个环节。比如直接改.config，或者手动编译某个包再塞进rootfs。结果要么依赖不对，要么文件冲突。后来我学乖了——尊重这套流程，它帮你省的时间远比你绕开它省的多。
4.5 性能调优视角：这三个机制能怎么优化？
你可能会问：这些机制跟性能调优有什么关系？关系大了。
| 机制 | 调优切入点 | 我常用的手段 |
|---|---|---|
| Kconfig | 裁剪不必要的包和驱动 | 用 make savedefconfig 生成最小配置 |
| Makefile | 并行编译、增量编译 | 设置 BR2_JLEVEL=4 或更高 |
| Buildroot | 缓存下载、ccache、预编译工具链 | 开启 BR2_CCACHE，配置本地下载缓存 |
举个例子。我做过一个项目，默认配置编译要40分钟。我通过Kconfig把没用到的Wi-Fi驱动、蓝牙协议栈、测试工具全去掉，编译时间降到25分钟。再开ccache和并行编译，降到12分钟。
嗯，这三个机制是Tina构建系统的基石。你理解了它们，后面讲增量编译、分布式编译、缓存策略时，才能知道它们作用在哪个环节上。