translating makefile.txt in Linux source code

vincent-cws

                                                Linux Kernel Makefiles
This document describes the Linux kernel Makefiles.
=== Table of Contents
    === 1 Overview
    === 2 Who does what
    === 3 The kbuild files
       --- 3.1 Goal definitions
       --- 3.2 Built-in object goals - obj-y
       --- 3.3 Loadable module goals - obj-m
       --- 3.4 Objects which export symbols
       --- 3.5 Library file goals - lib-y
       --- 3.6 Descending down in directories
       --- 3.7 Compilation flags
       --- 3.8 Command line dependency
       --- 3.9 Dependency tracking
       --- 3.10 Special Rules
    === 4 Host Program support
       --- 4.1 Simple Host Program
       --- 4.2 Composite Host Programs
       --- 4.3 Defining shared libraries  
       --- 4.4 Using C++ for host programs
       --- 4.5 Controlling compiler options for host programs
       --- 4.6 When host programs are actually built
       --- 4.7 Using hostprogs-$(CONFIG_FOO)
    === 5 Kbuild clean infrastructure
    === 6 Architecture Makefiles
       --- 6.1 Set variables to tweak the build to the architecture
       --- 6.2 Add prerequisites to prepare:
       --- 6.3 List directories to visit when descending
       --- 6.4 Architecture specific boot images
       --- 6.5 Building non-kbuild targets
       --- 6.6 Commands useful for building a boot image
       --- 6.7 Custom kbuild commands
       --- 6.8 Preprocessing linker scripts
       --- 6.9 $(CC) support functions
    === 7 Kbuild Variables
    === 8 Makefile language
    === 9 Credits
    === 10 TODO
=== 1 Overview
The Makefiles have five parts:
    Makefile        the top Makefile.
    .config            the kernel configuration file.
    arch/$(ARCH)/Makefile    the arch Makefile.
    scripts/Makefile.*    common rules etc. for all kbuild Makefiles.
    kbuild Makefiles    there are about 500 of these.
The top Makefile reads the .config file, which comes from the kernel
configuration process.
The top Makefile is responsible for building two major products: vmlinux
(the resident kernel image) and modules (any module files).
It builds these goals by recursively descending into the subdirectories of
the kernel source tree.
The list of subdirectories which are visited depends upon the kernel
configuration. The top Makefile textually includes an arch Makefile
with the name arch/$(ARCH)/Makefile. The arch Makefile supplies
architecture-specific information to the top Makefile.
Each subdirectory has a kbuild Makefile which carries out the commands
passed down from above. The kbuild Makefile uses information from the
.config file to construct various file lists used by kbuild to build
any built-in or modular targets.
scripts/Makefile.* contains all the definitions/rules etc. that
are used to build the kernel based on the kbuild makefiles.
（译）
=== 1 概述
Makefiles 分为五部分：
    Makefile        顶层的Makefile.
    .config            内核配置文件.
    arch/$(ARCH)/Makefile    体系Makefile.
    scripts/Makefile.*    公共规则等等. 供给所有的kbuild Makefiles.
    kbuild Makefiles    大约有500这样的Makefiles.
顶层的Makefile读入.config文件，这文件来自内核配置处理。
顶层Makefile是负责建立两个主要的产物：vmlinux（常驻内核镜像）和模块 （任何模块文件）。
它建立这些目标通过递归向下的进入内核源码树的子目录来实现的。
这些子目录列表根据内核的配置来被访问。顶层Makefile原文地包含体系的Makefile
"arch/$(ARCH)/Makefile". 这个体系的Makefile 提供指定的体系信息给顶层的Makefile.
每个子目录都有一个kbuild Makefile 来执行从上层传递下来的命令。这些kbuild Makefile使用
来自.config文件的信息来构造各种文件列表，用来给kbuild建立各种build-in或模块目标。
scripts/Makefile.* 包含所有的定义/规则等等。用以基于kbuild Makefiles来建立内核。
   
