轉載自:http://www.cnblogs.com/jason-lu/p/3728198.htmlhtml
--譯自Linux3.9.5 Kernel Makefiles(內核目錄documention/kbuild/makefiles.txt)node
kbuild(kernel build)linux
內核編譯器ios
This document describes the Linux kernel Makefilesgit
本文當介紹了Linux內核的Makefile算法
=== Table of Contents
=== 目錄shell
=== 1 Overviewexpress
=== 1 概述bootstrap
=== 2 Who does what網絡
=== 2 角色分工
=== 3 The kbuild files
=== 3 內核編譯文件
--- 3.1 Goal definitions
--- 3.1 目標定義
--- 3.2 Built-in object goals - obj-y
--- 3.2 內嵌對象 - obj-y
--- 3.3 Loadable module goals - obj-m
--- 3.3 可加載模塊 - obj-m
--- 3.4 Objects which export symbols
--- 3.4 導出符號
--- 3.5 Library file goals - lib-y
--- 3.5 庫文件 - lib-y
--- 3.6 Descending down in directories
--- 3.6 目錄遞歸
--- 3.7 Compilation flags
--- 3.7 編譯標記
--- 3.8 Command line dependency
--- 3.8 命令依賴
--- 3.9 Dependency tracking
--- 3.9 依賴關係
--- 3.10 Special Rules
--- 3.10 特殊規則
--- 3.11 $(CC) support functions
--- 3.11 $(CC) 支持的函數
--- 3.12 $(LD) support functions
--- 3.12 $(LD) 支持的函數
=== 4 Host Program support
=== 4 輔助程序
--- 4.1 Simple Host Program
--- 4.1 簡單輔助程序
--- 4.2 Composite Host Programs
--- 4.2 組合輔助程序
--- 4.3 Defining shared libraries
--- 4.3 定義共享庫
--- 4.4 Using C++ for host programs
--- 4.4 C++語言編寫的輔助程序使用方法
--- 4.5 Controlling compiler options for host programs
--- 4.5 輔助程序編譯控制選項
--- 4.6 When host programs are actually built
--- 4.6 什麼時候創建輔助程序
--- 4.7 Using hostprogs-$(CONFIG_FOO)
--- 4.7 使用hostprogs-$(CONFIG_FOO)
=== 5 Kbuild clean infrastructure
=== 5 編譯清除機制
=== 6 Architecture Makefiles
=== 6 架構Makefile文件
--- 6.1 Set variables to tweak the build to the architecture
--- 6.1 設置變量調整構建的體系結構
--- 6.2 Add prerequisites to archheaders:
--- 6.2 增長預設置項到archheaders中
--- 6.3 Add prerequisites to archprepare:
--- 6.3 增長預設置項到archprepare中
--- 6.4 List directories to visit when descending
--- 6.4 遞歸向下訪問的目錄列表
--- 6.5 Architecture-specific boot images
--- 6.5 具體架構的引導映像
--- 6.6 Building non-kbuild targets
--- 6.6 編譯非內核目標
--- 6.7 Commands useful for building a boot image
--- 6.7 構建引導映像的命令
--- 6.8 Custom kbuild commands
--- 6.8 自定義內核編譯命令
--- 6.9 Preprocessing linker scripts
--- 6.9 預處理鏈接腳本
--- 6.10 Generic header files
--- 6.10 通用頭文件
=== 7 Kbuild syntax for exported headers
=== 7 導出頭文件的Kbuild語法
--- 7.1 header-y
--- 7.2 genhdr-y
--- 7.3 destination-y
--- 7.4 generic-y
=== 8 Kbuild Variables
=== 8 Kbuild變量
=== 9 Makefile language
=== 9 Makefile語言
=== 10 Credits
=== 11 TODO
=== Contents
=== 正文
=== 1 Overview
=== 1 概述
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.
Makefile包括五部分:
Makefile 頂層Makefile文件
.config 內核配置文件
arch/$(ARCH)/Makefile 機器體系結構相關Makefile文件
scripts/Makefile.* 全部內核Makefiles共用規則
kbuild Makefiles 其它makefile文件
The top Makefile reads the .config file, which comes from the kernel configuration process.
經過內核配置操做產生.config文件,頂層Makefile文件讀取該文件的配置.
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.
頂層Makefile文件負責產生兩個主要的程序:vmlinux (內核image)和模塊.頂層Makefile文件根據內核配置,經過遞歸編譯內核代碼樹子目錄創建這兩個文件.頂層Makefile文件裏包含一個名爲 arch/$(ARCH)/Makefile的架構makefile文件.架構Makefile文件爲頂層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.
每個子目錄有一個makefile文件,子目錄makefile文件根據上級目錄makefile文件命令啓動編譯.這些makefile使用.config文件配置數據構建各類文件列表,並使用這些文件列表編譯內嵌或模塊目標文件.scripts/Makefile.*包含了全部的定義和規則,與makefile文件一塊兒編譯出內核程序.
=== 2 Who does what
=== 2 角色分工
People have four different relationships with the kernel Makefiles.
用戶與內核makefile存在四種不一樣的關係:
*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).
*用戶* 用戶使用"make menuconfig"或"make"命令編譯內核.他們一般不讀或編輯內核makefile文件或其餘源文件.
*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 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.
*普通開發者* 普通開發者維護設備驅動程序、文件系統和網絡協議代碼,他們維護相關子系統的makefile文件,所以他們須要內核makefile文件總體性的通常知識和關於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.
*體系開發者* 體系開發者關注一個總體的體系架構,好比sparc或者ia64.體系開發者既須要掌握關於體系的makefile文件,也要熟悉內核makefile文件.
*Kbuild developers* are people who work on the kernel build system itself. These people need to know about all aspects of the kernel Makefiles.
*內核開發者* 內核開發者關注內核編譯系統自己.他們須要清楚內核makefile文件的全部方面.
This document is aimed towards normal developers and arch developers.
本文檔的讀者對象是普通開發者和系統開發者.
=== 3 The kbuild files
=== 3 內核編譯文件
Most Makefiles within the kernel are kbuild Makefiles that use the kbuild infrastructure. This chapter introduces the syntax used in the
kbuild makefiles.
The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild' file will be used.
內核中大多數makefile文件是使用kbuild基礎架構的makefile文件.本章介紹 kbuild的makefile中的語法.
Kbuild文件傾向於"Makefile"這個名字,但使用"Kbuild"也能夠.若是"Makefile"和"Kbuild"同時出現的話,則使用"Kbuild"文件.
Section 3.1 "Goal definitions" is a quick intro, further chapters provide more details, with real examples.
3.1節」目標定義」是一個快速導引,後面各章有詳細介紹和實例.
--- 3.1 Goal definitions
--- 3.1 目標定義
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.
目標定義是makefile文件的主要部分(核心).這些目標定義行定義瞭如何編譯文件,特殊的兼容選項和遞歸子目錄.
The most simple kbuild makefile contains one line:
最簡單的makefile文件只包含一行:
例如: obj-y += foo.o
This tells 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:
這行告訴kbuild在該目錄下名爲foo.o的目標文件(object),foo.o經過編譯foo.c或者foo.S而獲得.若是foo.o編譯成一個模塊,則使用obj-m變量,所以常見寫法以下:
例如: 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.
$(CONFIG_FOO)能夠表明y(built-in對象)或m(module對象).
若是CONFIG_FOO不是y或m,那麼這個文件不會被編譯和連接.
--- 3.2 Built-in object goals - obj-y
--- 3.2 內嵌對象 - obj-y
The kbuild Makefile specifies object files for vmlinux in the $(obj-y) lists. These lists depend on the kernel configuration.
Kbuild Makefile規定全部編譯進vmlinux的目標文件都在$(obj-y)列表中,這些列表依賴於內核配置.
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.
Kbuild編譯全部的$(obj-y)文件,而後調用"$(LD) -r"合併這些文件到一個built-in.o文件中. built-in.o以後經過父makefile文件連接到vmlinux. $(obj-y)中的文件順序很重要.列表中文件容許重複,文件第一次出現將被連接到built-in.o,後續出現該文件將被忽略.
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 your 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_I4L) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
連接順序之因此重要是由於某些函數在內核引導時將按照他們出現的順序被調用,如函數(module_init() / __initcall).因此請記住改變連接順序的同時也可能會改變SCSI控制器的檢測次序,從而致使磁盤從新編號.
例如: #drivers/isdn/i4l/Makefile
# 內核ISDN子系統和設備驅動程序Makefile
# 每一個配置項都會使能一個文件列表
obj-$(CONFIG_ISDN) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
--- 3.3 Loadable module goals - obj-m
--- 3.3 可加載模塊 - obj-m
$(obj-m) specify object files which are built as loadable kernel modules.
$(obj-m)指定了那些能被編譯爲可加載的內核模塊的目標文件.
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).
一個模塊能夠從一個源文件或幾個源文件編譯而成.在一個源文件的狀況下, kbuild makefile只需簡單地它加到$(obj-m).
例如:#drivers/isdn/i4l/Makefile
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
注意:在這個例子中$(CONFIG_ISDN_PPP_BSDCOMP)含義是'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; however,
kbuild needs to know which object files you want to build your module from, so you have to tell it by setting a $(<module_name>-y)
variable.
若是內核模塊是經過幾個源文件編譯而成的,您可使用和上面一樣的方法指定您想要編譯的模塊.然而此時Kbuild須要知道編譯模塊時是基於那些目標文件的,所以您須要設置一個$(<module_name>-objs)變量來告訴編譯器.
例如:#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-y) and then run "$(LD) -r" on the list of these files to generate isdn.o.
Due to kbuild recognizing $(<module_name>-y) for composite objects, you can use the value of a CONFIG_ symbol to optionally include an object file as part of a composite object.
在這個例子中,模塊名isdn.o. Kbuild首先編譯$(isdn-objs)中的object文件,而後運行"$(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
In this example, xattr.o, xattr_user.o and xattr_trusted.o are only part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
evaluates to 'y'.
在這個例子中,若是$(CONFIG_EXT2_FS_XATTR)表示'y',則xattr.o xattr_user.o和xattr_trusted.o都將是複合對象ext2.o的一部分.
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.
注意: 固然,當你將編譯目標文件到內核時,以上語法一樣有效.所以,若是CONFIG_EXT2_FS=y,Kbuild將創建一個ext2.o來輸出各個部分,而後將其連接到 built-in.o中,正如您指望的那樣.
--- 3.4 Objects which export symbols
--- 3.4 導出符號
No special notation is required in the makefiles for modules exporting symbols.
在makefile文件中的模塊導出符號不須要特別的標記.
--- 3.5 Library file goals - lib-y
--- 3.5 庫文件 - 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.
對於指定的目錄, obj-*列表中的object文件編譯成模塊或複合進built-in.o. 也有可能指定這些目標文件到編譯到庫文件中--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 additionally listed in
lib-y will not be included in the library, since they will be accessible anyway. For consistency, objects listed in lib-m will be included in lib.a.
全部羅列在lib-y中的object文件都將編譯到該目錄下的一個單一的庫文件中.
包含在obj-y中的object文件若是也列舉在lib-y中將不會包含到庫文件中,由於他們不能被訪問.但lib-m中的object文件將被編譯進 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.
注意在相同的makefile中能夠列舉文件到buit-in內核中也能夠做爲庫文件的一個組成部分.所以在同一個目錄下既能夠有built-in.o也能夠有lib.a文件.
例如: #arch/x86/lib/Makefile
lib-y := delay.o
This will create a library lib.a based on delay.o. For kbuild to actually recognize that there is a lib.a being built, the directory shall be listed in libs-y.
See also "6.4 List directories to visit when descending". Use of lib-y is normally restricted to lib/ and arch/*/lib.
這樣將基於delay.o建立一個lib.a文件.爲了讓Kbuild意識到有一個lib.a被建立,其所在的目錄要加入到libs-y中.
參看」6.4遞歸向下訪問的目錄列表」.lib-y一般被限制使用在lib/和arch/*/lib目錄中.
--- 3.6 Descending down in directories
--- 3.6 目錄遞歸
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.
makefile文件負責編譯當前目錄下的目標文件,子目錄中的文件由子目錄中的makefile文件負責編譯.編譯系統將使用obj-y和obj-m自動遞歸編譯各個子目錄中文件.
若是ext2是一個子目錄,fs目錄下的makefile將使用如下賦值語句是編譯系統編譯ext2子目錄.
例如: #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.
若是將CONFIG_EXT2_FS設置成'y(built-in)或'm'(modular),則對應的obj-變量也要設置,內核編譯系統將進入ext2目錄編譯文件.
內核編譯系統只使用這些信息來決定是否須要編譯這個目錄,子目錄中makefile文件規定哪些文件編譯爲模塊,哪些是內核內嵌對象.
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'.
當指定目錄名時使用CONFIG_變量是一種比較好的作法.若是CONFIG_選項不爲'y'或'm',內核編譯系統就會跳過這個目錄.
--- 3.7 Compilation flags
--- 3.7 編譯標記
ccflags-y, asflags-y and ldflags-y
These three flags apply only to the kbuild makefile in which they are assigned. They are used for all the normal cc, as and ld
invocations happening during a recursive build.
ccflags-y, asflags-y and ldflags-y這三個標記只是用於定義它們的makefile中.在遞歸構建時它們被用在全部的正規cc/as/ld指令調用中.
Note: Flags with the same behaviour were previously named:
EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
They are still supported but their usage is deprecated.
ccflags-y specifies options for compiling with $(CC).
注意:以前的名爲EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS這些標記都具備相同的行爲它們的用法已通過時了,可是內核仍然支持它們.
ccflags-y指定了使用$(CC)編譯時的選項.
例如:# drivers/acpi/Makefile
ccflags-y := -Os
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
This variable is necessary because the top Makefile owns the variable $(KBUILD_CFLAGS) and uses it for compilation flags for the entire tree.
這個變量是必須的,由於頂層makefile定義了$(KBUILD_CFLAGS)變量並使用該變量編譯整個代碼樹.
asflags-y specifies options for assembling with $(AS).
ccflags-y指定了使用$(AS)彙編時的選項.
例如:#arch/sparc/kernel/Makefile
asflags-y := -ansi
ldflags-y specifies options for linking with $(LD).
ccflags-y指定了使用$(LD)連接時的選項.
例如: #arch/cris/boot/compressed/Makefile
ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
subdir-ccflags-y, subdir-asflags-y
The two flags listed above are similar to ccflags-y and asflags-y. The difference is that the subdir- variants have effect for the kbuild file where they are present and all subdirectories. Options specified using subdir-* are added to the commandline before the options specified using the non-subdir variants.
subdir-ccflags-y, subdir-asflags-y這兩個標記和ccflags-y, asflags-y很類似.不一樣的是subdir-變量對於有它們出現的kbuild文件和全部的子目錄都會有影響.使用subdir-*指定的選項將在使用non-subdir變量指定的選項以前被添加到命令行.
例如:
subdir-ccflags-y := -Werror
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CFLAGS_$@, AFLAGS_$@
CFLAGS_$@ and AFLAGS_$@ only apply to commands in current kbuild makefile.
CFLAGS_$@和AFLAGS_$@只使用到當前makefile文件的命令中.
$(CFLAGS_$@) specifies per-file options for $(CC). The $@ part has a literal value which specifies the file that it is for.
$(CFLAGS_$@)指定了每一個使用$(CC)文件的選項.$@部分有一個文本值,這個值指定了具體操做的文件.
例如: # drivers/scsi/Makefile
CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
-DGDTH_STATISTICS
These two lines specify compilation flags for aha152x.o and gdth.o.
這兩行定義了aha152x.o和gdth.o文件的編譯選項.
$(AFLAGS_$@) is a similar feature for source files in assembly languages.
$(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.8 Command line dependency
--- 3.8 命令依賴
--- 3.9 Dependency tracking
--- 3.9 依賴關係
Kbuild tracks dependencies on the following:
Kbuild記錄以下依賴關係:
1) All prerequisite files (both *.c and *.h)
1) 全部的前提文件(both *.c and *.h)
2) CONFIG_ options used in all prerequisite files
2) CONFIG_ 選項影響到的全部文件
3) Command-line used to compile target
3) 編譯目標文件使用的命令行
Thus, if you change an option to $(CC) all affected files will be re-compiled.
所以,假如改變$(CC)的一個選項,全部相關的文件都要從新編譯.
--- 3.10 Special Rules
--- 3.10 特殊規則
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 are the architecture-specific Makefiles which need special rules to prepare boot images etc. Special rules are written as normal Make rules.
當kbuild規則不能提供編譯所需的支持時就須要使用一些特殊規則了.一個典型的例子就是在編譯期間自動生成頭文件.
其餘例子有好比特定體系架構的makefile須要特殊規則來製做引導映像.特殊規則寫法同普通的Make規則.
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:
在Makefile所在的目錄中,Kbuild不能執行,所以全部的特殊規則須要提供必備文件和目標文件的相對路徑.定義特殊規則時將使用到兩個變量:
$(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.
$(src)指定Makefile文件所在的相對路徑,當使用代碼樹中的文件時使用該變量$(src).
$(obj)
$(obj) is a relative path which points to the directory where the target is saved. Always use $(obj) when referring to generated files.
$(obj)指定保存目標文件的相對路徑.生成文件使用$(obj)變量.
例如: #drivers/scsi/Makefile
$(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
$(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
This is a special rule, following the normal syntax required by make. The target file depends on two prerequisite files. References to the target file are prefixed with $(obj), references to prerequisites are referenced with $(src) (because they are not generated files).
這就特殊規則,其語法規則和make要求的普通語法同樣.目標文件依賴於兩個必備文件.引用目標文件的前綴是$(obj), 引用必備文件的前綴是$(src)(由於它們不是生成文件).
$(kecho)
echoing information to user in a rule is often a good practice but when execution "make -s" one does not expect to see any output except for warnings/errors.
在規則中打印提示信息給用戶一般是一個很好的作法,可是當執行」make -s」的時候人們將看不到任何信息,除了錯誤和警告信息以外.
To support this kbuild define $(kecho) which will echo out the text following $(kecho) to stdout except if "make -s" is used.
爲了支持該功能(打印提示信息),kbuild定義了$(kecho)來打印以下的文本信息,除非」make -s」被使用.
例如:#arch/blackfin/boot/Makefile
$(obj)/vmImage: $(obj)/vmlinux.gz
$(call if_changed,uimage)
@$(kecho) 'Kernel: $@ is ready'
--- 3.11 $(CC) support functions
--- 3.11 $(CC) 支持的函數
The kernel may be built with several different versions of $(CC), each supporting a unique set of features and options. kbuild provide basic support to check for valid options for $(CC). $(CC) is usually the gcc compiler, but other alternatives are available.
內核可能由一些不一樣版本的$(CC)編譯,每一個版本的編譯器都支持一些的功能與選項.Kbuild提供了一些基本支持,能夠來檢查 $(CC) 的選項是否有效.$(CC)通常狀況下是gcc編譯器,但也可使用其它編譯器來代替gcc.
as-option
as-option is used to check if $(CC) -- when used to compile assembler (*.S) files -- supports the given option. An optional second option may be specified if the first option is not supported.
as-option該函數使用在當使用$(CC)來編譯彙編文件(*.S)時,用來檢查$(CC)是否支持特定選項.若是第一個選項不支持的話,則能夠指定一個選項(第二個選項將被使用).
例如:#arch/sh/Makefile
cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
In the above example, cflags-y will be assigned the option -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC). The second argument is optional, and if supplied will be used if first argument is not supported.
在上面的例子中,若是$(CC)支持選項-Wa$(comma)-isa=$(isa-y),cflags-y標記選項列表中就會加上該值.第二個參數是可選的,當第一個參數不支持時,就會使用該值.
cc-ldoption
cc-ldoption is used to check if $(CC) when used to link object files supports the given option. An optional second option may be specified if first option are not supported.
cc-ldoption函數用來檢查當聯接目標文件時使用的$(CC)是否支持特定選項.若是第一個選項不支持的話,則能夠指定一個選項(第二個選項將被使用).
例如:#arch/x86/kernel/Makefile
vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
In the above example, vsyscall-flags will be assigned the option -Wl$(comma)--hash-style=sysv if it is supported by $(CC).The second argument is optional, and if supplied will be used if first argument is not supported.
在上面的例子中,若是$(CC)支持選項-Wl$(comma)--hash-style=sysv, vsyscall-flags標記選項列表中就會加上該值.第二個參數是可選的,當第一個參數不支持時,就會使用該值.
as-instr checks if the assembler reports a specific instruction and then outputs either option1 or option2 C escapes are supported in the test instruction
as-instr函數用來檢測在測試指令中彙編器是否支持報告並輸出C轉義字符,不管是選項1仍是選項2.
Note: as-instr-option uses KBUILD_AFLAGS for $(AS) options
注意: as-instr-option在$(AS)選項中使用KBUILD_AFLAGS變量.
cc-option
cc-option is used to check if $(CC) supports a given option, and not supported to use an optional second option.
cc-option函數用來檢查$(CC)是否支持特定選項,而且不支持使用可選的第二項.
例如:#arch/x86/Makefile
cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
In the above example, cflags-y will be assigned the option -march=pentium-mmx if supported by $(CC), otherwise -march=i586. The second argument to cc-option is optional, and if omitted, cflags-y will be assigned no value if first option is not supported.
在上面的例子中,若是$(CC)支持選項-march=pentium-mmx,cc-option標記選項列表中就會加上該值,不然就使用-march=i586. cc-option的第二個參數是可選的,若是省略,當第一個選項不支持時cflags-y不會被賦值.
Note: cc-option uses KBUILD_CFLAGS for $(CC) options
注意:cc-option在$(CC)選項中使用KBUILD_CFLAGS變量.
cc-option-yn
cc-option-yn is used to check if gcc supports a given option and return 'y' if supported, otherwise 'n'.
cc-option-yn函數用來檢查gcc是否支持特定選項,若是支持則返回'y',不然爲'n'.
例如:#arch/ppc/Makefile
biarch := $(call cc-option-yn, -m32)
aflags-$(biarch) += -a32
cflags-$(biarch) += -m32
In the above example, $(biarch) is set to y if $(CC) supports the -m32 option. When $(biarch) equals 'y', the expanded variables $(aflags-y) and $(cflags-y) will be assigned the values -a32 and -m32, respectively.
Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
在上面的例子中,若是$(CC)支持-m32選項時,$(biarch)會被設置爲y.當$(biarch)爲y時,擴展的$(aflags-y)和$(cflags-y)變量就會分別被賦值爲-a32和-m32.
注意: cc-option-yn在$(CC)選項中使用KBUILD_CFLAGS
gcc versions >= 3.0 changed the type of options used to specify alignment of functions, loops etc. $(cc-option-align), when used as prefix to the align options, will select the right prefix:
大於3.0版本的gcc編譯器,改變了對函數/循環中用於指定內存對齊的選項類型. $(cc-option-align)就做爲對齊選項的前綴出現,當用到對齊選項時,$(cc-option-align)用來選擇正確的前綴:
gcc < 3.00
cc-option-align = -malign
gcc >= 3.00
cc-option-align = -falign
例如:KBUILD_CFLAGS += $(cc-option-align)-functions=4
In the above example, the option -falign-functions=4 is used for gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
在上面的例子中,選項-falign-funcions=4被用在gcc >= 3.00的時候,對於小於3.00時,使用 -malign-funcions=4.
Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options
注意: cc-option-align在$(CC)選項中使用KBUILD_CFLAGS
cc-disable-warning checks if gcc supports a given warning and returns the commandline switch to disable it. This special function is needed, because gcc 4.4 and later accept any unknown -Wno-* option and only warn about it if there is another warning in the source file.
cc-disable-warning函數檢測gcc是否支持一個給定的警告而且返回命令行改觀去禁用該選項.這個特殊的函數也是須要的,由於gcc4.4和以後更高的版本都接受任何未知的以-Wno*標識的選項,而且發出警告,若是在源文件中有其餘警告的話.
例如: KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
In the above example, -Wno-unused-but-set-variable will be added to KBUILD_CFLAGS only if gcc really accepts it.
在上面的例子中,只有在gcc真正接受unused-but-set-variable的時候, -Wno-unused-but-set-variable變量才被加入到KBUILD_CFLAGS編譯列表中去.
cc-version
cc-version returns a numerical version of the $(CC) compiler version. The format is <major><minor> where both are two digits. So for example gcc 3.41 would return 0341. cc-version is useful when a specific $(CC) version is faulty in one area, for example -mregparm=3 was broken in some gcc versions even though the option was accepted by gcc.
cc-version以數學形式返回$(CC)編譯器的版本號.其格式是:<major><minor>,兩者都是數學.好比,gcc 3.41會返回0341.當某版本的$(CC)在某方面有缺陷時,cc-version就會頗有用.好比,選項
-mregparm=3雖然會被gcc接受,但其實現是有問題的.
例如: #arch/x86/Makefile
cflags-y += $(shell \
if [ $(call cc-version) -ge 0300 ] ; then \
echo "-mregparm=3"; fi ;)
In the above example, -mregparm=3 is only used for gcc version greater than or equal to gcc 3.0.
在上面的例子中,-mregparm=3只會在gcc的版本大於等於3.0的時候使用.
cc-ifversion
cc-ifversion tests the version of $(CC) and equals last argument if version expression is true.
cc-ifversion測試$(CC)的版本號,若是版本表達式爲真,就賦值爲最後的參數.
例如:#fs/reiserfs/Makefile
ccflags-y := $(call cc-ifversion, -lt, 0402, -O1)
In this example, ccflags-y will be assigned the value -O1 if the $(CC) version is less than 4.2. cc-ifversion takes all the shell operators:
-eq, -ne, -lt, -le, -gt, and –ge The third parameter may be a text as in this example, but it may also be an expanded variable or a macro.
在這個例子中,若是$(CC)的版本小於4.2, ccflags-y就被賦值-O1. cc-ifversion可以使用全部的shell操做符:-eq,-ne,-lt,-le,-gt,和-ge.第三個參數能夠像上面例子同樣是個文本,也能夠是個擴展的變量或宏.
cc-fullversion
cc-fullversion is useful when the exact version of gcc is needed.One typical use-case is when a specific GCC version is broken. cc-fullversion points out a more specific version than cc-version does.
當須要精確的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
In this example for a specific GCC version the build will error out explaining to the user why it stops.
在這個使用特定版本GCC編譯的時候會產生錯誤,並向用戶解釋了爲什麼會中止.
cc-cross-prefix is used to check if there exists a $(CC) in path with one of the listed prefixes. The first prefix where there exist a prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found then nothing is returned.
cc-cross-prefix函數用來檢測指定目錄中是否存在$(CC)使用前綴列表之一.若存在則返回第一個prefix$(CC)這樣的前綴,不然什麼也不返回.
Additional prefixes are separated by a single space in the call of cc-cross-prefix.
附加前綴經過在調用cc-cross-prefix的時候分離一個空格獲得.
This functionality is useful for architecture Makefiles that try to set CROSS_COMPILE to well-known values but may have several values to select between.
這個函數是頗有用的,在架構相關makefile中會試着設置CROSS_COMPILE爲一個衆所周知的值,但通常會有好幾個值供選擇.
It is recommended only to try to set CROSS_COMPILE if it is a cross build (host arch is different from target arch). And if CROSS_COMPILE
is already set then leave it with the old value.
所以建議只有在交叉編譯(主機和目標機不一樣的架構)的時候再去設置CROSS_COMPILE.若是CROSS_COMPILE已經被設置好了,那就保留它吧.
例如: #arch/m68k/Makefile
ifneq ($(SUBARCH),$(ARCH))
ifeq ($(CROSS_COMPILE),)
CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
endif
endif
--- 3.12 $(LD) support functions
--- 3.12 $(LD) 支持的函數
ld-option is used to check if $(LD) supports the supplied option. ld-option takes two options as arguments.The second argument is an optional option that can be used if the first option is not supported by $(LD).
ld-option函數是用來檢查$(LD)是否支持提供的選項. ld-option函數有有兩個選項做爲參數.第二個參數是一個可選項,當第一個選項不被$(LD)支持時就使用它.
例如:#Makefile
LDFLAGS_vmlinux += $(call really-ld-option, -X)
=== 4 Host Program support
=== 4 輔助程序
Kbuild supports building executables on the host for use during the compilation stage.Two steps are required in order to use a host executable.
內核編譯系統支持在編譯(compliation)階段編譯主機可執行程序.爲了使用主機程序須要兩個步驟.
The first step is to tell kbuild that a host program exists. This is done utilising the variable hostprogs-y.
第一個步驟使用hostprogs-y變量告訴內核編譯系統有主機程序可用.
The second step is to add an explicit dependency to the executable.
This can be done in two ways. Either add the dependency in a rule,or utilise the variable $(always).
第二步給主機程序添加潛在的依賴關係.有兩種方法能夠作到,在規則中增長依賴關係,或使用$(always)變量.
Both possibilities are described in the following.
具體描述以下.
--- 4.1 Simple Host Program
--- 4.1 簡單輔助程序
In some cases there is a need to compile and run a program on the computer where the build is running.
The following line tells kbuild that the program bin2hex shall be built on the build host.
在某些狀況下,當編譯正在運行時,須要在主機上編譯和運行主機程序.下面這行告訴kbuild應該在主機上創建bin2hex程序.
例如:hostprogs-y := bin2hex
Kbuild assumes in the above example that bin2hex is made from a single c-source file named bin2hex.c located in the same directory as
the Makefile.
上例中,Kbuild假定bin2hex程序是使用makefile相同目錄下的單一C代碼文件bin2hex.c編譯出來的.
--- 4.2 Composite Host Programs
--- 4.2 組合輔助程序
Host programs can be made up based on composite objects. The syntax used to define composite objects for host programs is similar to the syntax used for kernel objects. $(<executable>-objs) lists all objects used to link the final executable.
主機程序也能夠由多個object文件組成.定義組合輔助程序的語法同內核對象的定義方法.
$(<executeable>-objs)包含了全部的用於連接最終可執行程序的對象.
例如: #scripts/lxdialog/Makefile
hostprogs-y := lxdialog
lxdialog-objs := checklist.o lxdialog.o
Objects with extension .o are compiled from the corresponding .cfiles. 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 <executable>-y is not permitted for host-programs.
擴展名.o的目標文件都是編譯自對應的.c文件得來的.在上面的例子中checklist.c編譯成checklist.o,lxdialog.c編譯爲 lxdialog.o.最後兩個.o文件連接成可執行文件lxdialog.
注意:語法<executable>-y不能用於定義主機程序.
--- 4.3 Defining shared libraries
--- 4.3 定義共享庫
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.
擴展名爲.so的對象是共享庫文件,這是位置無關的object文件.Kbuild對共享庫提供支持,但使用方法有限制.在下面例子中 libkconfig.so庫文件被連接到可執行文件conf中.
例如: #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.
共享庫文件須要對應的-objs定義,在上面例子中庫libkconfig由兩個對象組成:expr.o和type.o. expr.o和type.o將被編譯爲位置無關代碼並被連接爲共享庫 libkconfig.so. 共享庫不支持C++語言.
--- 4.4 Using C++ for host programs
--- 4.4 C++語言編寫的輔助程序使用方法
kbuild offers support for host programs written in C++. This was introduced solely to support kconfig, and is not recommended for general use.
Kbuild提供了對C++主機程序的支持以用於內核配置,該功能被引入主要是來爲了支持kconfig,所以通常不建議使用.
例如: #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.
在上面例子中可執行文件由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
--- 4.5 輔助程序編譯控制選項
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.
當編譯主機程序的時候,仍能夠設置特定的標誌.程序始終會使用$(HOSTCC)變量,該變量中的選項是從$(HOSTCFLAGS)變量傳來的.設置這些選項將影響全部使用了變量$(HOSTCFLAGS)的makefile建立的主機程序.
例如: #scripts/lxdialog/Makefile
HOST_EXTRACFLAGS += -I/usr/include/ncurses
To set specific flags for a single file the following construction is used:
爲單個文件設置選項使用下面方式:
例如: #arch/ppc64/boot/Makefile
HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
It is also possible to specify additional options to the linker.
也可使用附加連接選項:
例如: #scripts/kconfig/Makefile
HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
When linking qconf, it will be passed the extra option "-L$(QTDIR)/lib".
當連接qconf時將使用外部選項"-L$(QTDIR)/lib".
--- 4.6 When host programs are actually built
--- 4.6 什麼時候創建輔助程序
Kbuild will only build host-programs when they are referenced as a prerequisite. This is possible in two ways:
只有當該輔助程序做爲一個先決條件(必備文件)被引用時,Kbuild纔會去編譯它.有兩種方式:
(1) List the prerequisite explicitly in a special rule.
(1) 在特殊規則中做爲隱式的前提需求
例如: #drivers/pci/Makefile
hostprogs-y := gen-devlist
$(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
(cd $(obj); ./gen-devlist ) < $<
The target $(obj)/devlist.h will not be built before $(obj)/gen-devlist is updated. Note that references to the host programs in special rules must be prefixed with $(obj).
編譯目標文件$(obj)/devlist.h須要先創建$(obj)/gen-devlist.注意在特殊規則中使用主機程序必須加前綴$(obj).
(2) Use $(always)
(2) 使用$(always)
When there is no suitable special rule, and the host program shall be built when a makefile is entered, the $(always) variable shall be used.
當沒有合適的特殊規則可使用,而且在進入makefile文件時就要創建主機程序,可使用變量$(always).
例如: #scripts/lxdialog/Makefile
hostprogs-y := lxdialog
always := $(hostprogs-y)
This will tell kbuild to build lxdialog even if not referenced in any rule.
這樣就告訴內核編譯系統即便沒有任何規則使用lxdialog也要編譯它.
--- 4.7 Using hostprogs-$(CONFIG_FOO)
--- 4.7 使用hostprogs-$(CONFIG_FOO)
A typical pattern in a Kbuild file looks like this:
在Kbuild文件中典型模式以下:
例如: #scripts/Makefile
hostprogs-$(CONFIG_KALLSYMS) += kallsyms
Kbuild knows about both 'y' for built-in and 'm' for module. So if a config symbol evaluate to 'm', kbuild will still build the binary. In other words, Kbuild handles hostprogs-m exactly like hostprogs-y. But only hostprogs-y is recommended to be used when no CONFIG symbols are involved.
對Kbuild來講'y'用於內嵌對象'm'用於模塊.所以若是config符號是'm',編譯系統也將建立該程序.換句話說內核編譯系統等同看待hostprogs-m和hostprogs-y.但若是不涉及到CONFIG符號僅建議使用hostprogs-y.
=== 5 Kbuild clean infrastructure
=== 5 編譯清除機制
"make clean" deletes most generated files in the obj tree where the kernel is compiled. This includes generated files such as host programs. Kbuild knows targets listed in $(hostprogs-y), $(hostprogs-m), $(always), $(extra-y) and $(targets). They are all deleted during "make clean". Files matching the patterns "*.[oas]", "*.ko", plus some additional files generated by kbuild are deleted all over the kernel src tree when "make clean" is executed.
Additional files can be specified in kbuild makefiles by use of $(clean-files).
"make clean"命令刪除在編譯內核生成的大部分文件,例如主機程序.列舉在$(hostprogs-y)、$(hostprogs-m)、$(always)、$(extra-y)和$(targets)中目標文件都將被刪除.代碼目錄數中的"*.[oas]"、"*.ko"文件和一些由編譯系統產生的附加文件也將被刪除.
附加文件可使用$(clean-files)進行定義.
例如: #drivers/pci/Makefile
clean-files := devlist.h classlist.h
When executing "make clean", the two files "devlist.h classlist.h" will be deleted. Kbuild will assume files to be in same relative directory as the Makefile except if an absolute path is specified (path starting with '/').
當執行"make clean"命令時, "devlist.h classlist.h"兩個文件將被刪除.內核編譯系統默認這些文件與makefile具備相同的相對路徑,不然須要設置以'/'開頭的絕對路徑.
To delete a directory hierarchy use:
刪除整個目錄使用如下方式:
例如: #scripts/package/Makefile
clean-dirs := $(objtree)/debian/
This will delete the directory debian, including all subdirectories. Kbuild will assume the directories to be in the same relative path as the
Makefile if no absolute path is specified (path does not start with '/').
To exclude certain files from make clean, use the $(no-clean-files) variable. This is only a special case used in the top level Kbuild file:
這樣就將刪除包括子目錄在內的整個debian目錄.若是沒有指定以'/'開頭的絕對路徑,Kbuild假定這裏使用和Makefile相同的相對路徑.
若是要使make clean的時候排除某些文件,則需使用$(no-clean-file)變量.這僅僅是在頂層Kbuild文件中的一種特殊狀況:
例如:#Kbuild
no-clean-files := $(bounds-file) $(offsets-file)
Usually kbuild descends down in subdirectories due to "obj-* := dir/", but in the architecture makefiles where the kbuild infrastructure
is not sufficient this sometimes needs to be explicit.
一般內核編譯系統根據"obj-* := dir/"進入子目錄,但有的時候,Kbuild架構還不足以描述和體系結構相關的makefile的狀況時,就須要顯式的指明所要訪問的子目錄:
例如: #arch/x86/boot/Makefile
subdir- := compressed/
The above assignment instructs kbuild to descend down in the directory compressed/ when "make clean" is executed.
上面賦值語句指示編譯系統執行"make clean"命令時進入compressed/目錄.
To support the clean infrastructure in the Makefiles that builds the final bootimage there is an optional target named archclean:
在編譯最終的引導映像文件的makefile中有一個可選的目標對象名稱是archclean.
例如: #arch/ x86/Makefile
archclean:
$(Q)$(MAKE) $(clean)=arch/ x86/boot
When "make clean" is executed, make will descend down in arch/x86/boot, and clean as usual. The Makefile located in arch/x86/boot/ may use the subdir- trick to descend further down.
當執行"make clean"時編譯器進入arch/ x86/boot並象一般同樣工做.arch/ x86/boot中的makefile文件可使用subdir- 標識進入更下層的目錄.
Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is included in the top level makefile, and the kbuild infrastructure
is not operational at that point.
注意1:arch/$(ARCH)/Makefile不能使用"subdir-",由於它被包含在頂層makefile文件中,在這個位置編譯機制是不起做用的.
Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will be visited during "make clean".
注意2:全部列舉在core-y、libs-y、drivers-y和net-y中的目錄將被"make clean"命令清除.
=== 6 Architecture Makefiles
=== 6 架構Makefile文件
The top level Makefile sets up the environment and does the preparation, before starting to descend down in the individual directories.
在開始進入各個目錄編譯以前,頂層makefile文件設置編譯環境和作些準備工做.
The top level makefile contains the generic part, whereas arch/$(ARCH)/Makefile contains what is required to set up kbuild for said architecture.
To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines a few targets.
頂層makefile文件包含通用的部分,然而arch/$(ARCH) /Makefile包含該體系架構所需的設置.要作到這一點,arch/$(ARCH)/Makefile會設置一些變量和少許的目標.
When kbuild executes, the following steps are followed (roughly):
當編譯時將按照如下大概步驟執行:
1) Configuration of the kernel => produce .config
1) 配置內核 => 產生.config文件
2) Store kernel version in include/linux/version.h
2) 保存內核版本到include/linux/version.h文件中
3) Symlink include/asm to include/asm-$(ARCH)
3) 符號連接include/asm到include/asm-$(ARCH)
4) Updating all other prerequisites to the target prepare:
4) 更新全部目標對象的其它前提文件
- Additional prerequisites are specified in arch/$(ARCH)/Makefile
- 附加前提文件定義在arch/$(ARCH)/Makefile文件中
5) Recursively descend down in all directories listed in init-* core* drivers-* net-* libs-* and build all targets.
5) 遞歸進入init-* core* drivers-* net-* libs-*中的全部子目錄並編譯全部的目標對象
- The values of the above variables are expanded in arch/$(ARCH)/Makefile.
- 上述變量均可以在arch/$(ARCH)/Makefile文件中擴展.
6) All object files are then linked and the resulting file vmlinux is located at the root of the obj tree. The very first objects linked are listed in head-y, assigned by arch/$(ARCH)/Makefile.
6) 連接全部的object文件生成vmlinux文件,在代碼樹根目錄下.最早連接的幾個object文件是在arch/$(ARCH)/Makefile文件的head-y變量中指定的.
7) Finally, the architecture-specific part does any required post processing and builds the final bootimage.
7) 最後,特定體系相關的部分作一些必要的處理並創建最終的引導映像bootimage.
- This includes building boot records
- 包括建立引導指令
- Preparing initrd images and the like
- 準備initrd鏡像和相似文件
--- 6.1 Set variables to tweak the build to the architecture
--- 6.1設置變量調整構建的體系結構
LDFLAGS Generic $(LD) options
LDFLAGS $(LD)通常選項
Flags used for all invocations of the linker. Often specifying the emulation is sufficient.
該選項在每次調用連接器時都會用到.通常狀況下,只用來指明模擬器.
例如: #arch/s390/Makefile
LDFLAGS := -m elf_s390
Note: ldflags-y can be used to further customize the flags used. See chapter 3.7.
注意: LDFLAGS-y能夠進一步訂製所使用選項,參考第3.7節.
LDFLAGS_MODULE Options for $(LD) when linking modules
LDFLAGS_MODULE $(LD)連接模塊的選項
LDFLAGS_MODULE is used to set specific flags for $(LD) when linking the .ko files used for modules. Default is "-r", for relocatable output.
LDFLAGS_MODULE用於在使用$(LD)連接.ko文件爲模塊的時候設置選項.默認爲"-r",指定輸出文件是可重定位的.
LDFLAGS_vmlinux Options for $(LD) when linking vmlinux
LDFLAGS_vmlinux $(LD)連接vmlinux選項
LDFLAGS_vmlinux is used to specify additional flags to pass to the linker when linking the final vmlinux image.
LDFLAGS_vmlinux用於在連接最終vmlinux鏡像時給連接器指定一些附加選項.
LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
LDFLAGS_vmlinux支持使用LDFLAGS_$@.
例如: #arch/ x86/Makefile
LDFLAGS_vmlinux := -e stext
OBJCOPYFLAGS objcopy flags
OBJCOPYFLAGS objcopy選項
When $(call if_changed,objcopy) is used to translate a .o file, the flags specified in OBJCOPYFLAGS will be used. $(call if_changed,objcopy) is often used to generate raw binaries on vmlinux.
當使用$(call if_changed,objcopy)轉化a .o文件時,定義在OBJCOPYFLAGS中的該選項將被使用. $(call if_changed,objcopy)常常被用來產生vmlinux的原始的二進制文件.
例如: #arch/s390/Makefile
OBJCOPYFLAGS := -O binary
#arch/s390/boot/Makefile
$(obj)/image: vmlinux FORCE
$(call if_changed,objcopy)
In this example, the binary $(obj)/image is a binary version of vmlinux. The usage of $(call if_changed,xxx) will be described later.
在該例中, $(obj)/image是vmlinux的二進制版本文件.$(call if_changed,xxx)的使用方法見後.
KBUILD_AFLAGS $(AS) assembler flags
KBUILD_AFLAGS $(AS)彙編選項
Default value - see top level Makefile
默認值見頂層Makefile文件
Append or modify as required per architecture.
針對每一個體系須要另外添加和修改它.
例如: #arch/sparc64/Makefile
KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
KBUILD_CFLAGS $(CC) compiler flags
KBUILD_CFLAGS $(CC)編譯器選項
Default value - see top level Makefile
默認值見頂層Makefile文件
Append or modify as required per architecture.
針對每一個體系須要另外添加和修改它.
Often, the KBUILD_CFLAGS variable depends on the configuration.
一般KBUILD_CFLAGS變量值取決於內核配置.
例如: #arch/ x86/Makefile
cflags-$(CONFIG_M386) += -march=i386
CFLAGS += $(cflags-y)
Many arch Makefiles dynamically run the target C compiler to probe supported options:
許多體系Makefiles文件動態運行目標C編譯器來檢測其支持的選項:
#arch/ x86/Makefile
...
cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
-march=pentium2,-march=i686) .
# Disable unit-at-a-time mode ...
CFLAGS += $(call cc-option,-fno-unit-at-a-time)
...
The first example utilises the trick that a config option expands to 'y' when selected.
第一個例子使用了一個配置選項,當config配置該選項爲'y'時將被選中.
KBUILD_AFLAGS_KERNEL $(AS) options specific for built-in
KBUILD_AFLAGS_KERNEL 編譯built-in對象時,$(AS)使用的選項
$(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile resident kernel code.
$( KBUILD_AFLAGS_KERNEL)包含編譯常駐內核代碼使用的外部C編譯器選項.
KBUILD_AFLAGS_MODULE Options for $(AS) when building modules
KBUILD_AFLAGS_MODULE 編譯模塊時, $(AS)使用的選項
$(KBUILD_AFLAGS_MODULE) is used to add arch specific options that are used for $(AS).
$( KBUILD_AFLAGS_MODULE)用於爲$(AS)添加一些特定的選項.
From commandline AFLAGS_MODULE shall be used (see kbuild.txt).
能夠查看命令行AFLAGS_MODULE用法(看kbuild.txt)
KBUILD_CFLAGS_KERNEL $(CC) options specific for built-in
KBUILD_CFLAGS_KERNEL 編譯built-in對象時,$(CC)使用的選項
$(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile resident kernel code.
$( KBUILD_CFLAGS_KERNEL)包含編譯常駐內核代碼使用的外部C編譯器選項.
KBUILD_CFLAGS_MODULE Options for $(CC) when building modules
KBUILD_CFLAGS_MODULE 編譯模塊時, $(CC)使用的選項
$(KBUILD_CFLAGS_MODULE) is used to add arch specific options that are used for $(CC).
$( KBUILD_CFLAGS_MODULE)用於爲$(CC)添加一些特定的選項.
From commandline CFLAGS_MODULE shall be used (see kbuild.txt).
能夠查看命令行CFLAGS_MODULE用法(看kbuild.txt)
KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules
KBUILD_LDFLAGS_MODULE 連接模塊時,$(LD)所使用的選項
$(KBUILD_LDFLAGS_MODULE) is used to add arch specific options used when linking modules. This is often a linker script.
$( KBUILD_LDFLAGS_MODULE)用於在連接模塊時添加一些特定的選項.這也是一個連接腳本.
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
能夠查看命令行LDFLAGS_MODULE用法(看kbuild.txt)
KBUILD_ARFLAGS Options for $(AR) when creating archives
KBUILD_ARFLAGS 建立壓縮文件時,$(AR)所使用的選項
$(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic mode) if this option is supported by $(AR).
$( KBUILD_ARFLAGS)由頂層Makefile設置爲」D」(肯定模式),若是$(AR)支持該選項的話.
--- 6.2 Add prerequisites to archheaders
--- 6.2增長預設置項到archheaders中
The archheaders: rule is used to generate header files that may be installed into user space by "make header_install" or "make headers_install_all". In order to support "make headers_install_all", this target has to be able to run on an unconfigured tree, or a tree configured for another architecture.
archheaders:這是用於生成頭文件的規則,這些頭文件能夠經過」make header_install」或者」make headers_install_all」安裝到用戶空間.爲了支持」make headers_install_all」,該目標必須可以在未配置或者被配置爲其餘體系結構的樹上運行.
It is run before "make archprepare" when run on the architecture itself.
這些命令(指生成頭文件)會在」make archprepare」以前在本地架構上就運行.
--- 6.3 Add prerequisites to archprepare
--- 6.3增長預設置項到archprepare中
The archprepare: rule is used to list prerequisites that need to be built before starting to descend down in the subdirectories.
This is usually used for header files containing assembler constants.
archprepare:這個規則用於列舉開始進入子目錄前編譯時須要的前提文件.一般用在包含彙編常量的頭文件.
例如: #arch/arm/Makefile
archprepare: maketools
In this example, the file target maketools will be processed before descending down in the subdirectories. See also chapter XXX-TODO that describe how kbuild supports generating offset header files.
在這個例子中,目標文件maketools將在進入子目錄前被處理.詳見XXX-TODO章描述了kbuild如何支持生成offset頭文件.
--- 6.4 List directories to visit when descending
--- 6.4 遞歸向下訪問的目錄列表
An arch Makefile cooperates with the top Makefile to define variables which specify how to build the vmlinux file. Note that there is no corresponding arch-specific section for modules; the module-building machinery is all architecture-independent.
體系makefile文件配合頂層makefile文件共同定義了一些變量用於指定如何創建vmlinux文件.注意架構makefile是不會定義和模塊相關的內容的;全部構建模塊的機制都是體系無關的.
head-y, init-y, core-y, libs-y, drivers-y, net-y
$(head-y) lists objects to be linked first in vmlinux.
$(head-y) 列出了最早連接到vmlinux的目標文件.
$(libs-y) lists directories where a lib.a archive can be located.
$(libs-y) 列出了全部lib.a所在的目錄.
The rest list directories where a built-in.o object file can be located.
其他的變量列出了build-in.o文件所在的目錄.
$(init-y) objects will be located after $(head-y).
$(init-y) 列舉的對象位於$(head-y)對象以後.
Then the rest follows in this order:
$(core-y), $(libs-y), $(drivers-y) and $(net-y).
而後剩下的按照以下順序:
$(core-y), $(libs-y), $(drivers-y) 和 $(net-y).
The top level Makefile defines values for all generic directories, and arch/$(ARCH)/Makefile only adds architecture-specific directories.
頂層makefile定義了全部通用目錄,而arch/$(ARCH)/Makefile文件只需增長體系相關的目錄.
例如: #arch/sparc64/Makefile
core-y += arch/sparc64/kernel/
libs-y += arch/sparc64/prom/ arch/sparc64/lib/
drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/
--- 6.5 Architecture-specific boot images
--- 6.5 具體架構的引導映像
An arch Makefile specifies goals that take the vmlinux file, compress it, wrap it in bootstrapping code, and copy the resulting files somewhere. This includes various kinds of installation commands. The actual goals are not standardized across architectures.
體系makefile文件的目標就是,生成並壓縮vmlinux文件,而後把它打包成引導啓動代碼,並複製到合適的位置.這包括各類安裝命令.如何定義實際的目標對象是沒法在各個體系結構間進行標準化的.
It is common to locate any additional processing in a boot/ directory below arch/$(ARCH)/.
通常的,附加處理過程常位於arch/$(ARCH)/下的boot/目錄.
Kbuild does not provide any smart way to support building a target specified in boot/. Therefore arch/$(ARCH)/Makefile shall call make manually to build a target in boot/.
Kbuild並無爲構建boot/目錄下的目標提供更好的方法.所以arch/$(ARCH)/Makefile須要調用make命令手動在boot /目錄下創建目標文件.
The recommended approach is to include shortcuts in arch/$(ARCH)/Makefile, and use the full path when calling down into the arch/$(ARCH)/boot/Makefile.
推薦使用的方法是在arch/$(ARCH)/Makefile包含快捷方式,而後在調用arch/$(ARCH) /boot/Makefile中使用完整路徑.
例如: #arch/x86/Makefile
boot := arch/x86/boot
bzImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
"$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke make in a subdirectory.
建議使用"$(Q)$(MAKE) $(build)=<dir>"方式在子目錄中調用make命令.
There are no rules for naming architecture-specific targets, but executing "make help" will list all relevant targets. To support this, $(archhelp) must be defined.
沒有專門用於命名特定體系結構目標文件的規則,但執行"make help"命令要列出全部目標系統文件,爲支持該功能,所以必須定義$(archhelp)變量.
例如: #arch/x86/Makefile
define archhelp
echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)'
endif
When make is executed without arguments, the first goal encountered will be built. In the top level Makefile the first goal present
is all:.
當執行不帶參數的make命令時,所遇到的第一個目標將被創建.在頂層makefile中,第一個目標就是all:.
An architecture shall always, per default, build a bootable image. In "make help", the default goal is highlighted with a '*'.
默認狀況下,每一個體繫結構都應該構造一個可引導映像.在"make help"中,默認的目標就是被高亮的」*」.
Add a new prerequisite to all: to select a default goal different from vmlinux.
增長新的前提文件給all,就能夠構造一個不一樣於vmlinux的默認目標.
例如: #arch/x86/Makefile
all: bzImage
When "make" is executed without arguments, bzImage will be built.
當執行不帶參數的"make"命令時,bzImage文件將被構造.
--- 6.6 Building non-kbuild targets
--- 6.6 編譯非內核目標
extra-y
extra-y specify additional targets created in the current directory, in addition to any targets specified by obj-*. Listing all targets in extra-y is required for two purposes:
extra-y指定了在當前目錄下建立的沒有在obj-*定義的附加的目標文件.在extra-y中列舉目標是處於兩個目的:
1) Enable kbuild to check changes in command lines
1) 使kbuild能夠檢查命令行是否發生變化
- When $(call if_changed,xxx) is used
- 當使用$(call if_changed,xxx)時
2) kbuild knows what files to delete during "make clean"
2) kbuild知道執行"make clean"命令時刪除哪些文件
例如:#arch/x86/kernel/Makefile
extra-y := head.o init_task.o
In this example, extra-y is used to list object files that shall be built, but shall not be linked as part of built-in.o.
該例子中,extra-y中的對象文件將被編譯,但不會被連接到built-in.o中.
--- 6.7 Commands useful for building a boot image
--- 6.7 構建引導映像的命令
Kbuild provides a few macros that are useful when building a boot image.
Kbuild提供了一些宏,用於構建一個引導映像.
if_changed
if_changed is the infrastructure used for the following commands.
if_changed是後面命令使用的基礎.
用法:
target: source(s) FORCE
$(call if_changed,ld/objcopy/gzip)
When the rule is evaluated, it is checked to see if any files need an update, or the command line has changed since the last invocation.
當該規則被使用時,它將檢查是否有文件須要更新,或者自上次調用以後命令行是否發生了改變.
The latter will force a rebuild if any options to the executable have changed.
若是該可執行程序的任何選項被更改的話,後者會強制從新構造該目標文件.
Any target that utilises if_changed must be listed in $(targets), otherwise the command line check will fail, and the target will always be built.
任何使用if_changed的目標對象都必須在$(targets)中列出來,不然命令行檢查將失敗,而且目標老是會被重建.
Assignments to $(targets) are without $(obj)/ prefix.
給$(targets)的對象的賦值沒有$(obj)/前綴.
if_changed may be used in conjunction with custom commands as defined in 6.8 "Custom kbuild commands".
if_changed也能夠和定製命令配合使用,見6.8節"自定義內核編譯命令".
Note: It is a typical mistake to forget the FORCE prerequisite.
注意: 忘記了FORCE前導詞是一個常見的錯誤.
Another common pitfall is that whitespace is sometimes significant; for instance, the below will fail (note the extra space after the comma):
另外一個常見的錯誤是,空格有時候是有意義的;好比,下面的命令就會錯誤(注意在逗號後面的那個多餘的空格):
target: source(s) FORCE
#WRONG!# $(call if_changed, ld/objcopy/gzip)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ld
Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
連接目標.常使用LDFLAGS_$@來設置ld的選項.
objcopy
Copy binary. Uses OBJCOPYFLAGS usually specified in arch/$(ARCH)/Makefile. OBJCOPYFLAGS_$@ may be used to set additional options.
拷貝二進制文件.通常用於arch/$(ARCH)/Makefile中,使用OBJCOPYFLAGS變量來指定.也能夠用OBJCOPYFLAGS_$@來設置附加選項.
gzip
Compress target. Use maximum compression to compress target.
壓縮目標文件.使用最大壓縮算法壓縮目標文件.
例如: #arch/x86/boot/Makefile
LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
targets += setup setup.o bootsect bootsect.o
$(obj)/setup $(obj)/bootsect: %: %.o FORCE
$(call if_changed,ld)
In this example, there are two possible targets, requiring different options to the linker. The linker options are specified using the LDFLAGS_$@ syntax - one for each potential target.
該例子中有兩個可能的目標對象,分別須要不一樣的連接選項.定義連接器的選項使用LDFLAGS_$@語法,每一個潛在目標一個.
$(targets) are assigned all potential targets, by which kbuild knows the targets and will:
$(targets) 會匹配全部的潛在目標,所以kbuild就知道目標是哪些,而且還會:
1) check for commandline changes
1) 檢查命令行的改變
2) delete target during make clean
2) 執行make clean命令時刪除目標對象
The ": %: %.o" part of the prerequisite is a shorthand that free us from listing the setup.o and bootsect.o files.
Note: It is a common mistake to forget the "target :=" assignment, resulting in the target file being recompiled for no obvious reason.
先決條件中的": %: %.o"部分是簡寫方法,使咱們沒必要在列出setup.o和bootsect.o文件.
注意: 常犯錯誤是忘記"target :="語句,致使目標文件莫名其妙地被從新編譯.
dtc
Create flattend device tree blob object suitable for linking into vmlinux. Device tree blobs linked into vmlinux are placed in an init section in the image. Platform code *must* copy the blob to non-init memory prior to calling unflatten_device_tree().
建立適合於連接到vmlinux的平面設備樹文件.設備樹文件連接進vmlinux被放置在鏡像的init段中.平臺代碼必須在調用unflatten_device_tree()以前將設備樹文件拷貝到非未初始化內存.
To use this command, simply add *.dtb into obj-y or targets, or make some other target depend on %.dtb
要使用此命令,只須要簡單的將*.dtb加入到obj-y或者targets目標中,或者構建一些其餘的目標使之依賴於%.dtb
A central rule exists to create $(obj)/%.dtb from $(src)/%.dts; architecture Makefiles do no need to explicitly write out that rule.
從$(src)/%.dts構建$(obj)/%.dtb存在一個重要的規則;架構相關Makefile不須要顯式指定該規則.
例如:
targets += $(dtb-y)
clean-files += *.dtb
DTC_FLAGS ?= -p 1024
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dtc_cpp
This is just like dtc as describe above, except that the C pre-processor is invoked upon the .dtsp file before compiling the result with dtc.
除了在編譯以前是通過.dtsp文件中調用的C預編譯器以外,該命令規則和上文dtc所描述的同樣.
In order for build dependencies to work, all files compiled using dtc_cpp must use the C pre-processor's #include functionality and not dtc's /include/ functionality.
爲了讓構建依賴能正常工做,全部使用dtc_cpp編譯的文件都必須使用C預編譯器的#include功能而不是dtc的那種/include/機制.
Using the C pre-processor allows use of #define to create named constants. In turn, the #defines will typically appear in a header file, which may be shared with regular C code. Since the dtc language represents a data structure rather than code in C syntax, similar restrictions are placed on a header file included by a device tree file as for a header file included by an assembly language file.
使用C預編譯器支持使用#define來建立命名常量.反之,#define定義一般會出如今一個頭文件中,能夠和常規的C代碼共享.因爲dtc語言表示的是一個數據結構而不是C語法代碼,相似的限制被放置在一個頭文件中,該頭文件被設備樹包含,就像彙編語言文件包含頭文件那樣.
In particular, the C pre-processor is passed -x assembler-with-cpp, which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header files to restrict their content to that compatible with device tree source.
特別是,C預編譯器將被傳遞-x assembler-with-cpp,經過設置宏__ASSEMBLY__. __DTS__也設置了,這就支持了頭文件經過限制其內容來和設備樹相兼容.
A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp; architecture Makefiles do no need to explicitly write out that rule.
從$(src)/%.dtsP構建$(obj)/%.dtb存在一個重要的規則;架構相關Makefile不須要顯式指定該規則.
--- 6.8 Custom kbuild commands
--- 6.8 自定義內核編譯命令
When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand of a command is normally displayed. To enable this behaviour for custom commands kbuild requires two variables to be set:
quiet_cmd_<command> - what shall be echoed
cmd_<command> - the command to execute
當kbuild執行帶KBUILD_VERBOSE=0參數的編譯命令時,只會顯示命令的簡寫.要啓用自定義命令的該功能,就須要設置兩個變量:
quiet_cmd_<command> - 將被顯示的內容
cmd_<command> - 被執行的命令
例如: #quiet_cmd_image = BUILD $@
cmd_image = $(obj)/tools/build $(BUILDFLAGS) \
$(obj)/vmlinux.bin > $@
targets += bzImage
$(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE
$(call if_changed,image)
@echo 'Kernel: $@ is ready'
When updating the $(obj)/bzImage target, the line
BUILD arch/x86/boot/bzImage
will be displayed with "make KBUILD_VERBOSE=0".
執行"make KBUILD_VERBOSE=0"命令更新$(obj)/bzImage目標時將顯示:
BUILD arch/x86/boot/bzImage
--- 6.9 Preprocessing linker scripts
--- 6.9 預處理鏈接腳本
When the vmlinux image is built, the linker script arch/$(ARCH)/kernel/vmlinux.lds is used.
當構造vmlinux映像時,將使用arch/$(ARCH)/kernel/vmlinux.lds連接腳本.
The script is a preprocessed variant of the file vmlinux.lds.S located in the same directory. kbuild knows .lds files and includes a rule *lds.S -> *lds.
該腳本是同目錄下的vmlinux.lds.S文件的預處理的變體. Kbuild認識.lds文件幷包含*lds.S -> *lds的生成規則.
例如:#arch/x86/kernel/Makefile
always := vmlinux.lds
#Makefile
export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
The assignment to $(always) is used to tell kbuild to build the target vmlinux.lds.
賦值給$(always)是用來告訴kbuild,去構造目標vmlinux.lds
The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the specified options when building the target vmlinux.lds.
賦值給$( CPPFLAGS_vmlinux.lds)是用來告訴kbuild,使用指定的選項去構造構造目標vmlinux.lds
When building the *.lds target, kbuild uses the variables:
編譯*.lds時將使用到下面這些變量:
KBUILD_CPPFLAGS : Set in top-level Makefile
KBUILD_CPPFLAGS : 定義在頂層Makefile
cppflags-y : May be set in the kbuild makefile
cppflags-y : 能夠在kbuild makefile中設置
CPPFLAGS_$(@F) : Target specific flags.
Note that the full filename is used in this assignment.
CPPFLAGS_$(@F) :目標編譯選項
注意此處的賦值使用完整的文件名
The kbuild infrastructure for *lds file are used in several architecture-specific files.
針對*.lds文件的kbuild構架還被用在一些特定的體系結構的文件中.
--- 6.10 Generic header files
--- 6.10 通用頭文件
The directory include/asm-generic contains the header files that may be shared between individual architectures.
Include/asm-generic目錄下包含的頭文件能夠在各個架構之間共享.
The recommended approach how to use a generic header file is to list the file in the Kbuild file.
推薦的使用通用頭文件的方法,是將其羅列在kbuild文件中.
See "7.4 generic-y" for further info on syntax etc.
關於語法等更多資料,參看」7.4 gerneric-y」
=== 7 Kbuild syntax for exported headers
=== 7 導出頭文件的Kbuild語法
The kernel include a set of headers that is exported to userspace. Many headers can be exported as-is but other headers require a minimal pre-processing before they are ready for user-space.
內核包含一組能夠導出到用戶空間的頭文件.許多頭文件能夠原樣導出,可是有一部分頭文件在用戶空間讀取以前,須要作一些簡單的處理.
The pre-processing does:
- drop kernel specific annotations
- drop include of compiler.h
- drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
這些預先處理包括:
-去掉內核特定的註釋
-去掉compiler.h頭文件的包含
-去掉內核內的全部段(即便用ifdef __KERNEL__聲明的部分)
Each relevant directory contains a file name "Kbuild" which specifies the headers to be exported.
每一個相關的目錄都包含一個名爲」Kbuild」的文件,該文件指定了那些頭文件要被導出.
See subsequent chapter for the syntax of the Kbuild file.
參見後續章節的Kbuild文件的語法.
--- 7.1 header-y
header-y specify header files to be exported.
head-y指定了要導出的頭文件.
例如:#include/linux/Kbuild
header-y += usb/
header-y += aio_abi.h
The convention is to list one file per line and preferably in alphabetic order.
約定每一行列出一個文件,並最好是按字母順序排列.
header-y also specify which subdirectories to visit. A subdirectory is identified by a trailing '/' which can be seen in the example above for the usb subdirectory. Subdirectories are visited before their parent directories.
header-y還能夠指定要訪問的子目錄.子目錄能夠由末尾是」/」肯定,能夠看到,上文例子中使用了usb子目錄.子目錄會在其父目錄以前就被訪問.
--- 7.2 genhdr-y
genhdr-y specifies generated files to be exported.
genhdr-y指定生成的文件被導出.
Generated files are special as they need to be looked up in another directory when doing 'make O=...' builds.
生成文件比較特殊,由於當執行’make O=…’構建的它們的時候,須要查詢另外一個目錄
例如:#include/linux/Kbuild
genhdr-y += version.h
--- 7.3 destination-y
When an architecture have a set of exported headers that needs to be exported to a different directory destination-y is used.
當一個架構有一套頭文件須要被導出到不一樣的目錄去的時候,就須要用到destination-y.
destination-y specify the destination directory for all exported headers in the file where it is present.
destination-y指定全部的存在於文件中,被指定的要導出的頭文件的目標目錄
例如:#arch/xtensa/platforms/s6105/include/platform/Kbuild
destination-y := include/linux
In the example above all exported headers in the Kbuild file will be located in the directory "include/linux" when exported.
在上例中,全部存在與Kbuild文件中的要導出的頭文件,在導出時都將被定位到」include/linux」目錄.
--- 7.4 generic-y
If an architecture uses a verbatim copy of a header from include/asm-generic then this is listed in the file arch/$(ARCH)/include/asm/Kbuild like this:
若是一個架構從include/asm-generic目錄逐字拷貝頭文件,那麼在arch/$(ARCH)/include/asm/Kbuild文件中的列表應該像下面這樣:
例如:#arch/x86/include/asm/Kbuild
generic-y += termios.h
generic-y += rtc.h
During the prepare phase of the build a wrapper include file is generated in the directory:
arch/$(ARCH)/include/generated/asm
構建一個包的準備階段,包括在arch/$(ARCH)/include/generated/asm目錄下生成文件.
When a header is exported where the architecture uses the generic header a similar wrapper is generated as part of the set of exported headers in the directory:
usr/include/asm
當一個頭文件被導出時,導出到的那個架構,採用了和在usr/include/asm目錄下導出的頭文件集合的一部分相似的封裝,來生成通用頭文件.
The generated wrapper will in both cases look like the following:
生成的封裝可能就是像下面這兩種狀況:
例如:termios.h
#include <asm-generic/termios.h>
=== 8 Kbuild Variables
=== 8 Kbuild變量
The top Makefile exports the following variables:
VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
頂層Makefile文件導出下面這些變量:
VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
These variables define the current kernel version. A few arch Makefiles actually use these values directly; they should use $(KERNELRELEASE) instead.
這幾個變量定義了當前內核版本號.不多有架構相關的Makefiles文件直接使用這些變量;它們一般會使用$(KERNELRELEASE)來獲取內核版本號.
$(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic three-part version number, such as "2", "4", and "0". These three
values are always numeric.
$(VERSION),$(PATCHLEVEL)和$(SUBLEVEL)定義了三個基礎版本號,例如"2", "4",和"0".這三個變量老是數字.
$(EXTRAVERSION) defines an even tinier sublevel for pre-patches or additional patches. It is usually some non-numeric string such as "-pre4", and is often blank.
$(EXTRAVERSION)爲補丁定義了更細的版本號,一般是一些非數值字符串,例如"-pre4",但更多狀況下是空白.
KERNELRELEASE
$(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable for constructing installation directory names or showing in version strings. Some arch Makefiles use it for this purpose.
$(KERNELRELEASE)是一個字符串,好比"2.4.0-pre4",適合於安裝目錄的命名,或者顯示當前的版本號.有些架構Makefile就使用該變量來實現此目標.
ARCH
This variable defines the target architecture, such as "i386", "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to determine which files to compile.
這個變量定義了目標系統體系結構,例如"i386",」arm","sparc".一些kbuild Makefile檢測$(ARCH)來肯定哪些文件須要編譯.
By default, the top Makefile sets $(ARCH) to be the same as the host system architecture. For a cross build, a user may override the value of $(ARCH) on the command line:
make ARCH=m68k ...
默認狀況下頂層Makefile文件把$(ARCH)設置爲主機相同的體系結構.當交叉編譯編譯時,用戶可使用命令行傳值來改變$(ARCH)值,好比:
make ARCH=m68k ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INSTALL_PATH
This variable defines a place for the arch Makefiles to install the resident kernel image and System.map file.Use this for architecture-specific install targets.
該變量爲架構Makefile定義了安裝內核鏡像與System.map文件的目錄.該變量主要用來指明特定架構的安裝路徑.
INSTALL_MOD_PATH, MODLIB
$(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module installation. This variable is not defined in the Makefile but may be passed in by the user if desired.
$(INSTALL_MOD_PATH)爲了安裝模塊,給變量$(MODLIB)指定了前綴.這個變量不能在Makefile中定義,可是若是須要的話,能夠由用戶傳值進來.
$(MODLIB) specifies the directory for module installation.
$(MODLIB)指定了模塊安裝的目錄.
The top Makefile defines $(MODLIB) to $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may override this value on the command line if desired.
頂層Makefile將$(MODLIB)定義爲$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE).若是須要,用戶可使用命令行傳值的方式將其覆蓋.
INSTALL_MOD_STRIP
If this variable is specified, will cause modules to be stripped after they are installed. If INSTALL_MOD_STRIP is '1', then the default option --strip-debug will be used. Otherwise, INSTALL_MOD_STRIP value will be used as the option(s) to the strip command.
若是該變量被定義的話,將致使模塊在安裝以後就被去掉.若是INSTALL_MOD_STRIP是’1’,那麼默認的選項—strip-debug將被使用.不然, INSTALL_MOD_STRIP這個變量的值將做爲strip命令的選項被使用.
=== 9 Makefile language
=== 9 Makefile語言
The kernel Makefiles are designed to be run with GNU Make. The Makefiles use only the documented features of GNU Make, but they do use many GNU extensions.
內核的Makefile被設計成使用GNU Make.該Makefile僅使用GNU Make已註明的功能,但也確實用到了不少GNU的擴展.
GNU Make supports elementary list-processing functions. The kernel Makefiles use a novel style of list building and manipulation with few "if" statements.
GNU Make程序支持基本的列處理功能.內核Makefiles文件使用了一種新穎的方式,描述了"if"語句的構建和處理過程.
GNU Make has two assignment operators, ":=" and "=".
GNU Make程序有兩種賦值操做符,":="和"=".
":=" performs immediate evaluation of the right-hand side and stores an actual string into the left-hand side.
":="執行時當即計算右值並賦值給左值.
"=" is like a formula definition; it stores the right-hand side in an unevaluated form and then evaluates this form each time the left-hand side is used.
"="相似公式定義,直接將右邊的表達式賦給左值,只有當每次使用左值的時候纔會求值.
There are some cases where "=" is appropriate. Usually, though, ":=" is the right choice.
固然有些時候使用"="是能夠的.可是,一般使用":="纔是正確選擇.
=== 10 Credits
Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Updates by Sam Ravnborg <sam@ravnborg.org>
Language QA by Jan Engelhardt <jengelh@gmx.de>
=== 11 TODO
Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Updates by Sam Ravnborg <sam@ravnborg.org>
Language QA by Jan Engelhardt <jengelh@gmx.de>