Linux内核Makefile文件

Godbach

Makefile包括五部分
--------------------------------------------
        Makefile                    顶层Makefile文件
        .config                     内核配置文件
        arch/$(ARCH)/Makefile       机器体系Makefile文件
        scripts/Makefile.*          所有内核Makefiles共用规则
        Kbuild                      其它makefile文件
   
通过内核配置操作产生.config文件，顶层Makefile文件使用该文件的配置。顶层Makefile文件负责产生两个主要的程序：vmlinux
(内核image)和modules(模块)。顶层Makefile文件根据内核配置，通过递归编译内核代码树子目录建立这两个文件。机器体系
Makefile文件为顶层Makefile文件提供与机器相关的信息。每一个子目录有一个Makefile文件，子目录Makefile根据上级目录
Makefile命令启动编译。这些Makefile使用.config文件配置数据构建各种文件列表，并使用这些文件列表编译内嵌或模块目标文件。
scripts/Makefile.*包含了所有的定义和规则，与Makefile文件一起编译出内核程序。
角色分工
--------------------------------------------
人们与内核Makefile存在四种不同的关系：
用户           用户使用"make menuconfig"配置内核(生成.config配置文件)或"make"命令编译内核。他们通常不读或编辑内核Makefile文件或其他源文件。
普通开发者     普通开发者维护设备驱动程序、文件系统和网络协议代码，他们维护相关子系统的Makefile文件，因此他们需要内核Makefile文件整体性的一般知识和关于kbuild公共接口的详细知识。
体系开发者     体系开发者关注一个整体的体系架构，比如sparc或者ia64。体系开发者既需要掌握关于体系的Makefile文件，也要熟悉内核Makefile文件。
内核开发者     内核开发者关注内核编译系统本身。他们需要清楚内核Makefile文件的所有方面。
本文档的读者对象是普通开发者和系统开发者。
内核编译文件
--------------------------------------------
     内核中大多数Makefile文件是使用kbuild基础架构的Makefile文件。本章介绍kbuild的Makefile中的语法。
目标定义
--------------------------------------------
     目标定义是Makefile文件的主要部分(核心)。这些目标定义行定义了如何编译文件，特殊的兼容选项和递归子目录。最简单的Makefile只包含一行： obj-y += foo.o
     这行告诉kbuild在该目录下名为foo.o的目标文件(object)，foo.o通过编译foo.c或者foo.S而得到。如果foo.o编译成一个模块，则使用obj-m变量，因此常见写法如下：
     obj-$(CONFIG_FOO) += foo.o
     [color="#800000"]$(CONFIG_FOO)可以代表y(built-in对象)或m(module对象)。如果CONFIG_FOO不是y或m，那么这个文件不会被编译和链接。
内嵌对象 --- [color="#800000"]obj-y
--------------------------------------------
   
Makefile文件将为编译vmlinux的目标文件放在$(obj-y)列表中，这些列表依赖于内核配置。Kbuild编译所有的$(obj-y)文
件，然后调用"$(LD)
-r"合并这些文件到一个built-in.o文件中。built-in.o经过父Makefile文件链接到vmlinux。$(obj-y)中的文件
顺序很重要。列表中文件允许重复，文件第一次出现将被链接到built-in.o，后续出现该文件将被忽略。
     链接顺序之所以重要是因为一些函数在内核引导时将按照他们出现的顺序被调用，所以要牢记改变链接顺序意味着也要改变SCSI控制器的检测顺序和重数磁盘。
     # drivers/isdn/i4l/Makefile
     # 内核ISDN子系统和设备驱动程序Makefile
     # 每个配置项是一个文件列表
     obj-$(CONFIG_ISDN)            += isdn.o
     obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