=== 2 Who does what
People have four different relationships with the kernel Makefiles.
*Users* are people who build kernels.  These people type commands such as
"make menuconfig" or "make".  They usually do not read or edit
any kernel Makefiles (or any other source files).
*Normal developers* are people who work on features such as device
drivers, file systems, and network protocols.  These people need to
maintain the kbuild Makefiles for the subsystem that they are
working on.  In order to do this effectively, they need some overall
knowledge about the kernel Makefiles, plus detailed knowledge about the
public interface for kbuild.
*Arch developers* are people who work on an entire architecture, such
as sparc or ia64.  Arch developers need to know about the arch Makefile
as well as kbuild Makefiles.
*Kbuild developers* are people who work on the kernel build system itself.
These people need to know about all aspects of the kernel Makefiles.
This document is aimed towards normal developers and arch developers.
（译）
=== 2 人们与Makefile。
人们与kernel Makefiles的之间分为4种不同的关系。
*用户* 是一类建立内核的人们。 这些人只是敲命令例如"make menuconfig" 或者 "make".
他们通常不需要阅读或者编辑任何内核Makefiles（或者任何其他的源文件）。
*普通的开发者* 是一类工作在例如设备驱动，文件系统和网络协议的人们。这些人需要
维护他们工作的子系统的kbuild Makefiles。为了使到这些更高效，他们需要一些全面
的知识关于内核Makefiles, 和详细的知识关于kbuild公共接口。
*体系开发者* 是一类工作在整个体系的人们，例如 sparc或者ia64的。体系开发者既需要
理解体系Makefile，也需要理解kbuild Makefiles.
*kbuild开发者* 是一类工作在建立内核build系统的人们。这些人们需要理解内核Makefiles
的各个方面知识。
这个文档是面向普通的开发人员和体系开发者。
=== 3 The kbuild files
Most Makefiles within the kernel are kbuild Makefiles that use the
kbuild infrastructure. This chapter introduce the syntax used in the
kbuild makefiles.
The preferred name for the kbuild files is 'Kbuild' but 'Makefile' will
continue to be supported. All new developmen is expected to use the
Kbuild filename.
Section 3.1 "Goal definitions" is a quick intro, further chapters provide
more details, with real examples.
（译）
=== 3 kbuild文件
大部分处在内核中的Makefiles都是kbuild Makefiles, 用来kbuild的下部构造。这章介绍
kbuild makefiles用到的语法。
给kbuild files个更好的称呼是'Kbuild',而不是'Makefile',这会继续被使用。希望所有新
的开发者都去使用Kbuild这个名字。
3.1 节 “目标定义”是一个快速介绍，后面的章节提供更详细的信息和真实的例子。
--- 3.1 Goal definitions
    Goal definitions are the main part (heart) of the kbuild Makefile.
    These lines define the files to be built, any special compilation
    options, and any subdirectories to be entered recursively.
    The most simple kbuild makefile contains one line:
    Example:
        obj-y += foo.o
    This tell kbuild that there is one object in that directory named
    foo.o. foo.o will be built from foo.c or foo.S.
    If foo.o shall be built as a module, the variable obj-m is used.
    Therefore the following pattern is often used:
    Example:
        obj-$(CONFIG_FOO) += foo.o
    $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).
    If CONFIG_FOO is neither y nor m, then the file will not be compiled
    nor linked.
（译）
--- 3.1 目标定义
目标定义是kbuild Makefile主要（核心）部分。这些行定义了建立这些文件，任何特殊的
编译选项，和递归地进入任何子目录。
最简单的kbuild makefile包含一行：
例子：
obj-y += foo.o
这告诉kbuild在这个目录下有一个目标叫做foo.o. 这个foo.o将被建立通过foo.c或者foo.S.
如果foo.o应该被作为模块来建立，变量obj-m被使用。因此下面模式经常被使用：
例子：
obj-$(CONFIG_FOO) += foo.o
$(CONFIG_FOO) 评估为y（built-in）或者m（模块）。如果CONFIG_FOO既不是y也不是m，那么该文件
将会不被编译也不被链接。
--- 3.2 Built-in object goals - obj-y
    The kbuild Makefile specifies object files for vmlinux
    in the lists $(obj-y).  These lists depend on the kernel
    configuration.
    Kbuild compiles all the $(obj-y) files.  It then calls
    "$(LD) -r" to merge these files into one built-in.o file.
    built-in.o is later linked into vmlinux by the parent Makefile.
    The order of files in $(obj-y) is significant.  Duplicates in
    the lists are allowed: the first instance will be linked into
    built-in.o and succeeding instances will be ignored.
    Link order is significant, because certain functions
    (module_init() / __initcall) will be called during boot in the
    order they appear. So keep in mind that changing the link
    order may e.g.  change the order in which your SCSI
    controllers are detected, and thus you disks are renumbered.
    Example:
        #drivers/isdn/i4l/Makefile
        # Makefile for the kernel ISDN subsystem and device drivers.
        # Each configuration option enables a list of files.
        obj-$(CONFIG_ISDN)             += isdn.o
        obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
