makefiles.txt

linux 内核源代码

	specified if first option are not supported.

	Example:
		#arch/i386/kernel/Makefile
		vsyscall-flags += $(call ld-option, -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.

    as-instr
	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
	Note: as-instr-option uses KBUILD_AFLAGS for $(AS) options

    cc-option
	cc-option is used to check if $(CC) supports a given option, and not
	supported to use an optional second option.

	Example:
		#arch/i386/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.
	Note: cc-option uses KBUILD_CFLAGS for $(CC) options

   cc-option-yn
	cc-option-yn is used to check if gcc supports a given option
	and return 'y' if supported, otherwise 'n'.

	Example:
		#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-option-align
	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:
	gcc < 3.00
		cc-option-align = -malign
	gcc >= 3.00
		cc-option-align = -falign

	Example:
		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.
	Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options

    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.

	Example:
		#arch/i386/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.

    cc-ifversion
	cc-ifversion tests the version of $(CC) and equals last argument if
	version expression is true.

	Example:
		#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-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.

	Example:
		#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.

    cc-cross-prefix
	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.
	Additional prefixes are separated by a single space in the
	call of 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.
	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.

	Example:
		#arch/m68k/Makefile
		ifneq ($(SUBARCH),$(ARCH))
		        ifeq ($(CROSS_COMPILE),)
		               CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
			endif
		endif

=== 4 Host Program support

Kbuild supports building executables on the host for use during the
compilation stage.
Two steps are required in order to use a host executable.

The first step is to tell kbuild that a host program exists. This is
done utilising the variable 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).
Both possibilities are described in the following.

--- 4.1 Simple Host Program

	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.

	Example:
		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.

--- 4.2 Composite Host Programs

	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.

	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 <executable>-y is not permitted for host-programs.

--- 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.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.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.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 ) < $<

	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).

	(2) Use $(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.

	Example:
		#scripts/lxdialog/Makefile
		hostprogs-y   := lxdialog
		always        := $(hostprogs-y)

	This will tell kbuild to build lxdialog even if not referenced in
	any rule.

--- 4.7 Using hostprogs-$(CONFIG_FOO)

	A typical pattern in a Kbuild file looks like this:

	Example:
		#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.

=== 5 Kbuild clean infrastructure

"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).

	Example:
		#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 '/').

To delete a directory hierarchy use:

	Example:
		#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 '/').

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.

	Example:
		#arch/i386/boot/Makefile
		subdir- := compressed/

The above assignment instructs kbuild to descend down in the
directory compressed/ when "make clean" is executed.

To support the clean infrastructure in the Makefiles that builds the
final bootimage there is an optional target named archclean:

	Example:
		#arch/i386/Makefile
		archclean:
			$(Q)$(MAKE) $(clean)=arch/i386/boot

When "make clean" is executed, make will descend down in arch/i386/boot,
and clean as usual. The Makefile located in arch/i386/boot/ may use
the subdir- trick to descend further down.

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.

Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will
be visited during "make clean".

=== 6 Architecture Makefiles

The top level Makefile sets up the environment and does the preparation,
before starting to descend down in the individual directories.
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.

When kbuild executes, the following steps are followed (roughly):
1) Configuration of the kernel => produce .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 values of the above variables are expanded in 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.
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.1 Set variables to tweak the build to the architecture

    LDFLAGS		Generic $(LD) options

	Flags used for all invocations of the linker.
	Often specifying the emulation is sufficient.

	Example:
		#arch/s390/Makefile
		LDFLAGS         := -m elf_s390
	Note: ldflags-y can be used to further customise
	the flags used. See chapter 3.7.

    LDFLAGS_MODULE	Options for $(LD) when linking modules

	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_vmlinux	Options for $(LD) when linking vmlinux

	LDFLAGS_vmlinux is used to specify additional flags to pass to
	the linker when linking the final vmlinux image.
	LDFLAGS_vmlinux uses the LDFLAGS_$@ support.