Linux 的编译使用 GNU make 工具来检查整个系统的文件和调用 gcc 工具以及脚本完成编译源代码生成 image 等操作。要了解整个编译系统，我们首先要了解 Linux 内核的 Makefile 文件。
Linux 的 编译系统包括 5 个部分
Makefile
顶层的 Makefile 文件
.config
内核配置文件
arch/$(ARCH)/Makefile
平台 Makefile 文件
scripts/Makefile.*
脚本规则
kbuild Makefiles
大概 500 多个其他的 Makefile 文件
在内核源代码的根目录有一个 Makefile 文件，这是编译内核的入口，不管执行配置还是编译，make 命令首先读取这个文件。这个文件首先指明了内核的版本：
我们这里是 3.10
VERSION = 3
PATCHLEVEL = 10
SUBLEVEL = 0
EXTRAVERSION =
NAME = Unicycling Gorilla
然后处理 command line ，一共有 5 个 command line
V : 设定编译时，输出信息的等级，例如你可以用 make V=1， 查看编译时执行的所有命令，包括 gcc 参数都会打印出来
C : 代码检查，使用 sparse，检查源文件。
M : 指定不在当前目录（外部模块）的编译，也可以指定当前目录的子目录，那么将只会编译子目录的内容
O ：指定编译生成的目标文件位置，当设置了 O 参数，内核生成的 obj 和 builtin 文件都会按照目录结构组织到 O 参数指定的目录里面
W： 使能外部 gcc 检查
这几个命令参数，在特定的情况下，将会非常有用，比如我们想编译一个单独的模块就经常使用 M 参数，用 M 指定模块的路径，make 的时候将会不编译整个内核，而编译我们需要的模块：（M 参数会覆盖 KBUILD_EXTMOD 变量）
make M=drivers/misc/ LD drivers/misc/eeprom/built-in.o CC [M] drivers/misc/eeprom/eeprom_93cx6.o LD drivers/misc/built-in.o Building modules, stage 2. MODPOST 1 modules CC drivers/misc/eeprom/eeprom_93cx6.mod.o LD [M] drivers/misc/eeprom/eeprom_93cx6.ko
O 参数的指定，会改变整个编译出来的文件的结构，例如哦我们有多个平台要编译，你就需要为每个平台 clone 一份内核代码了，只需要设置不同的输出路径即可：
make O=atmel， make O=asus （O 参数会覆盖 KBUILD_OUTPUT 变量），相应的文件也会生成在目标路径下，例如 uImage 就在 atmel/arch/arm/boot/uImage
接下来系统就会获取交叉编译环境和选择不同的 gcc 和 bin 工具集
ARCH ?= $(SUBARCH) CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%)
arch 变量设置目标平台， cross compile 设置交叉编译链。
当系统信息获取成功，就可以执行编译命令了，每一个伪目标都可以作为一个编译命令：（大概有 40 个左右的伪目标），但是我们会使用到的并没有这么多，可以用 make help 查看我们使用的编译命令：
make help
Cleaning targets:
clean - Remove most generated files but keep the config and
enough build support to build external modules
mrproper - Remove all generated files + config + various backup files
distclean - mrproper + remove editor backup and patch files
Configuration targets:
config - Update current config utilising a line-oriented program
nconfig - Update current config utilising a ncurses menu based program
menuconfig - Update current config utilising a menu based program
xconfig - Update current config utilising a QT based front-end
gconfig - Update current config utilising a GTK based front-end
oldconfig - Update current config utilising a provided .config as base
localmodconfig - Update current config disabling modules not loaded
localyesconfig - Update current config converting local mods to core
silentoldconfig - Same as oldconfig, but quietly, additionally update deps
defconfig - New config with default from ARCH supplied defconfig
savedefconfig - Save current config as ./defconfig (minimal config)
allnoconfig - New config where all options are answered with no
allyesconfig - New config where all options are accepted with yes
allmodconfig - New config selecting modules when possible
alldefconfig - New config with all symbols set to default
randconfig - New config with random answer to all options
listnewconfig - List new options
olddefconfig - Same as silentoldconfig but sets new symbols to their default value
Other generic targets:
all - Build all targets marked with [*]
* vmlinux - Build the bare kernel
* modules - Build all modules
modules_install - Install all modules to INSTALL_MOD_PATH (default: /)
firmware_install- Install all firmware to INSTALL_FW_PATH
(default: $(INSTALL_MOD_PATH)/lib/firmware)
dir/ - Build all files in dir and below
dir/file.[oisS] - Build specified target only
dir/file.lst - Build specified mixed source/assembly target only
(requires a recent binutils and recent build (System.map))
dir/file.ko - Build module including final link
modules_prepare - Set up for building external modules
tags/TAGS - Generate tags file for editors
cscope - Generate cscope index
gtags - Generate GNU GLOBAL index
kernelrelease - Output the release version string
kernelversion - Output the version stored in Makefile
headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH
(default: /media/android/jiangxd/workspace/Miura/kernel/usr)
Static analysers
checkstack - Generate a list of stack hogs
namespacecheck - Name space analysis on compiled kernel
versioncheck - Sanity check on version.h usage
includecheck - Check for duplicate included header files
export_report - List the usages of all exported symbols
headers_check - Sanity check on exported headers
headerdep - Detect inclusion cycles in headers
coccicheck - Check with Coccinelle.
Kernel packaging:
rpm-pkg - Build both source and binary RPM kernel packages
binrpm-pkg - Build only the binary kernel package
deb-pkg - Build the kernel as a deb package
tar-pkg - Build the kernel as an uncompressed tarball
targz-pkg - Build the kernel as a gzip compressed tarball
tarbz2-pkg - Build the kernel as a bzip2 compressed tarball
tarxz-pkg - Build the kernel as a xz compressed tarball
perf-tar-src-pkg - Build perf-3.10.0.tar source tarball
perf-targz-src-pkg - Build perf-3.10.0.tar.gz source tarball
perf-tarbz2-src-pkg - Build perf-3.10.0.tar.bz2 source tarball
perf-tarxz-src-pkg - Build perf-3.10.0.tar.xz source tarball
Documentation targets:
Linux kernel internal documentation in different formats:
htmldocs - HTML
pdfdocs - PDF
psdocs - Postscript
xmldocs - XML DocBook
mandocs - man pages
installmandocs - install man pages generated by mandocs
cleandocs - clean all generated DocBook files
Architecture specific targets (arm):
* zImage - Compressed kernel image (arch/arm/boot/zImage)
Image - Uncompressed kernel image (arch/arm/boot/Image)
* xipImage - XIP kernel image, if configured (arch/arm/boot/xipImage)
uImage - U-Boot wrapped zImage
bootpImage - Combined zImage and initial RAM disk
(supply initrd image via make variable INITRD=<path>)
* dtbs - Build device tree blobs for enabled boards
install - Install uncompressed kernel
zinstall - Install compressed kernel
uinstall - Install U-Boot wrapped compressed kernel
Install using (your) ~/bin/installkernel or
(distribution) /sbin/installkernel or
install to $(INSTALL_PATH) and run lilo内容非常之多。这里只介绍几个常用的：
make menuconfig 图形化配置 config
make uImage 编译生成 uImage
make clean 删除大部分生成的文件，但是保留配置，以便可以编译模块
make distclean 删除所有生成的文件，补丁和配置，以及一些备份文件
make mrproper 删除所有生成的文件，补丁和配置
总的来说，顶层 Makefile 文件读取 config 文件生成 Linux 的两大目标文件 vmlinux 和 模块文件
原文地址：http://blog.csdn.net/jingxia2008/article/details/30262853
