Linux 内核:Kconfig/kbuild 内部的过程( 三 )

这将生成一个 .d 文件,内容如下:
init_task.o: init/init_task.c include/linux/kconfig.hinclude/generated/autoconf.h include/linux/init_task.hinclude/linux/rcupdate.h include/linux/types.h...然后主程序 fixdep 通过将 depfile 文件和命令行作为输入来处理其他两个依赖项,然后以 makefile 格式输出一个 .<target>.cmd 文件,它记录命令行和目标的所有先决条件(包括配置) 。它看起来像这样:
# The command line used to compile the targetcmd_init/init_task.o := gcc -Wp,-MD,init/.init_task.o.d -nostdinc ......# The dependency filesdeps_init/init_task.o :=$(wildcard include/config/posix/timers.h)$(wildcard include/config/arch/task/struct/on/stack.h)$(wildcard include/config/thread/info/in/task.h)... include/uapi/linux/types.harch/x86/include/uapi/asm/types.hinclude/uapi/asm-generic/types.h...在递归 make 中,.<target>.cmd 文件将被包含,以提供所有依赖关系信息并帮助决定是否重建目标 。
这背后的秘密是 fixdep 将解析 depfile(.d 文件),然后解析里面的所有依赖文件,搜索所有 CONFIG_ 字符串的文本,将它们转换为相应的空的头文件,并将它们添加到目标的先决条件 。每次配置更改时,相应的空的头文件也将更新,因此 kbuild 可以检测到该更改并重建依赖于它的目标 。因为还记录了命令行,所以很容易比较最后和当前的编译参数 。
展望未来Kconfig/kbuild 在很长一段时间内没有什么变化,直到新的维护者 Masahiro Yamada 于 2017 年初加入,现在 kbuild 正在再次积极开发中 。如果你不久后看到与本文中的内容不同的内容,请不要感到惊讶 。


推荐阅读