（译）
--- 3.2 Built-in object 目标 - obj-y
这个kbuild Makefile 在$(obj-y)列表里为vmlinux指定了object文件。这些列表在
内核配置的时候将被使用到。
Kbuild 编译所有的$(obj-y)文件。它然后调用"$(LD) -r" 去合并这些文件成一个built-in.o
文件。built-in.o将会被父目录的Makefile链接到vmlinux去。
在$(obj-y)列表里的文件顺序是非常重要的。在列表里重复出现是允许的：最前面的实例将被
链接到built-in.o, 而后面同名的实例将会被忽略掉。
链接的顺序也是至关重要的，因为某些函数 （module_init()/ __initcall）将会在依赖他们
出现的顺序在boot的时候被调用。所以一定要记住改变链接顺序可能发生这样事情，例如：当你
改变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)             += isdn.o
        obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
--- 3.3 Loadable module goals - obj-m
    $(obj-m) specify object files which are built as loadable
    kernel modules.
    A module may be built from one source file or several source
    files. In the case of one source file, the kbuild makefile
    simply adds the file to $(obj-m).
    Example:
        #drivers/isdn/i4l/Makefile
        obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
    Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
    If a kernel module is built from several source files, you specify
    that you want to build a module in the same way as above.
    Kbuild needs to know which the parts that you want to build your
    module from, so you have to tell it by setting an
    $(-objs) variable.
    Example:
        #drivers/isdn/i4l/Makefile
        obj-$(CONFIG_ISDN) += isdn.o
        isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
    In this example, the module name will be isdn.o. Kbuild will
    compile the objects listed in $(isdn-objs) and then run
    "$(LD) -r" on the list of these files to generate isdn.o.
    Kbuild recognises objects used for composite objects by the suffix
    -objs, and the suffix -y. This allows the Makefiles to use
    the value of a CONFIG_ symbol to determine if an object is part
    of a composite object.
    Example:
        #fs/ext2/Makefile
            obj-$(CONFIG_EXT2_FS)        += ext2.o
         ext2-y                       := balloc.o bitmap.o
            ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
   
    In this example xattr.o is only part of the composite object
    ext2.o, if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
    Note: Of course, when you are building objects into the kernel,
    the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
    kbuild will build an ext2.o file for you out of the individual
    parts and then link this into built-in.o, as you would expect.
（译）
--- 3.3 可加载模块目标 - obj-m
$(obj-m) 指定的object文件，这些文件可以作为可加载的内核模块。
一个模块可能由一个源文件或几个源文件建立。在由一个源文件建立的情况，kbuild makefile
简单的添加文件到目标$(obj-m)。
    例子:
        #drivers/isdn/i4l/Makefile
        obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
注意：这个例子里的$(CONFIG_ISDN_PPP_BSDCOMP)被评估为'm'
如果内核模块由几个源文件建立的，你只需要使用上面相同方法指定它们到要建立的目标里。
Kbuild 需要知道从哪一部分你想建立你的模块，所以你必须通过$(-objs)变量来告诉它。
    例子:
        #drivers/isdn/i4l/Makefile
        obj-$(CONFIG_ISDN) += isdn.o
        isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
