原文 : Linux-3.16/Document/kbuild/makefiles.txt
Linux 内核Makefiles
这个文档描述了Linux的内核Makefiles.
目录
1 简介
2 各自的任务
3 Kbuild 文件
3.1 定义目标
3.2 内置目标 — obj-y
3.3 可加载模块目标 — obj-m
3.4 输出符号对象
3.5 库文件目标 — lib-y
3.6 向下进入目录
3.7 编译标志
3.8 命令行依赖项
3.9 依赖项追踪
3.10 特殊规则
3.11 $(CC) 支持函数
3.12 $(LD) 支持函数
4 本机应用程序支持
4.1 简单本机程序
4.2 组合本机程序
4.3 定义动态链接库
4.4 使用C++编写的本机程序
4.5 本机程序的命令行选项控制
4.6 本机程序什么时候被编译
4.7 使用 hostprogs-$(CONFIG_FOO)
5 Kbuild的清除机制
_______________________________以下的章节未翻译
6 架构相关Makefile
7 导出头文件的Kbuild的语法
— 7.1 header-y— 7.2 genhdr-y
— 7.3 destination-y
— 7.4 generic-y
8 Kbuild 变量
9Makefile语言
10 贡献
11 TODO
.
.
.
1 简介
Makefile 有5部分:
Makefile 顶层的Makefile
.config 内核配置文件
arch/$(ARCH)/Makefile 架构Makefile
scripts/Makefile* 面向所有kbuild Makefile的通用规则
kbuild Makefiles 大约有500个
vmlinux (常驻内核映像) 和 modules (任意模块文件).
它会递归向下进入内核源码的子目录来编译这两个目标.
内核当前的配置决定哪些子目录会被访问,顶层的Makefile会以文本形式包含一个名为arch/$(ARCH)/Makefile
的架构Makefile.这个架构Makefile会给顶层的Makefile提供一些架构相关的特殊信息.
每一个子目录有一个携带着自上往下传递的命令的kbuild Makefile , 这些kbuild Makefile 利用来自
.config文件构造那些需要被kbuild编译成内置目标或模块目标的文件列表.
scripts/Makefile.* 包含所有的定义/规则 . 这些定义和规则被用来基于 kbuild makefiles 来编译内核.
2 各自的任务
大家和内核 Makefile 有四种关系.
*使用者* 是那些编译内核的人. 这些人使用命令诸如 "make menuconfig" 或 "make" .他们通常不需要阅读
或编辑任何内核的Makefile ( 或者其他任何源文件).
*普通的开发者* 是那些开发特定的部分, 比如设备驱动, 文件系统 和 网络协议的的人. 这些人需要维护他们所
工作的子系统的 kbuild makefiles.为了更有效率的实现这个目标,他们需要一些关于内核Makefile的整体知识,
加上kbuild的公共接口的详细信息.
*架构开发者* 是那些为某个架构工作,比如sparc或者ia64的人. 架构开发者需要知道架构Makefile和kbuild Makefile.
*Kbuild 开发者* 是为整个kbuild 系统工作的人,这些人需要知道内核Makefile 的方方面面.
这个文档适合普通开发者和内核开发者.
3 Kbuild 文件
内核里面的kbuild Makefile大多使用的是Kbuild 的基础结构. 这一章介绍kbuild Makefile的基本语法.
kbuild文件的推荐名字是Makefile, 但是Kbuild也可以使用,同时存在一个Makefile 和 Kbuild的时候,
优先使用Kbuild.
"3.1节 定义目标" 是一个简单的入门,之后的章节提供更多的细节和真实的例子.
3.1 定义目标
定义目标是Kbuild的主要(核心)部分.它们定义了需要被编译的文件,特殊的编译选项和需要被递归调用
的子目录.
最简单的kbuild makefile只包含一行:
例子: obj-y += foo.o
这个文件告诉kbuild这个文件夹下面有一个目标文件, 名字是 foo.o , 由 foo.c 或者 foo.S 编译生成.
如果需要把foo.o编译成一个模块, 那就要使用变量 obj-m. 因此通常使用下面的模式:
例子:
obj-$(CONFIG_FOO) += foo.o$(CONFIG_FOO) 可以等于 y ( 内置目标) 或者 m (模块).要是CONFIG_FOO 既不是 y 也不是 m , 那么
这个文件就不会编译和链接.
3.2 内置对象目标 – obj-y
kbuild Makefile 为 vmlinux 指定的目标文件都在 $(obj-y) 列表里面. 这是个基于内核配置文件的列表.
Kbuild编译$(obj-y)里面的所有文件. 然后调用"$(LD) -r " 来把这个文件整合到一个"build-in.o"文件里.
这个文件呆会被会上级Makefile链接到vmlinux里面.
$(obj-y)里面的文件顺序是有意义的,允许重复的文件,但是对于重复的文件,只有第一个会被链接进入
build-in.o, 多余的都会被忽略.
链接的顺序有意义的.因为有些函数(module_init() / __initcall) 在启动的时候调用,它们的调用顺序是
基于它们出现的顺序的.请记住改变链接顺序可能, 比如说改变你的SCSI控制器的检测顺序,然后你的
硬盘就重新排序了.
例子:
#drivers/isdn/i4l/Makefile # Makefile for the kernel ISDN subsystem and device drivers. # Each configuration option enables a list of files. obj-$(CONFIG_ISDN_I4L) += isdn.o obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
3.3 可加载模块目标 — obj-m
$(obj-m) 指定那些需要被编译成可加载的内核模块的文件.
一个模块可能由一个或多个文件编译而成.对于只需要一个源文件的模块,只需要简单的把它加到变量
$(obj-m) 里面.
例子:
#drivers/isdn/i4l/Makefile obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
注意: 在这个例子里面 $(CONFIG_ISDN_PPP_BSDCOMP) 等于 m
如果内核模块是由多个源文件编译而成,你希望仍然可以像上面这样编译它,然而kbuild需要知道那些
目标文件是用来编译你这个模块的,所以你需要通过定义一个$(<module_name>-y) 变量来告诉它.
例子:
#drivers/isdn/i4l/Makefile obj-$(CONFIG_ISDN_I4L) += isdn.o isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
在这个例子里面模块的名字是isdn.o. Kbuild将会编译$(isdn-y) 列表里面的目标文件然后对$(isdn-y)
文件运行"$(LD) -r" 来生成isdn.o.
由于Kbuild使用$(<module_name>-y)来识别组合模块,你需要用CONFIG_ 的值来实现可选的包含一
些文件作为组合模块的一部分.
例子:
#fs/ext2/Makefile obj-$(CONFIG_EXT2_FS) += ext2.o ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ namei.o super.o symlink.o ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ xattr_trusted.o
在这个例子里, 只有$(CONFIG_EXT2_FS_XATTR)等于y的时候, xattr.o, xattr_user.o 和 xattr_trusted.o
才是组合文件ext2.o 的一部分.
注意: 当你在编译内核的时候,上面的语法就会起作用.因此如果你有CONFIG_EXT2_FS=y, 那么kbuild就
会在独立的部分之外为你编译一个ext2.o,然后链接进入 built-in.o. 和你想得一样.
3.4 输出符号对象
在Makefile中,对于输出符号的模块,没有什么特殊的符号需要.
3.5 库文件目标 — lib-y
在obj-* 里面的对象用来编译模块或者为特定的目录组合出一个built-in.o对象.文件也有可能被一个库文件
包含: lib.a
特定文件夹下 lib-y 里面所有的文件会生成一个特定库.
出现在lib-y 里面并且同时出现在obj-y里面的对象不会被包含进入这个库,因为它可能在任何地方被引用.
注意同一个kbuild makefile 可能即有需要编译成内置对象的也有需要被编译成库文件的,这样同一个目录
下就可以同时存在一个built-in.o 文件和 一个 lib.a 文件.
例子:
#arch/x86/lib/Makefile lib-y := delay.o
这将基于delay.o生成一个lib.a . 为了让kbuild明白这里有一个lib.a需要被编译,这个文件夹需要出现在libs-y
里面.
请查看 "6.4 列出下级需要被访问的文件夹"
对lib-y的使用通常限制在 lib/ 和arch/*/lib 里面.
3.6 向下进入目录
只要你让编译系统知道了子目录,它就递归的执行make命令.
为了实现这些, 我们需要使用 obj-y 和 obj-m.
ext2 在一个单独的文件夹内, 在父级目录 fs/ 中的Makefile 使用下面的赋值语句来告诉Kbuild 向下执行:
例子:
#fs/Makefile obj-$(CONFIG_EXT2_FS) += ext2/
如果 CONFIG_EXT2_FS 被设置为 ‘y’ 或者 ‘m’ , 吧么对应的 obj- 变量就被设置好了, kbuild 会向下进入 ext2
目录.
Kbuild 仅使用这个信息来决定是否访问这个目录.子目录的Makefile 决定它们到底是被编译成buildin的还是
一个模块.
使用赋值文件夹名字的时候 CONFIG_ 变量是一个好习惯, 它允许kbuild在对应的CONFIG_ 变量 不是 y 或者
m 的时候将这个文件夹整体跳过.
3.7 编译标志
ccflags-y, asflags-y 和 ldflags-y
这三个变量在哪里被赋值就在哪里使用. 当递归编译的时候他们被常规的 cc , as 和 ld 调用使用.
注意: 之前有相同意义的标志是 EXTRA_CFLAGS, EXTRA_AFLAGS 和 EXTRA_LDFLAGS. 虽然
它们仍然被支持,但是
ccflags-y 指定 $(CC) 的编译选项
例子:
# drivers/acpi/Makefile ccflags-y := -Os ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
这个变量是必须有的因为顶层的Makefile有$(KBUILD_CFLAGS)变量并且使用它来作为整个编译
期间的编译选项.
asflags-y 指定as的编译选项
例子: #arch/sparc/kernel/Makefile asflags-y := -ansi
ldflags-y 指定$(LD)的链接选项
例子:
#arch/cris/boot/compressed/Makefile ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
subdir-ccflags-y, subdir-asflags-y
上面的两个标志位和 ccflags-y , asflags-y 很相像. 不同的地方是sudir- 变量对当它自身是父目录
的时候的子目录kbuild有效.
由subdir-指定的选项会优先与非subdir-指定的选项添加到命令行中.
例子:
subdir-ccflags-y := -Werror
CFLAGS_$@, AFLAGS_$@
CFLAGS_$@ 和 AFLAGS_$@ 仅在当前的kbuild makefile中使用.
$(CFLAGS_$@) 为$(CC)指定每个文件的选项. $@ 部分是一个指定它服务的文件的字面值
例子:
# drivers/scsi/Makefile CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \ -DGDTH_STATISTICS
这两行为aha152x.o 和 gdth.o 指定特殊的编译选项.
$(AFLAGS_$@) 是一个类似的标志位,服务与特定文件的汇编编译选项.
例子:
# arch/arm/kernel/Makefile AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
3.9 依赖项追踪
// 我不大理解下面的 :
Kbuild 使用下面的规则来追踪依赖项:
1) 所有的依赖的文件( *.c 和 *.h 文件)
2) 对所有的依赖文件使用COFIG_ 选项
3)对目标使用命令行选项
3.10 特殊规则
当kbuild的基础部分不能提供需要的支持的时候,就需要使用特殊规则.一个例子是头文件需要被在
编译过程中生成 . 另一个例子是架构模块需要特殊的规则来准备启动镜像.
特殊的规则和普通的规则的书写方式是一样的.
kbuild不在指定makefile的文件夹下执行,所以应给为所有的需求文件和目标给定一个相对目录..
定义特殊规则的时候使用两个规则:
$(src)
$(src) 是一个指向目标Makefile所在文件夹的相对目录. 当想要指定文件在目录树中位置的时候就就要
指定$(src).
$(obj)
$(obj) 是指向目标文件被保存的目录.当想要生成文件的时候就要指定$(obj)
例子:
#drivers/scsi/Makefile $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl $(CPP) -DCHIP=810 – < $< | … $(src)/script_asm.pl
这是一个特殊规则,按照正常的make需求语法写的.
目标文件依赖两个文件.依赖文件有$(src) 前缀,怒表文件有$(obj)前缀.
$(kecho)
在一个规则中为使用者输出信息是一个好习题.但是当执行make -s 的时候使用者不希望看到警告和
错误之外的信息.
为了支持这个kbuild定义了$(kecho) , 它只有在没有指定 make -s 的时候才向stdout输出文本信息.
例子:
#arch/blackfin/boot/Makefile $(obj)/vmImage: $(obj)/vmlinux.gz $(call if_changed,uimage) @$(kecho) ‘Kernel: $@ is ready’
3.11 $(CC) 支持函数
内核可能绑定了很多不同版本的$(CC) , 各自支持一系列各不相同的特征和选项. kbuild 提供基本的支持
来检测$(CC)的有效选项, $(CC) 通常是gcc ,但是其他的替代品也是可行的.
as-option
当$(CC)用来编译汇编(*.S) 文件的时候, as-option 检测$(CC) 对给定选项的支持.如果第一选项不支持的
话一个可选的第二选项被使用.
例子:
#arch/x86/kernel/Makefile vsyscall-flags += $(call cc-ldoption, -Wl$(comma)–hash-style=sysv)
在上面的例子里面, 如果$(CC) 支持的话,vsyscall-flags 将会被赋值
-Wl$(comma)–hash-style=sysv , 第二个参数是可选的,如果第一个参数不支持就选择第二个参数.
as-instr
as-instr检测汇编是否报告特殊的指令,输出是选项1或者选项2. 在测试指令中支持C的转意符号.
注意: as-instr 使用 KBUILD_AFLAGS 作为 as 的选项.
cc-option
cc-option 用来检测 $(CC) 是否支持一个给定选项, 不支持可选的第二选项.
例子:
#arch/x86/Makefile cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
在上面的例子里面. cflags-y 会被赋值为-march=pentium-mmx如果$(CC) 支持的话,否则就是-march=i586
.第二个参数是可选的,如果缺省的话, cflags-y就会在编译器不支持选项1 的时候赋值为空.
注意: cc-option使用KBUILD_CFLAGS来作为$(CC)的选项.
cc-option-yn
cc-option-yn 被用来检测gcc是否支持给定选项, 支持就返回 y , 否则 n
例子:
#arch/ppc/Makefile biarch := $(call cc-option-yn, -m32) aflags-$(biarch) += -a32 cflags-$(biarch) += -m32
在上面的例子中, 如果gcc支持-m32的话,$(biarch) 会被设置成y , 扩展变量$(aflags-y) 和$(cflags-y)就会对应的
被设置成 -a32 和 -m32.
注意: cc-option-yn使用KBUILD_CFLAGS来作为$(CC)的选项.
cc-option-align
gcc3.0 以上的版本改变了用来指定诸如函数或者循环的对齐方式的选项的类型.当使用它作为对齐选项的前缀的
时候,他会选择正确的前缀:
gcc < 3.00 cc-option-align = -malign gcc >= 3.00 cc-option-align = -falign
例子:
KBUILD_CFLAGS += $(cc-option-align)-functions=4
在上面的例子中,如果gcc版本大于等于3.0,就就用-falign-functions=4,否则就是-malign-functions=4.
注意:cc-option-align使用KBUILD_CFLAGS来作为$(CC)的选项.
cc-disable-warning
cc-disable-warning 检测gcc是否支持给定的警告并且返回关闭它的命令行. 需要特殊的函数,因为gcc4.4
和之后的版本接受任何为止的-Wno-*选项并且当代码中有多个需要警告的部分的时候仅警告一个.
例子:
Example: KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
上面的例子中, 如果gcc真的支持它的话,unused-but-set-variable选项会被加入到KBUILD_CFLAGS中.
cc-version
cc-version 返回$(CC)编译器的数字话版本号.格式是:<主版本号><从版本号> ,两个都是数字.gcc3.14返回
0314. cc-version在一个特定的$(CC)版本在某个领域有缺陷的时候就会起作用,比如 -mregparm=3在某些
gcc版本是不可行的,虽然gcc会接受这个选项.
例子:
#arch/x86/Makefile
cflags-y += $(shell \ if [ $(call cc-version) -ge 0300 ] ; then \ echo "-mregparm=3"; fi 😉
在上面的例子中, -mregparm=3 仅在gcc3.0及以上的版本被使用.
cc-ifversion
cc-ifversion检测$(CC)的版本并且如果版本检测通过的话就等于最后一个参数.
例子:
#fs/reiserfs/Makefile ccflags-y := $(call cc-ifversion, -lt, 0402, -O1)
在这个例子中,如果gcc的版本小于4.2的话,ccflags-y就会被赋值为 -O1.
cc-ifversion 接受所有的shell操作符号:
-eq, -ne, -lt, -le, -gt, and -ge
第三个参数在这个例子里面是字面值,但是它也可以是扩展变量或者宏.
cc-fullversion
当需要特定的gcc版本的时候, 就需要使用cc-fullversion.一个典型的例子是特定的gcc版本不可用的时候.
cc-fullversion和cc-version相比能指定更多的特定版本.
例子:
#arch/powerpc/Makefile $(Q)if test "$(call cc-fullversion)" = "040200" ; then \ echo -n ‘*** GCC-4.2.0 cannot compile the 64-bit powerpc ‘ ; \ false ; \ fi这个例子中当检测到特定的gcc版本的时候就会给使用者解释为什出错终止.
cc-cross-prefix
cc-cross-prefix用来检测在特定前缀的路径中是否存在$(CC) . 第一个存在$(CC) 的路径会被返回, 如果
所有的路径路径都没有的话就返回空.
调用cc-cross-prefix的时候,用一个空白来间隔各个前缀.这个函数在架构Makefile 试图设置CROSS_COMPILE
为通用路径同时有多个选择的时候使用.
建议只有在交叉编译试图设置CROSS_COMPILE的时候使用.如果CROSS_COMPILE已经设置的话就保
留原有值.
例子:
Example: #arch/m68k/Makefile ifneq ($(SUBARCH),$(ARCH)) ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-) endif endif
3.12 $(LD) 支持函数
ld-option
ld-option 用来检测$(LD) 是否支持给定的选项. 他需要两个参数, 第二个参数是可选的,当$(LD) 不支持第
一个选项的时候就使用它.
4 本机应用程序支持
Kbuild 支持在编译期间在本机上编译可执行文件. 需要两步来编译一个本机可执行文件.
第一步告诉kbuild存在一个本机可执行文件(需要编译) .利用变量hostprogs-y来完成.
第二布告诉kbuild这个可执行文件的显式依赖. 这可以通过两种方式来完成.要么将其加入其他目标的依赖,
要么利用变量$(always).
下面讲这两种方式.
4.1 简单本机程序
有些情况下我们需要在编译的时候编译并执行一个程序.下面一行告诉kbuild程序 bin2hex 应该在本机上编译.
例子:
hostprogs-y := bin2hex
在上面的例子中,kbuild假设bin2hex是从一个C的源文件: bin2hex.c编译而来的. 这个文件在和当前Makefile相
同的路径下.
4.2 组合本机程序
本机程序可能是由多个源文件组合编译的.这里用来为本机程序定义组合对象的语法和用于编译内核对象的很
相似. $(<executable>-objs) 列出用来链接生成最终执行文件的所有对象.
例子:
#scripts/lxdialog/Makefile hostprogs-y := lxdialog lxdialog-objs := checklist.o lxdialog.o
扩展名为.o的文件由对应的.c文件编译而来.在上面的例子中, checklist.c 编译成 checklist.o, lxdialog.c 编译成
lxdialog.o. 最终两个.o文件链接成执行文件lxdialog.
注意: 对于本机程序, 禁止使用语法<executable>-y
4.3 定义动态链接库
扩展名字为.so的对象视为动态链接库, 会被编译成独立地址的对象.Kbuild提供对动态链接库的支持,但是它的
使用是很受限制的.
下面的例子中,动态链接库libkconfig.so被用来链接生成可执行文件 conf.
例子:
#scripts/kconfig/Makefile hostprogs-y := conf conf-objs := conf.o libkconfig.so libkconfig-objs := expr.o type.o
动态链接库通常需要对应的-objs 文件行,并且上面的例子中libkconfig是由文件expr.o type.o组合生成的.
expr.o type.o将会别编译为位置独立的对象并且链接成libkconfig.so . 不支持C++的动态链接库.
4.4 使用C++编写的本机程序
kbuild支持使用C++写的本机本件.这是为了独自支持kconfig而引入的, 不推荐随便使用.
例子:
#scripts/kconfig/Makefile hostprogs-y := qconf qconf-cxxobjs := qconf.o
在上面的例子中可执行文件由C++文件, $(qconf-cxxobjs)标识的变量 qconf.cc 生成.
如果qconf 是由.c文件和.cc文件混合组成的,那么应该添加下面的一行来标识它.
例子:
#scripts/kconfig/Makefile hostprogs-y := qconf qconf-cxxobjs := qconf.o qconf-objs := check.o
4.5 本机程序的命令行选项控制
在编译本机程序的时候, 可能需要特殊的标志. 程序总是使用变量$(HOSTCFLAGS) 来传递选项,使用编译器
$(HOSTCC) 编译.
,使用变量HOST_EXTRACFLAGS 来设置标志会影响到由这个Makefile编译的所有本机程序.
例子:
#scripts/lxdialog/Makefile HOST_EXTRACFLAGS += -I/usr/include/ncurses为单文件设置标志按照下面的结构来.
例子:
HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
同样也可以为连接器指定特殊的标志
例子:
#scripts/kconfig/Makefile HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
当链接qconf的时候,就会传递额外的选项"-L$(QTDIR)/lib".
4.6 本机程序什么时候被编译
只有当本机程序作为一个依赖项的时候才会去编译它. 有两种方式来做:
(1) 在特殊的规则中加入作为依赖项.
例子:
#drivers/pci/Makefile hostprogs-y := gen-devlist $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist ( cd $(obj); ./gen-devlist ) < $<
目标$(obj)/devlist.h 只有在$(obj)/gen-devlist 更新后才会编译. 注意在特殊的规则中引用本机程序必须加前缀$(obj).
(2) 使用 $(always)
当没有合适的规则的时候,这个本机程序就应该在一个makefile进入的时候被编译.可以使用变量$(always).
例子:
#scripts/lxdialog/Makefile hostprogs-y := lxdialog always := $(hostprogs-y)
这样即使lxdialog没有被任何规则引用,它也会被编译.
4.7 使用 hostprogs-$(CONFIG_FOO)
一个典型的Kbuild 文件模式看起来是下面这样的.
例子:
#scripts/Makefile hostprogs-$(CONFIG_KALLSYMS) += kallsyms
Kbuild识别 ‘y’ 作为build-in 的 ‘m’ 作为 模块的标志.因此一个配置为’m’的对象还是会被编译成二进制文件.换句话说,kbuild在处理
本机程序的时候, hostprogs-m 和hostprogs-y 视为相同的. 但是推荐使用hostprogs-y.
5 Kbuild的清除机制
编译内核的时候 ,make clean 删除在目录树中的大部分Kbuild生成的文件. 这包括诸如本件程序,列举在$(hostprogs-y),
$(hostprogs-m), $(always), $(extra-y) 和 $(targets)的目标文件 . 它们在执行make clean 的时候都被删除了. 符合匹配模式诸如
"*.[oas]", "*.ko"的文件加上一些kbuild 生成的其他杂七杂八的东西也都被删掉了.
使用$(clean-files)指定清除额外的文件.
例子:
#drivers/pci/Makefile clean-files := devlist.h classlist.h
当执行make clean的时候, devlist.h classlist.h 两个文件就被删掉了. 除非文件名字由/ 开头,否则kbuild默认文件名字是基于本Makefile
相同目录的相对路径.
使用$(no-clean-files)变量在make clean的时候执行特定的文件.仅在顶层makefile中有个特例使用了这个.
例子:
#Kbuild no-clean-files := $(bounds-file) $(offsets-file)
通常kbuild向下利用"obj-* := dir/"进入子目录. 但是在架构makefile中有些特别:)
例子:
#arch/x86/boot/Makefile subdir- := compressed/
… 一些架构东西不翻译 …注意:: make clean的时候所有的列举在 core-y, libs-y, drivers-y and net-y 中的文件夹都会被访问到.
…其他章节不翻译
绊住的不仅是双脚，还有未来。