可加载模块 --- [color="#800000"]obj-m
--------------------------------------------
     $(obj-m)表示对象文件(object files)编译成可加载的内核模块。
     一个模块可以通过一个源文件或几个源文件编译而成。Makefile只需简单地它们加到$(obj-m)。
     #drivers/isdn/i4l/Makefile
     obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
     注意：在这个例子中$(CONFIG_ISDN_PPP_BSDCOMP)含义是'm'。
     如果内核模块通过几个源文件编译而成，使用以上同样的方法。
     Kbuild需要知道通过哪些文件编译模块，因此需要设置一个[color="#800000"]$(-objs)变量。
     #drivers/isdn/i4l/Makefile
     obj-$(CONFIG_ISDN) [color="#800000"]+= isdn.o
     [color="#800000"]isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
     在这个例子中，模块名isdn.o. Kbuild首先编译$(isdn-objs)中的object文件，然后运行"$(LD) -r"将列表中文件生成isdn.o.
     Kbuild使用后缀-objs、-y识别对象文件。这种方法允许Makefile使用CONFIG_符号值确定一个object文件是否是另外一个object的组成部分。
     #fs/ext2/Makefile
     obj-$(CONFIG_EXT2_FS)        += ext2.o
     ext2-y := balloc.o bitmap.o
     ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
     在这个例子中，如果$(CONFIG_EXT2_FS_XATTR)表示'y'，则ext2.o只有xattr.o组成部分。
     注意： 当然，当你将对象文件编译到内核时，以上语法同样有效。因此，如果CONFIG_EXT2_FS=y，Kbuild将先编译ext2.o文件，然后链接到built-in.o。
导出符号目标
--------------------------------------------
     在Makefile文件中没有特别导出符号的标记。