在这个例子里，模块名将是isdn.o。Kbuild将编译这些$(isdn-objs)里的objects， 然后运行"$(LD) -r"
通过这些列表文件来产生isdn.o。
Kbuild 通过后缀-objs和-y来识别objects构造objects，它允许Makefiles去使用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
在这个例子里xattr.o是组合目标ext2.o的一部分，紧且如果$(CONFIG_EXT2_FS_XATTR)被评估为'y'。
注意：当然，当你建立这些objects到内核，上面所说的语法同样能工作。所以，如果你的
CONFIG_EXT2_FS=y，Kbuild将为你建立ext2.o为独立的部分，然后链接它到built-in.o，如你所盼望的那样。
--- 3.4 Objects which export symbols
    No special notation is required in the makefiles for
    modules exporting symbols.
（译）
--- 3.4 导出Objects符号
没有特殊的标记法，在makefiles被请求模块导出符号的。
--- 3.5 Library file goals - lib-y
    Objects listed with obj-* are used for modules or
    combined in a built-in.o for that specific directory.
    There is also the possibility to list objects that will
    be included in a library, lib.a.
    All objects listed with lib-y are combined in a single
    library for that directory.
    Objects that are listed in obj-y and additional listed in
    lib-y will not be included in the library, since they will anyway
    be accessible.
    For consistency objects listed in lib-m will be included in lib.a.
    Note that the same kbuild makefile may list files to be built-in
    and to be part of a library. Therefore the same directory
    may contain both a built-in.o and a lib.a file.
    Example:
        #arch/i386/lib/Makefile
        lib-y    := checksum.o delay.o
    This will create a library lib.a based on checksum.o and delay.o.
    For kbuild to actually recognize that there is a lib.a being build
    the directory shall be listed in libs-y.
    See also "6.3 List directories to visit when descending".

    Usage of lib-y is normally restricted to lib/ and arch/*/lib.
（译）
--- 3.5 库文件目标 - lib-y
Objects以obj-*列表的形式被模块使用，或者被联合到指定目录的build-in.o里。同样也有可能
去列表objects，这些object被包含到一个库，lib.a。
所有objects以lib-y列表的形式被合并成一个简单的库供给这个目录。
在obj-y里面的排列的Objects和在lib-y里的附加列表将不会被包含进库里，因为它们将经常的
被访问到。
为了使到objects列表一致性，被包含到lib-m里的同时也会被包含进lib.a中。
注意同样的kbuild makefile 可能列表文件为built-in形式和库的一部分。因此同一个目录下可能
同时包含built-in.o和lib.a文件。
    例子:
        #arch/i386/lib/Makefile
        lib-y    := checksum.o delay.o
这将基于checksum.o和delay.o创建一个库lib.a。为了kbuild去真实的明白到有这样一个lib.a库来建立
这个目录，这个目录的包含信息应该在lib-y里被列出来。
同样参见 "6.3 List directories to visit when descending".
lib-y的用法被普遍的限制到lib/和arch/*/lib里。
--- 3.6 Descending down in directories
    A Makefile is only responsible for building objects in its own
    directory. Files in subdirectories should be taken care of by
    Makefiles in these subdirs. The build system will automatically
    invoke make recursively in subdirectories, provided you let it know of
    them.
    To do so obj-y and obj-m are used.
    ext2 lives in a separate directory, and the Makefile present in fs/
    tells kbuild to descend down using the following assignment.
    Example:
        #fs/Makefile
        obj-$(CONFIG_EXT2_FS) += ext2/
    If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular)
    the corresponding obj- variable will be set, and kbuild will descend
    down in the ext2 directory.
    Kbuild only uses this information to decide that it needs to visit
    the directory, it is the Makefile in the subdirectory that
    specifies what is modules and what is built-in.
    It is good practice to use a CONFIG_ variable when assigning directory
    names. This allows kbuild to totally skip the directory if the
    corresponding CONFIG_ option is neither 'y' nor 'm'.
（译）
--- 3.6 下降到子目录
一个Makefile只是负责建立它自己目录下的objects。子目录下的文件因该有这些子目录下的
makefiles来处理。build系统将在子目录里自动的递归调用，你应该提供足够信息给它去处理。
To do so obj-y and obj-m are used.
ext2处在一个独立的目录里，在fs/里的Makefile会告诉kbuild去下降处理下面的赋值。
    例子:
        #fs/Makefile
        obj-$(CONFIG_EXT2_FS) += ext2/
如果CONFIG_EXT2_FS被赋值为'y' (built-in) 或者 'm' (模块)，那么相应的obj-变量将会被赋值，
kbuild将下降到ext2目录。
Kbuild仅仅使用这些信息去决定它需要去访问这个目录，在这个子目录里的Makefile指示那些是模块
和那些是built-in。
这是一个很好的实例去使用CONFIG_变量，这个变量被赋值目录名。这样允许kbuild去全部跳过那些
CONFIG_选项既不是'y'又不是'm'的目录。
--- 3.7 Compilation flags
    EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS
    All the EXTRA_ variables apply only to the kbuild makefile
    where they are assigned. The EXTRA_ variables apply to all
    commands executed in the kbuild makefile.
    $(EXTRA_CFLAGS) specifies options for compiling C files with
    $(CC).
    Example:
        # drivers/sound/emu10k1/Makefile
        EXTRA_CFLAGS += -I$(obj)
        ifdef DEBUG
            EXTRA_CFLAGS += -DEMU10K1_DEBUG
        endif
    This variable is necessary because the top Makefile owns the
    variable $(CFLAGS) and uses it for compilation flags for the
    entire tree.
    $(EXTRA_AFLAGS) is a similar string for per-directory options
    when compiling assembly language source.
    Example:
        #arch/x86_64/kernel/Makefile
        EXTRA_AFLAGS := -traditional
    $(EXTRA_LDFLAGS) and $(EXTRA_ARFLAGS) are similar strings for
    per-directory options to $(LD) and $(AR).
    Example:
        #arch/m68k/fpsp040/Makefile
        EXTRA_LDFLAGS := -x
    CFLAGS_$@, AFLAGS_$@
    CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
    kbuild makefile.
    $(CFLAGS_$@) specifies per-file options for $(CC).  The $@
    part has a literal value which specifies the file that it is for.
    Example:
        # drivers/scsi/Makefile
        CFLAGS_aha152x.o =   -DAHA152X_STAT -DAUTOCONF
        CFLAGS_gdth.o    = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
                     -DGDTH_STATISTICS
        CFLAGS_seagate.o =   -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
    These three lines specify compilation flags for aha152x.o,
    gdth.o, and seagate.o
    $(AFLAGS_$@) is a similar feature for source files in assembly
    languages.
    Example:
        # arch/arm/kernel/Makefile
        AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
        AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
（译）
--- 3.7 编译标记
EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS
所有的EXTRA_变量被使用，仅且仅当在这些kbuild makefile中它们被赋值。EXTRA_变量
被应用到所有在kbuild 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
--- 3.9 Dependency tracking
    Kbuild tracks dependencies on the following:
    1) All prerequisite files (both *.c and *.h)
    2) CONFIG_ options used in all prerequisite files
    3) Command-line used to compile target
    Thus, if you change an option to $(CC) all affected files will
    be re-compiled.
（译）
--- 3.9 依赖跟踪
Kbuild跟踪依赖性如下所示：
1）所有的依赖文件（*.c和*.h)
2）CONFIG_选项被应用到所有的依赖文件中。
3）命令行常用来编译目标。
因此，如果你改变了$(CC)选项，那么所有受影响的文件将被重编。
--- 3.10 Special Rules
    Special rules are used when the kbuild infrastructure does
    not provide the required support. A typical example is
    header files generated during the build process.
    Another example is the architecture specific Makefiles which
    needs special rules to prepare boot images etc.
    Special rules are written as normal Make rules.
    Kbuild is not executing in the directory where the Makefile is
    located, so all special rules shall provide a relative
    path to prerequisite files and target files.
    Two variables are used when defining special rules:
    $(src)
    $(src) is a relative path which points to the directory
    where the Makefile is located. Always use $(src) when
    referring to files located in the src tree.
    $(obj)
    $(obj) is a relative path which points to the directory
    where the target is saved. Always use $(obj) when
    referring to generated files.
    Example:
        #drivers/scsi/Makefile
        $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
            $(CPP) -DCHIP=810 - -objs) list all objects used to link the final
    executable.
    Example:
        #scripts/lxdialog/Makefile
        hostprogs-y   := lxdialog  
        lxdialog-objs := checklist.o lxdialog.o
    Objects with extension .o are compiled from the corresponding .c
    files. In the above example checklist.c is compiled to checklist.o
    and lxdialog.c is compiled to lxdialog.o.
    Finally the two .o files are linked to the executable, lxdialog.
    Note: The syntax -y is not permitted for host-programs.