库文件 --- [color="#800000"]lib-y
--------------------------------------------
     obj-*中的object文件用于模块或built-in.o编译。object文件也可能编译到库文件中--lib.a。     所有罗列在lib-y中的object文件都将编译到该目录下的一个单一的库文件中。
     包含在obj-y中的object文件如果也列举在lib-y中将不会包含到库文件中，因为他们不能被访问。但lib-m中的object文件将被编译进lib.a库文件。
     注意在相同的Makefile中可以列举文件到buit-in内核中也可以作为库文件的一个组成部分。因此在同一个目录下既可以有built-in.o也可以有lib.a文件。
     #arch/i386/lib/Makefile
     lib-y      := checksum.o delay.o
     这样将基于checksum.o、delay.o创建一个lib.a文件。
     对于内核编译来说，lib.a文件被包含在libs-y中。lib-y通常被限制使用在lib/和arch/*/lib目录中。
目录递归
--------------------------------------------
     Makefile文件负责编译当前目录下的目标文件，子目录中的文件由子目录中的Makefile文件负责编译。编译系统将使用obj-y和obj-m自动递归编译各个子目录中文件。
     如果ext2是一个子目录，fs目录下的Makefile将使用以下赋值语句是编译系统编译ext2子目录。
     #fs/Makefile
     obj-$(CONFIG_EXT2_FS) += ext2/
     如果CONFIG_EXT2_FS设置成'y(built-in)或'm'(modular)，则对应的obj-变量也要设置，内核编译系统将进入ext2目录编译文件。
   
内核编译系统只使用这些信息来决定是否需要编译这个目录，子目录中Makefile文件规定那些文件编译为模块那些是内核内嵌对象。当指定目录名时使用
CONFIG_变量是一种良好的做法。如果CONFIG_选项不为'y'或'm'，内核编译系统就会跳过这个目录。
编译标记
--------------------------------------------
     EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS
     所有的EXTRA_变量只能使用在定义该变量后的Makefile文件中。EXTRA_变量被Makefile文件所有的执行命令语句所使用。
     $(EXTRA_CFLAGS)是使用$(CC)编译C文件的选项。
     # drivers/sound/emu10k1/Makefile
     EXTRA_CFLAGS += -I$(obj)
     ifdef
          DEBUG EXTRA_CFLAGS += -DEMU10K1_DEBUG
      endif
     定义这个变量是必须的，因为顶层Makefile定义了$(CFLAGS)变量并使用该变量编译整个代码树。
     $(EXTRA_AFLAGS)是每个目录编译汇编语言源文件的选项。
     #arch/x86_64/kernel/Makefile
     EXTRA_AFLAGS := -traditional
     $(EXTRA_LDFLAGS)和$(EXTRA_ARFLAGS)用于每个目录的$(LD)和$(AR)选项。
     例如: #arch/m68k/fpsp040/Makefile
             EXTRA_LDFLAGS := -x
     CFLAGS_$@和AFLAGS_$@只使用到当前Makefile文件的命令中。$(CFLAGS_$@)定义了使用$(CC)的每个文件的选项。$@部分代表该文件。
      例如: # drivers/scsi/Makefile
[color="#000000"]             CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
[color="#000000"]             CFLAGS_gdth.o     = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
-DGDTH_STATISTICS
[color="#000000"]             CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
     这三行定义了aha152x.o、gdth.o和seagate.o文件的编译选项。
     $(AFLAGS_$@)使用在汇编语言代码文件中，具有同上相同的含义。
     例如: # arch/arm/kernel/Makefile
[color="#000000"]             AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
[color="#000000"]             AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
依赖关系
--------------------------------------------
     内核编译记录如下依赖关系：
          1) 所有的前提文件(both *.c and *.h)
         2) CONFIG_选项影响到的所有文件
         3) 编译目标文件使用的命令行
     因此，假如改变$(CC)的一个选项，所有相关的文件都要重新编译。
特殊规则
--------------------------------------------
     特殊规则使用在内核编译需要规则定义而没有相应定义的时候。典型的例子如编译时头文件的产生规则。其他例子有体系Makefile编译引导映像的特殊规则。特殊规则写法同普通的Make规则。
     Kbuild(应该是编译程序)在Makefile所在的目录不能被执行，因此所有的特殊规则需要提供前提文件和目标文件的相对路径。
     定义特殊规则时将使用到两个变量：
     $(src)： $(src)是对于Makefile文件目录的相对路径，当使用代码树中的文件时使用该变量$(src)。
     $(obj)： $(obj)是目标文件目录的相对路径。生成文件使用$(obj)变量。
     例如: #drivers/scsi/Makefile
[color="#000000"]             $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
[color="#000000"]             $(CPP) -DCHIP=810 - -objs)包含了所有的用于链接最终可执行程序的对象。
      例如: #scripts/lxdialog/Makefile
[color="#000000"]             hostprogs-y    := lxdialog
[color="#000000"]             lxdialog-objs := checklist.o lxdialog.o
     扩展名.o文件都编译自对应的.c文件。在上面的例子中checklist.c编译成checklist.o，lxdialog.c编译为lxdialog.o。最后两个.o文件链接成可执行文件lxdialog。
     注意：语法-y不能用于定义主机程序。
定义共享库
     扩展名为.so的对象是共享库文件，并且是位置无关的object文件。内核编译系统提供共享库使用支持，但使用方法有限制。在下面例子中libkconfig.so库文件被链接到可执行文件conf中。
     例如: #scripts/kconfig/Makefile
[color="#000000"]             hostprogs-y      := conf
[color="#000000"]             conf-objs        := conf.o libkconfig.so
[color="#000000"]             libkconfig-objs := expr.o type.o
     共享库文件需要对应的-objs定义, 在上面例子中库libkconfig由两个对象组成：expr.o和type.o。expr.o和type.o将被编译为位置无关代码并被链接如libkconfig.so。共享库不支持C++语言。
C++语言使用方法
     内核编译系统提供了对C++主机程序的支持以用于内核配置，但不主张其它方面使用这种方法。
     例如: #scripts/kconfig/Makefile
[color="#000000"]             hostprogs-y      := qconf
[color="#000000"]             qconf-cxxobjs := qconf.o
     在上面例子中可执行文件由C++文件qconf.cc组成 - 通过$(qconf-cxxobjs)标识。如果qconf由.c和.cc文件混合组成，附加行表示这种情况。
     例如: #scripts/kconfig/Makefile
[color="#000000"]             hostprogs-y      := qconf
[color="#000000"]             qconf-cxxobjs := qconf.o
[color="#000000"]             qconf-objs      := check.o
辅助程序编译控制选项
     当编译主机程序时仍然可以使用$(HOSTCFLAGS)设置编译选项传递给$(HOSTCC)。这些选项将影响所有使用变量HOST_EXTRACFLAG的Makefile创建的主机程序。
     例如: #scripts/lxdialog/Makefile
[color="#000000"]             HOST_EXTRACFLAGS += -I/usr/include/ncurses
     为单个文件设置选项使用下面方式：
     例如: #arch/ppc64/boot/Makefile
[color="#000000"]             HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
     也可以使用附加链接选项：
      例如: #scripts/kconfig/Makefile
[color="#000000"]             HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
     当链接qconf时将使用外部选项"-L$(QTDIR)/lib"。
何时建立辅助程序
     只有当需要时内核编译系统才会编译主机程序。有两种方式：
     (1) 在特殊规则中作为隐式的前提需求
     例如: #drivers/pci/Makefile
[color="#000000"]             hostprogs-y := gen-devlist
[color="#000000"]             $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
[color="#000000"]             ( cd $(obj); ./gen-devlist ) [color="#000000"]             hostprogs-y      := lxdialog
[color="#000000"]             always        := $(hostprogs-y)
     这样就告诉内核编译系统即使没有任何规则使用lxdialog也要编译它。
使用hostprogs-$(CONFIG_FOO)
     在Kbuild文件中典型模式如下：
     例如: #scripts/Makefile
[color="#000000"]             hostprogs-$(CONFIG_KALLSYMS) += kallsyms
     对Kbuild来说'y'用于内嵌对象'm'用于模块。
     因此如果config符号是'm'，编译系统也将创建该程序。换句话说内核编译系统等同看待hostprogs-m和hostprogs-y。但如果不涉及到CONFIG符号仅建议使用hostprogs-y。
编译清除机制
--------------------------------------------
    "make clean"命令删除在编译内核生成的大部分文件，例如主机程序，列举在
$(hostprogs-y)、$(hostprogs-m)、$(always)、$(extra-y)和$(targets)中目标文件都将被删除。
代码目录数中的"*.[oas]"、"*.ko"文件和一些由编译系统产生的附加文件也将被删除。
     附加文件可以使用$(clean-files)进行定义。
     例如: #drivers/pci/Makefile
[color="#000000"]             clean-files := devlist.h classlist.h
     当执行"make clean"命令时， "devlist.h classlist.h"两个文件将被删除。内核编译系统默认这些文件与Makefile具有相同的相对路径，否则需要设置以'/'开头的绝对路径。
     删除整个目录使用以下方式：
     例如: #scripts/package/Makefile
[color="#000000"]             clean-dirs := $(objtree)/debian/
     这样就将删除包括子目录在内的整个debian目录。如果不使用以'/'开头的绝对路径内核编译系统见默认使用相对路径。
     通常内核编译系统根据"obj-* := dir/"进入子目录，但是在体系Makefile中需要显式使用如下方式：
     例如: #arch/i386/boot/Makefile
[color="#000000"]             subdir- := compressed/
     上面赋值语句指示编译系统执行"make clean"命令时进入compressed/目录。
     在编译最终的引导映像文件的Makefile中有一个可选的目标对象名称是archclean。
     例如: #arch/i386/Makefile
[color="#000000"]             archclean:
[color="#000000"]             $(Q)$(MAKE) $(clean)=arch/i386/boot
     当执行"make clean"时编译器进入arch/i386/boot并象通常一样工作。arch/i386/boot中的Makefile文件可以使用subdir-标识进入更下层的目录。
      注意1: arch/$(ARCH)/Makefile不能使用"subdir-"，因为它被包含在顶层Makefile文件中，在这个位置编译机制是不起作用的。
      注意2: 所有列举在core-y、libs-y、drivers-y和net-y中的目录将被"make clean"命令清除。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/33048/showart_2090262.html