（译）
--- 4.2 构造主机程序
主机程序能够由基于混合objects组成。这些语法常用来为主机程序定义混合objects，类似于语法
被用来定义内核objects的用法。
$(-objs) 列出的所有objects是常用来链接成最终的可执行程序。
    例子:
        #scripts/lxdialog/Makefile
        hostprogs-y   := lxdialog  
        lxdialog-objs := checklist.o lxdialog.o
带有扩展名.o的Objects由相应的.c文件来编译。在上面的例子checklist.c被编译成checklist.o和
lxdialog.c被编译成lxdialog.o。
最后这两个.o文件都被链接成可执行文件lxdialog。
注意：语法 -y 是在主机程序里不允许的。
   
--- 4.3 Defining shared libraries  
  
    Objects with extension .so are considered shared libraries, and
    will be compiled as position independent objects.
    Kbuild provides support for shared libraries, but the usage
    shall be restricted.
    In the following example the libkconfig.so shared library is used
    to link the executable conf.
    Example:
        #scripts/kconfig/Makefile
        hostprogs-y     := conf
        conf-objs       := conf.o libkconfig.so
        libkconfig-objs := expr.o type.o
  
    Shared libraries always require a corresponding -objs line, and
    in the example above the shared library libkconfig is composed by
    the two objects expr.o and type.o.
    expr.o and type.o will be built as position independent code and
    linked as a shared library libkconfig.so. C++ is not supported for
    shared libraries.
（译）
--- 4.3 定义共享库
带有扩展名为.so的Objects被认为是共享库，将被编译为独立的objects。Kbuild提供支持共享库，
不过用法应该被限制。
在下面的例子，libkconfig.so共享库被链接为可执行文件conf。
    例子:
        #scripts/kconfig/Makefile
        hostprogs-y     := conf
        conf-objs       := conf.o libkconfig.so
        libkconfig-objs := expr.o type.o
共享库总是需要一个相应的-objs行，在例子里上面的共享库libkconfig由两个objects expr.o和type.o组成。
expr.o和type.o将被建立为以位置独立的代码和被链接成共享库libkconfig.so。C++不被共享库所支持。
--- 4.4 Using C++ for host programs
    kbuild offers support for host programs written in C++. This was
    introduced solely to support kconfig, and is not recommended
    for general use.
    Example:
        #scripts/kconfig/Makefile
        hostprogs-y   := qconf
        qconf-cxxobjs := qconf.o
    In the example above the executable is composed of the C++ file
    qconf.cc - identified by $(qconf-cxxobjs).
   
    If qconf is composed by a mixture of .c and .cc files, then an
    additional line can be used to identify this.
    Example:
        #scripts/kconfig/Makefile
        hostprogs-y   := qconf
        qconf-cxxobjs := qconf.o
        qconf-objs    := check.o
（译）
--- 4.4 在主机程序里使用C++
kbuild提供在主机上使用C++编程的支持。这将被独立的介绍去支持kconfig，但不推荐一般的使用。
    例子:
        #scripts/kconfig/Makefile
        hostprogs-y   := qconf
        qconf-cxxobjs := qconf.o
上面例子里的可执行文件由C++文件qconf.cc来构成 - 通过$(qconf-cxxobjs)被鉴别。
如果qconf由混合的.c和.cc文件构成，那么附加一行能被用来鉴别这个。
    例子:
        #scripts/kconfig/Makefile
        hostprogs-y   := qconf
        qconf-cxxobjs := qconf.o
        qconf-objs    := check.o
   
--- 4.5 Controlling compiler options for host programs
    When compiling host programs, it is possible to set specific flags.
    The programs will always be compiled utilising $(HOSTCC) passed
    the options specified in $(HOSTCFLAGS).
    To set flags that will take effect for all host programs created
    in that Makefile use the variable HOST_EXTRACFLAGS.
    Example:
        #scripts/lxdialog/Makefile
        HOST_EXTRACFLAGS += -I/usr/include/ncurses
  
    To set specific flags for a single file the following construction
    is used:
    Example:
        #arch/ppc64/boot/Makefile
        HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
  
    It is also possible to specify additional options to the linker.
  
    Example:
        #scripts/kconfig/Makefile
        HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
    When linking qconf it will be passed the extra option "-L$(QTDIR)/lib".
（译）
--- 4.5 为主机程序控制编译器选项
当编译主机程序时，很可能要设定指定的标志。程序将总是使用$(HOSTCC)来编译，$(HOSTCC)被传递
的选项在$(HOSTCFLAGS)里被指定。
去设置标志将影响所有的主机程序，这些程序在Makefile里使用变量HOST_EXTRACFLAGS被创建。
    例子:
        #scripts/lxdialog/Makefile
        HOST_EXTRACFLAGS += -I/usr/include/ncurses
为一个简单的文件设置指定的标志，下面的构造被使用：
    例子:
        #arch/ppc64/boot/Makefile
        HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
它同样可能给连接器指定附加的选项。
    例子:
        #scripts/kconfig/Makefile
        HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
当链接qconf时，它将被传递额外的选项 "-L$(QTDIR)/lib"。

--- 4.6 When host programs are actually built
    Kbuild will only build host-programs when they are referenced
    as a prerequisite.
    This is possible in two ways:
    (1) List the prerequisite explicitly in a special rule.
    Example:
        #drivers/pci/Makefile
        hostprogs-y := gen-devlist
        $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
            ( cd $(obj); ./gen-devlist )  produced .config
2) Store kernel version in include/linux/version.h
3) Symlink include/asm to include/asm-$(ARCH)
4) Updating all other prerequisites to the target prepare:
   - Additional prerequisites are specified in arch/$(ARCH)/Makefile
5) Recursively descend down in all directories listed in
   init-* core* drivers-* net-* libs-* and build all targets.
   - The value of the above variables are extended in arch/$(ARCH)/Makefile.
6) All object files are then linked and the resulting file vmlinux is
   located at the root of the src tree.
   The very first objects linked are listed in head-y, assigned by
   arch/$(ARCH)/Makefile.
7) Finally the architecture specific part does any required post processing
   and builds the final bootimage.
   - This includes building boot records
   - Preparing initrd images and the like
（译）
=== 6 体系 Makefiles
顶层的Makefile在开始下降进入个别目录之前设置环境和做好一切的准备工作。
顶层Makefile包含通用的部分，然而arch/$(ARCH)/Makefile包含所需求的设置kbuild
为所说的体系。
去完成这样的arch/$(ARCH)/Makefile,设置大量变量和定义一些目标。
kbuild依次地执行下面步骤（粗略地）：
1）配置内核 => 产生.config文件
2）存储内核版本到include/linux/version.h。
3）建立符号链接 include/asm 链接到 include/asm-$(ARCH)
4）更新目标所有其他依赖准备：
   -- 附加的依赖在arch/$(ARCH)/Makefile里被指定。
5）递归下降到所有的目录，这些目录被列表在init-* core* drivers-* net-* libs-*，
   里面， 和建立所有的目标。
6) 所有的object文件都然后被链接和结果文件vmlinux被放置在源码树的根目录里。
   在head-y列表里的最先的objects在arch/$(ARCH)/Makefile里被赋值。
7) 最后，这个体系指定部分完成所有需要的后置处理和建立最终的bootimage。
   - 这包括建立boot记录
   - 准备initrd 镜像和the like
               
               
               
               
               
               

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