1====================== 2Linux Kernel Makefiles 3====================== 4 5This document describes the Linux kernel Makefiles. 6 7.. Table of Contents 8 9 === 1 Overview 10 === 2 Who does what 11 === 3 The kbuild files 12 --- 3.1 Goal definitions 13 --- 3.2 Built-in object goals - obj-y 14 --- 3.3 Loadable module goals - obj-m 15 --- 3.4 Objects which export symbols 16 --- 3.5 Library file goals - lib-y 17 --- 3.6 Descending down in directories 18 --- 3.7 Compilation flags 19 --- 3.8 Command line dependency 20 --- 3.9 Dependency tracking 21 --- 3.10 Special Rules 22 --- 3.11 $(CC) support functions 23 --- 3.12 $(LD) support functions 24 25 === 4 Host Program support 26 --- 4.1 Simple Host Program 27 --- 4.2 Composite Host Programs 28 --- 4.3 Using C++ for host programs 29 --- 4.4 Controlling compiler options for host programs 30 --- 4.5 When host programs are actually built 31 --- 4.6 Using hostprogs-$(CONFIG_FOO) 32 33 === 5 Kbuild clean infrastructure 34 35 === 6 Architecture Makefiles 36 --- 6.1 Set variables to tweak the build to the architecture 37 --- 6.2 Add prerequisites to archheaders: 38 --- 6.3 Add prerequisites to archprepare: 39 --- 6.4 List directories to visit when descending 40 --- 6.5 Architecture-specific boot images 41 --- 6.6 Building non-kbuild targets 42 --- 6.7 Commands useful for building a boot image 43 --- 6.8 Custom kbuild commands 44 --- 6.9 Preprocessing linker scripts 45 --- 6.10 Generic header files 46 --- 6.11 Post-link pass 47 48 === 7 Kbuild syntax for exported headers 49 --- 7.1 no-export-headers 50 --- 7.2 generic-y 51 --- 7.3 generated-y 52 --- 7.4 mandatory-y 53 54 === 8 Kbuild Variables 55 === 9 Makefile language 56 === 10 Credits 57 === 11 TODO 58 591 Overview 60========== 61 62The Makefiles have five parts:: 63 64 Makefile the top Makefile. 65 .config the kernel configuration file. 66 arch/$(ARCH)/Makefile the arch Makefile. 67 scripts/Makefile.* common rules etc. for all kbuild Makefiles. 68 kbuild Makefiles there are about 500 of these. 69 70The top Makefile reads the .config file, which comes from the kernel 71configuration process. 72 73The top Makefile is responsible for building two major products: vmlinux 74(the resident kernel image) and modules (any module files). 75It builds these goals by recursively descending into the subdirectories of 76the kernel source tree. 77The list of subdirectories which are visited depends upon the kernel 78configuration. The top Makefile textually includes an arch Makefile 79with the name arch/$(ARCH)/Makefile. The arch Makefile supplies 80architecture-specific information to the top Makefile. 81 82Each subdirectory has a kbuild Makefile which carries out the commands 83passed down from above. The kbuild Makefile uses information from the 84.config file to construct various file lists used by kbuild to build 85any built-in or modular targets. 86 87scripts/Makefile.* contains all the definitions/rules etc. that 88are used to build the kernel based on the kbuild makefiles. 89 90 912 Who does what 92=============== 93 94People have four different relationships with the kernel Makefiles. 95 96*Users* are people who build kernels. These people type commands such as 97"make menuconfig" or "make". They usually do not read or edit 98any kernel Makefiles (or any other source files). 99 100*Normal developers* are people who work on features such as device 101drivers, file systems, and network protocols. These people need to 102maintain the kbuild Makefiles for the subsystem they are 103working on. In order to do this effectively, they need some overall 104knowledge about the kernel Makefiles, plus detailed knowledge about the 105public interface for kbuild. 106 107*Arch developers* are people who work on an entire architecture, such 108as sparc or ia64. Arch developers need to know about the arch Makefile 109as well as kbuild Makefiles. 110 111*Kbuild developers* are people who work on the kernel build system itself. 112These people need to know about all aspects of the kernel Makefiles. 113 114This document is aimed towards normal developers and arch developers. 115 116 1173 The kbuild files 118================== 119 120Most Makefiles within the kernel are kbuild Makefiles that use the 121kbuild infrastructure. This chapter introduces the syntax used in the 122kbuild makefiles. 123The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can 124be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild' 125file will be used. 126 127Section 3.1 "Goal definitions" is a quick intro, further chapters provide 128more details, with real examples. 129 1303.1 Goal definitions 131-------------------- 132 133 Goal definitions are the main part (heart) of the kbuild Makefile. 134 These lines define the files to be built, any special compilation 135 options, and any subdirectories to be entered recursively. 136 137 The most simple kbuild makefile contains one line: 138 139 Example:: 140 141 obj-y += foo.o 142 143 This tells kbuild that there is one object in that directory, named 144 foo.o. foo.o will be built from foo.c or foo.S. 145 146 If foo.o shall be built as a module, the variable obj-m is used. 147 Therefore the following pattern is often used: 148 149 Example:: 150 151 obj-$(CONFIG_FOO) += foo.o 152 153 $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module). 154 If CONFIG_FOO is neither y nor m, then the file will not be compiled 155 nor linked. 156 1573.2 Built-in object goals - obj-y 158--------------------------------- 159 160 The kbuild Makefile specifies object files for vmlinux 161 in the $(obj-y) lists. These lists depend on the kernel 162 configuration. 163 164 Kbuild compiles all the $(obj-y) files. It then calls 165 "$(AR) rcSTP" to merge these files into one built-in.a file. 166 This is a thin archive without a symbol table. It will be later 167 linked into vmlinux by scripts/link-vmlinux.sh 168 169 The order of files in $(obj-y) is significant. Duplicates in 170 the lists are allowed: the first instance will be linked into 171 built-in.a and succeeding instances will be ignored. 172 173 Link order is significant, because certain functions 174 (module_init() / __initcall) will be called during boot in the 175 order they appear. So keep in mind that changing the link 176 order may e.g. change the order in which your SCSI 177 controllers are detected, and thus your disks are renumbered. 178 179 Example:: 180 181 #drivers/isdn/i4l/Makefile 182 # Makefile for the kernel ISDN subsystem and device drivers. 183 # Each configuration option enables a list of files. 184 obj-$(CONFIG_ISDN_I4L) += isdn.o 185 obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o 186 1873.3 Loadable module goals - obj-m 188--------------------------------- 189 190 $(obj-m) specifies object files which are built as loadable 191 kernel modules. 192 193 A module may be built from one source file or several source 194 files. In the case of one source file, the kbuild makefile 195 simply adds the file to $(obj-m). 196 197 Example:: 198 199 #drivers/isdn/i4l/Makefile 200 obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o 201 202 Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm' 203 204 If a kernel module is built from several source files, you specify 205 that you want to build a module in the same way as above; however, 206 kbuild needs to know which object files you want to build your 207 module from, so you have to tell it by setting a $(<module_name>-y) 208 variable. 209 210 Example:: 211 212 #drivers/isdn/i4l/Makefile 213 obj-$(CONFIG_ISDN_I4L) += isdn.o 214 isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o 215 216 In this example, the module name will be isdn.o. Kbuild will 217 compile the objects listed in $(isdn-y) and then run 218 "$(LD) -r" on the list of these files to generate isdn.o. 219 220 Due to kbuild recognizing $(<module_name>-y) for composite objects, 221 you can use the value of a `CONFIG_` symbol to optionally include an 222 object file as part of a composite object. 223 224 Example:: 225 226 #fs/ext2/Makefile 227 obj-$(CONFIG_EXT2_FS) += ext2.o 228 ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ 229 namei.o super.o symlink.o 230 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ 231 xattr_trusted.o 232 233 In this example, xattr.o, xattr_user.o and xattr_trusted.o are only 234 part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) 235 evaluates to 'y'. 236 237 Note: Of course, when you are building objects into the kernel, 238 the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, 239 kbuild will build an ext2.o file for you out of the individual 240 parts and then link this into built-in.a, as you would expect. 241 2423.4 Objects which export symbols 243-------------------------------- 244 245 No special notation is required in the makefiles for 246 modules exporting symbols. 247 2483.5 Library file goals - lib-y 249------------------------------ 250 251 Objects listed with obj-* are used for modules, or 252 combined in a built-in.a for that specific directory. 253 There is also the possibility to list objects that will 254 be included in a library, lib.a. 255 All objects listed with lib-y are combined in a single 256 library for that directory. 257 Objects that are listed in obj-y and additionally listed in 258 lib-y will not be included in the library, since they will 259 be accessible anyway. 260 For consistency, objects listed in lib-m will be included in lib.a. 261 262 Note that the same kbuild makefile may list files to be built-in 263 and to be part of a library. Therefore the same directory 264 may contain both a built-in.a and a lib.a file. 265 266 Example:: 267 268 #arch/x86/lib/Makefile 269 lib-y := delay.o 270 271 This will create a library lib.a based on delay.o. For kbuild to 272 actually recognize that there is a lib.a being built, the directory 273 shall be listed in libs-y. 274 275 See also "6.4 List directories to visit when descending". 276 277 Use of lib-y is normally restricted to `lib/` and `arch/*/lib`. 278 2793.6 Descending down in directories 280---------------------------------- 281 282 A Makefile is only responsible for building objects in its own 283 directory. Files in subdirectories should be taken care of by 284 Makefiles in these subdirs. The build system will automatically 285 invoke make recursively in subdirectories, provided you let it know of 286 them. 287 288 To do so, obj-y and obj-m are used. 289 ext2 lives in a separate directory, and the Makefile present in fs/ 290 tells kbuild to descend down using the following assignment. 291 292 Example:: 293 294 #fs/Makefile 295 obj-$(CONFIG_EXT2_FS) += ext2/ 296 297 If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular) 298 the corresponding obj- variable will be set, and kbuild will descend 299 down in the ext2 directory. 300 301 Kbuild uses this information not only to decide that it needs to visit 302 the directory, but also to decide whether or not to link objects from 303 the directory into vmlinux. 304 305 When Kbuild descends into the directory with 'y', all built-in objects 306 from that directory are combined into the built-in.a, which will be 307 eventually linked into vmlinux. 308 309 When Kbuild descends into the directory with 'm', in contrast, nothing 310 from that directory will be linked into vmlinux. If the Makefile in 311 that directory specifies obj-y, those objects will be left orphan. 312 It is very likely a bug of the Makefile or of dependencies in Kconfig. 313 314 It is good practice to use a `CONFIG_` variable when assigning directory 315 names. This allows kbuild to totally skip the directory if the 316 corresponding `CONFIG_` option is neither 'y' nor 'm'. 317 3183.7 Compilation flags 319--------------------- 320 321 ccflags-y, asflags-y and ldflags-y 322 These three flags apply only to the kbuild makefile in which they 323 are assigned. They are used for all the normal cc, as and ld 324 invocations happening during a recursive build. 325 Note: Flags with the same behaviour were previously named: 326 EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. 327 They are still supported but their usage is deprecated. 328 329 ccflags-y specifies options for compiling with $(CC). 330 331 Example:: 332 333 # drivers/acpi/acpica/Makefile 334 ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA 335 ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT 336 337 This variable is necessary because the top Makefile owns the 338 variable $(KBUILD_CFLAGS) and uses it for compilation flags for the 339 entire tree. 340 341 asflags-y specifies assembler options. 342 343 Example:: 344 345 #arch/sparc/kernel/Makefile 346 asflags-y := -ansi 347 348 ldflags-y specifies options for linking with $(LD). 349 350 Example:: 351 352 #arch/cris/boot/compressed/Makefile 353 ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds 354 355 subdir-ccflags-y, subdir-asflags-y 356 The two flags listed above are similar to ccflags-y and asflags-y. 357 The difference is that the subdir- variants have effect for the kbuild 358 file where they are present and all subdirectories. 359 Options specified using subdir-* are added to the commandline before 360 the options specified using the non-subdir variants. 361 362 Example:: 363 364 subdir-ccflags-y := -Werror 365 366 CFLAGS_$@, AFLAGS_$@ 367 CFLAGS_$@ and AFLAGS_$@ only apply to commands in current 368 kbuild makefile. 369 370 $(CFLAGS_$@) specifies per-file options for $(CC). The $@ 371 part has a literal value which specifies the file that it is for. 372 373 Example:: 374 375 # drivers/scsi/Makefile 376 CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF 377 CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \ 378 -DGDTH_STATISTICS 379 380 These two lines specify compilation flags for aha152x.o and gdth.o. 381 382 $(AFLAGS_$@) is a similar feature for source files in assembly 383 languages. 384 385 Example:: 386 387 # arch/arm/kernel/Makefile 388 AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) 389 AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 390 AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt 391 392 3933.9 Dependency tracking 394----------------------- 395 396 Kbuild tracks dependencies on the following: 397 398 1) All prerequisite files (both `*.c` and `*.h`) 399 2) `CONFIG_` options used in all prerequisite files 400 3) Command-line used to compile target 401 402 Thus, if you change an option to $(CC) all affected files will 403 be re-compiled. 404 4053.10 Special Rules 406------------------ 407 408 Special rules are used when the kbuild infrastructure does 409 not provide the required support. A typical example is 410 header files generated during the build process. 411 Another example are the architecture-specific Makefiles which 412 need special rules to prepare boot images etc. 413 414 Special rules are written as normal Make rules. 415 Kbuild is not executing in the directory where the Makefile is 416 located, so all special rules shall provide a relative 417 path to prerequisite files and target files. 418 419 Two variables are used when defining special rules: 420 421 $(src) 422 $(src) is a relative path which points to the directory 423 where the Makefile is located. Always use $(src) when 424 referring to files located in the src tree. 425 426 $(obj) 427 $(obj) is a relative path which points to the directory 428 where the target is saved. Always use $(obj) when 429 referring to generated files. 430 431 Example:: 432 433 #drivers/scsi/Makefile 434 $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl 435 $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl 436 437 This is a special rule, following the normal syntax 438 required by make. 439 440 The target file depends on two prerequisite files. References 441 to the target file are prefixed with $(obj), references 442 to prerequisites are referenced with $(src) (because they are not 443 generated files). 444 445 $(kecho) 446 echoing information to user in a rule is often a good practice 447 but when execution "make -s" one does not expect to see any output 448 except for warnings/errors. 449 To support this kbuild defines $(kecho) which will echo out the 450 text following $(kecho) to stdout except if "make -s" is used. 451 452 Example:: 453 454 #arch/blackfin/boot/Makefile 455 $(obj)/vmImage: $(obj)/vmlinux.gz 456 $(call if_changed,uimage) 457 @$(kecho) 'Kernel: $@ is ready' 458 459 4603.11 $(CC) support functions 461---------------------------- 462 463 The kernel may be built with several different versions of 464 $(CC), each supporting a unique set of features and options. 465 kbuild provides basic support to check for valid options for $(CC). 466 $(CC) is usually the gcc compiler, but other alternatives are 467 available. 468 469 as-option 470 as-option is used to check if $(CC) -- when used to compile 471 assembler (`*.S`) files -- supports the given option. An optional 472 second option may be specified if the first option is not supported. 473 474 Example:: 475 476 #arch/sh/Makefile 477 cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),) 478 479 In the above example, cflags-y will be assigned the option 480 -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC). 481 The second argument is optional, and if supplied will be used 482 if first argument is not supported. 483 484 as-instr 485 as-instr checks if the assembler reports a specific instruction 486 and then outputs either option1 or option2 487 C escapes are supported in the test instruction 488 Note: as-instr-option uses KBUILD_AFLAGS for assembler options 489 490 cc-option 491 cc-option is used to check if $(CC) supports a given option, and if 492 not supported to use an optional second option. 493 494 Example:: 495 496 #arch/x86/Makefile 497 cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586) 498 499 In the above example, cflags-y will be assigned the option 500 -march=pentium-mmx if supported by $(CC), otherwise -march=i586. 501 The second argument to cc-option is optional, and if omitted, 502 cflags-y will be assigned no value if first option is not supported. 503 Note: cc-option uses KBUILD_CFLAGS for $(CC) options 504 505 cc-option-yn 506 cc-option-yn is used to check if gcc supports a given option 507 and return 'y' if supported, otherwise 'n'. 508 509 Example:: 510 511 #arch/ppc/Makefile 512 biarch := $(call cc-option-yn, -m32) 513 aflags-$(biarch) += -a32 514 cflags-$(biarch) += -m32 515 516 In the above example, $(biarch) is set to y if $(CC) supports the -m32 517 option. When $(biarch) equals 'y', the expanded variables $(aflags-y) 518 and $(cflags-y) will be assigned the values -a32 and -m32, 519 respectively. 520 Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options 521 522 cc-disable-warning 523 cc-disable-warning checks if gcc supports a given warning and returns 524 the commandline switch to disable it. This special function is needed, 525 because gcc 4.4 and later accept any unknown -Wno-* option and only 526 warn about it if there is another warning in the source file. 527 528 Example:: 529 530 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) 531 532 In the above example, -Wno-unused-but-set-variable will be added to 533 KBUILD_CFLAGS only if gcc really accepts it. 534 535 cc-ifversion 536 cc-ifversion tests the version of $(CC) and equals the fourth parameter 537 if version expression is true, or the fifth (if given) if the version 538 expression is false. 539 540 Example:: 541 542 #fs/reiserfs/Makefile 543 ccflags-y := $(call cc-ifversion, -lt, 0402, -O1) 544 545 In this example, ccflags-y will be assigned the value -O1 if the 546 $(CC) version is less than 4.2. 547 cc-ifversion takes all the shell operators: 548 -eq, -ne, -lt, -le, -gt, and -ge 549 The third parameter may be a text as in this example, but it may also 550 be an expanded variable or a macro. 551 552 cc-cross-prefix 553 cc-cross-prefix is used to check if there exists a $(CC) in path with 554 one of the listed prefixes. The first prefix where there exist a 555 prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found 556 then nothing is returned. 557 Additional prefixes are separated by a single space in the 558 call of cc-cross-prefix. 559 This functionality is useful for architecture Makefiles that try 560 to set CROSS_COMPILE to well-known values but may have several 561 values to select between. 562 It is recommended only to try to set CROSS_COMPILE if it is a cross 563 build (host arch is different from target arch). And if CROSS_COMPILE 564 is already set then leave it with the old value. 565 566 Example:: 567 568 #arch/m68k/Makefile 569 ifneq ($(SUBARCH),$(ARCH)) 570 ifeq ($(CROSS_COMPILE),) 571 CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-) 572 endif 573 endif 574 5753.12 $(LD) support functions 576---------------------------- 577 578 ld-option 579 ld-option is used to check if $(LD) supports the supplied option. 580 ld-option takes two options as arguments. 581 The second argument is an optional option that can be used if the 582 first option is not supported by $(LD). 583 584 Example:: 585 586 #Makefile 587 LDFLAGS_vmlinux += $(call ld-option, -X) 588 589 5904 Host Program support 591====================== 592 593Kbuild supports building executables on the host for use during the 594compilation stage. 595Two steps are required in order to use a host executable. 596 597The first step is to tell kbuild that a host program exists. This is 598done utilising the variable hostprogs-y. 599 600The second step is to add an explicit dependency to the executable. 601This can be done in two ways. Either add the dependency in a rule, 602or utilise the variable $(always). 603Both possibilities are described in the following. 604 6054.1 Simple Host Program 606----------------------- 607 608 In some cases there is a need to compile and run a program on the 609 computer where the build is running. 610 The following line tells kbuild that the program bin2hex shall be 611 built on the build host. 612 613 Example:: 614 615 hostprogs-y := bin2hex 616 617 Kbuild assumes in the above example that bin2hex is made from a single 618 c-source file named bin2hex.c located in the same directory as 619 the Makefile. 620 6214.2 Composite Host Programs 622--------------------------- 623 624 Host programs can be made up based on composite objects. 625 The syntax used to define composite objects for host programs is 626 similar to the syntax used for kernel objects. 627 $(<executable>-objs) lists all objects used to link the final 628 executable. 629 630 Example:: 631 632 #scripts/lxdialog/Makefile 633 hostprogs-y := lxdialog 634 lxdialog-objs := checklist.o lxdialog.o 635 636 Objects with extension .o are compiled from the corresponding .c 637 files. In the above example, checklist.c is compiled to checklist.o 638 and lxdialog.c is compiled to lxdialog.o. 639 640 Finally, the two .o files are linked to the executable, lxdialog. 641 Note: The syntax <executable>-y is not permitted for host-programs. 642 6434.3 Using C++ for host programs 644------------------------------- 645 646 kbuild offers support for host programs written in C++. This was 647 introduced solely to support kconfig, and is not recommended 648 for general use. 649 650 Example:: 651 652 #scripts/kconfig/Makefile 653 hostprogs-y := qconf 654 qconf-cxxobjs := qconf.o 655 656 In the example above the executable is composed of the C++ file 657 qconf.cc - identified by $(qconf-cxxobjs). 658 659 If qconf is composed of a mixture of .c and .cc files, then an 660 additional line can be used to identify this. 661 662 Example:: 663 664 #scripts/kconfig/Makefile 665 hostprogs-y := qconf 666 qconf-cxxobjs := qconf.o 667 qconf-objs := check.o 668 6694.4 Controlling compiler options for host programs 670-------------------------------------------------- 671 672 When compiling host programs, it is possible to set specific flags. 673 The programs will always be compiled utilising $(HOSTCC) passed 674 the options specified in $(KBUILD_HOSTCFLAGS). 675 To set flags that will take effect for all host programs created 676 in that Makefile, use the variable HOST_EXTRACFLAGS. 677 678 Example:: 679 680 #scripts/lxdialog/Makefile 681 HOST_EXTRACFLAGS += -I/usr/include/ncurses 682 683 To set specific flags for a single file the following construction 684 is used: 685 686 Example:: 687 688 #arch/ppc64/boot/Makefile 689 HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE) 690 691 It is also possible to specify additional options to the linker. 692 693 Example:: 694 695 #scripts/kconfig/Makefile 696 HOSTLDLIBS_qconf := -L$(QTDIR)/lib 697 698 When linking qconf, it will be passed the extra option 699 "-L$(QTDIR)/lib". 700 7014.5 When host programs are actually built 702----------------------------------------- 703 704 Kbuild will only build host-programs when they are referenced 705 as a prerequisite. 706 This is possible in two ways: 707 708 (1) List the prerequisite explicitly in a special rule. 709 710 Example:: 711 712 #drivers/pci/Makefile 713 hostprogs-y := gen-devlist 714 $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist 715 ( cd $(obj); ./gen-devlist ) < $< 716 717 The target $(obj)/devlist.h will not be built before 718 $(obj)/gen-devlist is updated. Note that references to 719 the host programs in special rules must be prefixed with $(obj). 720 721 (2) Use $(always) 722 723 When there is no suitable special rule, and the host program 724 shall be built when a makefile is entered, the $(always) 725 variable shall be used. 726 727 Example:: 728 729 #scripts/lxdialog/Makefile 730 hostprogs-y := lxdialog 731 always := $(hostprogs-y) 732 733 This will tell kbuild to build lxdialog even if not referenced in 734 any rule. 735 7364.6 Using hostprogs-$(CONFIG_FOO) 737--------------------------------- 738 739 A typical pattern in a Kbuild file looks like this: 740 741 Example:: 742 743 #scripts/Makefile 744 hostprogs-$(CONFIG_KALLSYMS) += kallsyms 745 746 Kbuild knows about both 'y' for built-in and 'm' for module. 747 So if a config symbol evaluates to 'm', kbuild will still build 748 the binary. In other words, Kbuild handles hostprogs-m exactly 749 like hostprogs-y. But only hostprogs-y is recommended to be used 750 when no CONFIG symbols are involved. 751 7525 Kbuild clean infrastructure 753============================= 754 755"make clean" deletes most generated files in the obj tree where the kernel 756is compiled. This includes generated files such as host programs. 757Kbuild knows targets listed in $(hostprogs-y), $(hostprogs-m), $(always), 758$(extra-y) and $(targets). They are all deleted during "make clean". 759Files matching the patterns "*.[oas]", "*.ko", plus some additional files 760generated by kbuild are deleted all over the kernel src tree when 761"make clean" is executed. 762 763Additional files or directories can be specified in kbuild makefiles by use of 764$(clean-files). 765 766 Example:: 767 768 #lib/Makefile 769 clean-files := crc32table.h 770 771When executing "make clean", the file "crc32table.h" will be deleted. 772Kbuild will assume files to be in the same relative directory as the 773Makefile, except if prefixed with $(objtree). 774 775To exclude certain files or directories from make clean, use the 776$(no-clean-files) variable. 777 778Usually kbuild descends down in subdirectories due to "obj-* := dir/", 779but in the architecture makefiles where the kbuild infrastructure 780is not sufficient this sometimes needs to be explicit. 781 782 Example:: 783 784 #arch/x86/boot/Makefile 785 subdir- := compressed/ 786 787The above assignment instructs kbuild to descend down in the 788directory compressed/ when "make clean" is executed. 789 790To support the clean infrastructure in the Makefiles that build the 791final bootimage there is an optional target named archclean: 792 793 Example:: 794 795 #arch/x86/Makefile 796 archclean: 797 $(Q)$(MAKE) $(clean)=arch/x86/boot 798 799When "make clean" is executed, make will descend down in arch/x86/boot, 800and clean as usual. The Makefile located in arch/x86/boot/ may use 801the subdir- trick to descend further down. 802 803Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is 804included in the top level makefile, and the kbuild infrastructure 805is not operational at that point. 806 807Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will 808be visited during "make clean". 809 8106 Architecture Makefiles 811======================== 812 813The top level Makefile sets up the environment and does the preparation, 814before starting to descend down in the individual directories. 815The top level makefile contains the generic part, whereas 816arch/$(ARCH)/Makefile contains what is required to set up kbuild 817for said architecture. 818To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines 819a few targets. 820 821When kbuild executes, the following steps are followed (roughly): 822 8231) Configuration of the kernel => produce .config 8242) Store kernel version in include/linux/version.h 8253) Updating all other prerequisites to the target prepare: 826 - Additional prerequisites are specified in arch/$(ARCH)/Makefile 8274) Recursively descend down in all directories listed in 828 init-* core* drivers-* net-* libs-* and build all targets. 829 - The values of the above variables are expanded in arch/$(ARCH)/Makefile. 8305) All object files are then linked and the resulting file vmlinux is 831 located at the root of the obj tree. 832 The very first objects linked are listed in head-y, assigned by 833 arch/$(ARCH)/Makefile. 8346) Finally, the architecture-specific part does any required post processing 835 and builds the final bootimage. 836 - This includes building boot records 837 - Preparing initrd images and the like 838 839 8406.1 Set variables to tweak the build to the architecture 841-------------------------------------------------------- 842 843 LDFLAGS 844 Generic $(LD) options 845 846 Flags used for all invocations of the linker. 847 Often specifying the emulation is sufficient. 848 849 Example:: 850 851 #arch/s390/Makefile 852 LDFLAGS := -m elf_s390 853 854 Note: ldflags-y can be used to further customise 855 the flags used. See chapter 3.7. 856 857 LDFLAGS_vmlinux 858 Options for $(LD) when linking vmlinux 859 860 LDFLAGS_vmlinux is used to specify additional flags to pass to 861 the linker when linking the final vmlinux image. 862 LDFLAGS_vmlinux uses the LDFLAGS_$@ support. 863 864 Example:: 865 866 #arch/x86/Makefile 867 LDFLAGS_vmlinux := -e stext 868 869 OBJCOPYFLAGS 870 objcopy flags 871 872 When $(call if_changed,objcopy) is used to translate a .o file, 873 the flags specified in OBJCOPYFLAGS will be used. 874 $(call if_changed,objcopy) is often used to generate raw binaries on 875 vmlinux. 876 877 Example:: 878 879 #arch/s390/Makefile 880 OBJCOPYFLAGS := -O binary 881 882 #arch/s390/boot/Makefile 883 $(obj)/image: vmlinux FORCE 884 $(call if_changed,objcopy) 885 886 In this example, the binary $(obj)/image is a binary version of 887 vmlinux. The usage of $(call if_changed,xxx) will be described later. 888 889 KBUILD_AFLAGS 890 Assembler flags 891 892 Default value - see top level Makefile 893 Append or modify as required per architecture. 894 895 Example:: 896 897 #arch/sparc64/Makefile 898 KBUILD_AFLAGS += -m64 -mcpu=ultrasparc 899 900 KBUILD_CFLAGS 901 $(CC) compiler flags 902 903 Default value - see top level Makefile 904 Append or modify as required per architecture. 905 906 Often, the KBUILD_CFLAGS variable depends on the configuration. 907 908 Example:: 909 910 #arch/x86/boot/compressed/Makefile 911 cflags-$(CONFIG_X86_32) := -march=i386 912 cflags-$(CONFIG_X86_64) := -mcmodel=small 913 KBUILD_CFLAGS += $(cflags-y) 914 915 Many arch Makefiles dynamically run the target C compiler to 916 probe supported options:: 917 918 #arch/x86/Makefile 919 920 ... 921 cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\ 922 -march=pentium2,-march=i686) 923 ... 924 # Disable unit-at-a-time mode ... 925 KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time) 926 ... 927 928 929 The first example utilises the trick that a config option expands 930 to 'y' when selected. 931 932 KBUILD_AFLAGS_KERNEL 933 Assembler options specific for built-in 934 935 $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile 936 resident kernel code. 937 938 KBUILD_AFLAGS_MODULE 939 Assembler options specific for modules 940 941 $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that 942 are used for assembler. 943 944 From commandline AFLAGS_MODULE shall be used (see kbuild.txt). 945 946 KBUILD_CFLAGS_KERNEL 947 $(CC) options specific for built-in 948 949 $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile 950 resident kernel code. 951 952 KBUILD_CFLAGS_MODULE 953 Options for $(CC) when building modules 954 955 $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that 956 are used for $(CC). 957 From commandline CFLAGS_MODULE shall be used (see kbuild.txt). 958 959 KBUILD_LDFLAGS_MODULE 960 Options for $(LD) when linking modules 961 962 $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options 963 used when linking modules. This is often a linker script. 964 965 From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). 966 967 KBUILD_LDS 968 969 The linker script with full path. Assigned by the top-level Makefile. 970 971 KBUILD_LDS_MODULE 972 973 The module linker script with full path. Assigned by the top-level 974 Makefile and additionally by the arch Makefile. 975 976 KBUILD_VMLINUX_OBJS 977 978 All object files for vmlinux. They are linked to vmlinux in the same 979 order as listed in KBUILD_VMLINUX_OBJS. 980 981 KBUILD_VMLINUX_LIBS 982 983 All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and 984 KBUILD_VMLINUX_LIBS together specify all the object files used to 985 link vmlinux. 986 9876.2 Add prerequisites to archheaders 988------------------------------------ 989 990 The archheaders: rule is used to generate header files that 991 may be installed into user space by "make header_install". 992 993 It is run before "make archprepare" when run on the 994 architecture itself. 995 996 9976.3 Add prerequisites to archprepare 998------------------------------------ 999 1000 The archprepare: rule is used to list prerequisites that need to be 1001 built before starting to descend down in the subdirectories. 1002 This is usually used for header files containing assembler constants. 1003 1004 Example:: 1005 1006 #arch/arm/Makefile 1007 archprepare: maketools 1008 1009 In this example, the file target maketools will be processed 1010 before descending down in the subdirectories. 1011 See also chapter XXX-TODO that describe how kbuild supports 1012 generating offset header files. 1013 1014 10156.4 List directories to visit when descending 1016--------------------------------------------- 1017 1018 An arch Makefile cooperates with the top Makefile to define variables 1019 which specify how to build the vmlinux file. Note that there is no 1020 corresponding arch-specific section for modules; the module-building 1021 machinery is all architecture-independent. 1022 1023 1024 head-y, init-y, core-y, libs-y, drivers-y, net-y 1025 $(head-y) lists objects to be linked first in vmlinux. 1026 1027 $(libs-y) lists directories where a lib.a archive can be located. 1028 1029 The rest list directories where a built-in.a object file can be 1030 located. 1031 1032 $(init-y) objects will be located after $(head-y). 1033 1034 Then the rest follows in this order: 1035 1036 $(core-y), $(libs-y), $(drivers-y) and $(net-y). 1037 1038 The top level Makefile defines values for all generic directories, 1039 and arch/$(ARCH)/Makefile only adds architecture-specific 1040 directories. 1041 1042 Example:: 1043 1044 #arch/sparc64/Makefile 1045 core-y += arch/sparc64/kernel/ 1046 libs-y += arch/sparc64/prom/ arch/sparc64/lib/ 1047 drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/ 1048 1049 10506.5 Architecture-specific boot images 1051------------------------------------- 1052 1053 An arch Makefile specifies goals that take the vmlinux file, compress 1054 it, wrap it in bootstrapping code, and copy the resulting files 1055 somewhere. This includes various kinds of installation commands. 1056 The actual goals are not standardized across architectures. 1057 1058 It is common to locate any additional processing in a boot/ 1059 directory below arch/$(ARCH)/. 1060 1061 Kbuild does not provide any smart way to support building a 1062 target specified in boot/. Therefore arch/$(ARCH)/Makefile shall 1063 call make manually to build a target in boot/. 1064 1065 The recommended approach is to include shortcuts in 1066 arch/$(ARCH)/Makefile, and use the full path when calling down 1067 into the arch/$(ARCH)/boot/Makefile. 1068 1069 Example:: 1070 1071 #arch/x86/Makefile 1072 boot := arch/x86/boot 1073 bzImage: vmlinux 1074 $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ 1075 1076 "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke 1077 make in a subdirectory. 1078 1079 There are no rules for naming architecture-specific targets, 1080 but executing "make help" will list all relevant targets. 1081 To support this, $(archhelp) must be defined. 1082 1083 Example:: 1084 1085 #arch/x86/Makefile 1086 define archhelp 1087 echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)' 1088 endif 1089 1090 When make is executed without arguments, the first goal encountered 1091 will be built. In the top level Makefile the first goal present 1092 is all:. 1093 An architecture shall always, per default, build a bootable image. 1094 In "make help", the default goal is highlighted with a '*'. 1095 Add a new prerequisite to all: to select a default goal different 1096 from vmlinux. 1097 1098 Example:: 1099 1100 #arch/x86/Makefile 1101 all: bzImage 1102 1103 When "make" is executed without arguments, bzImage will be built. 1104 11056.6 Building non-kbuild targets 1106------------------------------- 1107 1108 extra-y 1109 extra-y specifies additional targets created in the current 1110 directory, in addition to any targets specified by `obj-*`. 1111 1112 Listing all targets in extra-y is required for two purposes: 1113 1114 1) Enable kbuild to check changes in command lines 1115 1116 - When $(call if_changed,xxx) is used 1117 1118 2) kbuild knows what files to delete during "make clean" 1119 1120 Example:: 1121 1122 #arch/x86/kernel/Makefile 1123 extra-y := head.o init_task.o 1124 1125 In this example, extra-y is used to list object files that 1126 shall be built, but shall not be linked as part of built-in.a. 1127 11286.7 Commands useful for building a boot image 1129--------------------------------------------- 1130 1131 Kbuild provides a few macros that are useful when building a 1132 boot image. 1133 1134 if_changed 1135 if_changed is the infrastructure used for the following commands. 1136 1137 Usage:: 1138 1139 target: source(s) FORCE 1140 $(call if_changed,ld/objcopy/gzip/...) 1141 1142 When the rule is evaluated, it is checked to see if any files 1143 need an update, or the command line has changed since the last 1144 invocation. The latter will force a rebuild if any options 1145 to the executable have changed. 1146 Any target that utilises if_changed must be listed in $(targets), 1147 otherwise the command line check will fail, and the target will 1148 always be built. 1149 Assignments to $(targets) are without $(obj)/ prefix. 1150 if_changed may be used in conjunction with custom commands as 1151 defined in 6.8 "Custom kbuild commands". 1152 1153 Note: It is a typical mistake to forget the FORCE prerequisite. 1154 Another common pitfall is that whitespace is sometimes 1155 significant; for instance, the below will fail (note the extra space 1156 after the comma):: 1157 1158 target: source(s) FORCE 1159 1160 **WRONG!** $(call if_changed, ld/objcopy/gzip/...) 1161 1162 Note: 1163 if_changed should not be used more than once per target. 1164 It stores the executed command in a corresponding .cmd 1165 1166 file and multiple calls would result in overwrites and 1167 unwanted results when the target is up to date and only the 1168 tests on changed commands trigger execution of commands. 1169 1170 ld 1171 Link target. Often, LDFLAGS_$@ is used to set specific options to ld. 1172 1173 Example:: 1174 1175 #arch/x86/boot/Makefile 1176 LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary 1177 LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext 1178 1179 targets += setup setup.o bootsect bootsect.o 1180 $(obj)/setup $(obj)/bootsect: %: %.o FORCE 1181 $(call if_changed,ld) 1182 1183 In this example, there are two possible targets, requiring different 1184 options to the linker. The linker options are specified using the 1185 LDFLAGS_$@ syntax - one for each potential target. 1186 $(targets) are assigned all potential targets, by which kbuild knows 1187 the targets and will: 1188 1189 1) check for commandline changes 1190 2) delete target during make clean 1191 1192 The ": %: %.o" part of the prerequisite is a shorthand that 1193 frees us from listing the setup.o and bootsect.o files. 1194 1195 Note: 1196 It is a common mistake to forget the "targets :=" assignment, 1197 resulting in the target file being recompiled for no 1198 obvious reason. 1199 1200 objcopy 1201 Copy binary. Uses OBJCOPYFLAGS usually specified in 1202 arch/$(ARCH)/Makefile. 1203 OBJCOPYFLAGS_$@ may be used to set additional options. 1204 1205 gzip 1206 Compress target. Use maximum compression to compress target. 1207 1208 Example:: 1209 1210 #arch/x86/boot/compressed/Makefile 1211 $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE 1212 $(call if_changed,gzip) 1213 1214 dtc 1215 Create flattened device tree blob object suitable for linking 1216 into vmlinux. Device tree blobs linked into vmlinux are placed 1217 in an init section in the image. Platform code *must* copy the 1218 blob to non-init memory prior to calling unflatten_device_tree(). 1219 1220 To use this command, simply add `*.dtb` into obj-y or targets, or make 1221 some other target depend on `%.dtb` 1222 1223 A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`; 1224 architecture Makefiles do no need to explicitly write out that rule. 1225 1226 Example:: 1227 1228 targets += $(dtb-y) 1229 DTC_FLAGS ?= -p 1024 1230 12316.8 Custom kbuild commands 1232-------------------------- 1233 1234 When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand 1235 of a command is normally displayed. 1236 To enable this behaviour for custom commands kbuild requires 1237 two variables to be set:: 1238 1239 quiet_cmd_<command> - what shall be echoed 1240 cmd_<command> - the command to execute 1241 1242 Example:: 1243 1244 # 1245 quiet_cmd_image = BUILD $@ 1246 cmd_image = $(obj)/tools/build $(BUILDFLAGS) \ 1247 $(obj)/vmlinux.bin > $@ 1248 1249 targets += bzImage 1250 $(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE 1251 $(call if_changed,image) 1252 @echo 'Kernel: $@ is ready' 1253 1254 When updating the $(obj)/bzImage target, the line: 1255 1256 BUILD arch/x86/boot/bzImage 1257 1258 will be displayed with "make KBUILD_VERBOSE=0". 1259 1260 1261--- 6.9 Preprocessing linker scripts 1262 1263 When the vmlinux image is built, the linker script 1264 arch/$(ARCH)/kernel/vmlinux.lds is used. 1265 The script is a preprocessed variant of the file vmlinux.lds.S 1266 located in the same directory. 1267 kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`. 1268 1269 Example:: 1270 1271 #arch/x86/kernel/Makefile 1272 always := vmlinux.lds 1273 1274 #Makefile 1275 export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH) 1276 1277 The assignment to $(always) is used to tell kbuild to build the 1278 target vmlinux.lds. 1279 The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the 1280 specified options when building the target vmlinux.lds. 1281 1282 When building the `*.lds` target, kbuild uses the variables:: 1283 1284 KBUILD_CPPFLAGS : Set in top-level Makefile 1285 cppflags-y : May be set in the kbuild makefile 1286 CPPFLAGS_$(@F) : Target-specific flags. 1287 Note that the full filename is used in this 1288 assignment. 1289 1290 The kbuild infrastructure for `*lds` files is used in several 1291 architecture-specific files. 1292 12936.10 Generic header files 1294------------------------- 1295 1296 The directory include/asm-generic contains the header files 1297 that may be shared between individual architectures. 1298 The recommended approach how to use a generic header file is 1299 to list the file in the Kbuild file. 1300 See "7.2 generic-y" for further info on syntax etc. 1301 13026.11 Post-link pass 1303------------------- 1304 1305 If the file arch/xxx/Makefile.postlink exists, this makefile 1306 will be invoked for post-link objects (vmlinux and modules.ko) 1307 for architectures to run post-link passes on. Must also handle 1308 the clean target. 1309 1310 This pass runs after kallsyms generation. If the architecture 1311 needs to modify symbol locations, rather than manipulate the 1312 kallsyms, it may be easier to add another postlink target for 1313 .tmp_vmlinux? targets to be called from link-vmlinux.sh. 1314 1315 For example, powerpc uses this to check relocation sanity of 1316 the linked vmlinux file. 1317 13187 Kbuild syntax for exported headers 1319------------------------------------ 1320 1321The kernel includes a set of headers that is exported to userspace. 1322Many headers can be exported as-is but other headers require a 1323minimal pre-processing before they are ready for user-space. 1324The pre-processing does: 1325 1326- drop kernel-specific annotations 1327- drop include of compiler.h 1328- drop all sections that are kernel internal (guarded by `ifdef __KERNEL__`) 1329 1330All headers under include/uapi/, include/generated/uapi/, 1331arch/<arch>/include/uapi/ and arch/<arch>/include/generated/uapi/ 1332are exported. 1333 1334A Kbuild file may be defined under arch/<arch>/include/uapi/asm/ and 1335arch/<arch>/include/asm/ to list asm files coming from asm-generic. 1336See subsequent chapter for the syntax of the Kbuild file. 1337 13387.1 no-export-headers 1339--------------------- 1340 1341 no-export-headers is essentially used by include/uapi/linux/Kbuild to 1342 avoid exporting specific headers (e.g. kvm.h) on architectures that do 1343 not support it. It should be avoided as much as possible. 1344 13457.2 generic-y 1346------------- 1347 1348 If an architecture uses a verbatim copy of a header from 1349 include/asm-generic then this is listed in the file 1350 arch/$(ARCH)/include/asm/Kbuild like this: 1351 1352 Example:: 1353 1354 #arch/x86/include/asm/Kbuild 1355 generic-y += termios.h 1356 generic-y += rtc.h 1357 1358 During the prepare phase of the build a wrapper include 1359 file is generated in the directory:: 1360 1361 arch/$(ARCH)/include/generated/asm 1362 1363 When a header is exported where the architecture uses 1364 the generic header a similar wrapper is generated as part 1365 of the set of exported headers in the directory:: 1366 1367 usr/include/asm 1368 1369 The generated wrapper will in both cases look like the following: 1370 1371 Example: termios.h:: 1372 1373 #include <asm-generic/termios.h> 1374 13757.3 generated-y 1376--------------- 1377 1378 If an architecture generates other header files alongside generic-y 1379 wrappers, generated-y specifies them. 1380 1381 This prevents them being treated as stale asm-generic wrappers and 1382 removed. 1383 1384 Example:: 1385 1386 #arch/x86/include/asm/Kbuild 1387 generated-y += syscalls_32.h 1388 13897.4 mandatory-y 1390--------------- 1391 1392 mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild 1393 to define the minimum set of ASM headers that all architectures must have. 1394 1395 This works like optional generic-y. If a mandatory header is missing 1396 in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate 1397 a wrapper of the asm-generic one. 1398 1399 The convention is to list one subdir per line and 1400 preferably in alphabetic order. 1401 14028 Kbuild Variables 1403================== 1404 1405The top Makefile exports the following variables: 1406 1407 VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION 1408 These variables define the current kernel version. A few arch 1409 Makefiles actually use these values directly; they should use 1410 $(KERNELRELEASE) instead. 1411 1412 $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic 1413 three-part version number, such as "2", "4", and "0". These three 1414 values are always numeric. 1415 1416 $(EXTRAVERSION) defines an even tinier sublevel for pre-patches 1417 or additional patches. It is usually some non-numeric string 1418 such as "-pre4", and is often blank. 1419 1420 KERNELRELEASE 1421 $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable 1422 for constructing installation directory names or showing in 1423 version strings. Some arch Makefiles use it for this purpose. 1424 1425 ARCH 1426 This variable defines the target architecture, such as "i386", 1427 "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to 1428 determine which files to compile. 1429 1430 By default, the top Makefile sets $(ARCH) to be the same as the 1431 host system architecture. For a cross build, a user may 1432 override the value of $(ARCH) on the command line:: 1433 1434 make ARCH=m68k ... 1435 1436 1437 INSTALL_PATH 1438 This variable defines a place for the arch Makefiles to install 1439 the resident kernel image and System.map file. 1440 Use this for architecture-specific install targets. 1441 1442 INSTALL_MOD_PATH, MODLIB 1443 $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module 1444 installation. This variable is not defined in the Makefile but 1445 may be passed in by the user if desired. 1446 1447 $(MODLIB) specifies the directory for module installation. 1448 The top Makefile defines $(MODLIB) to 1449 $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may 1450 override this value on the command line if desired. 1451 1452 INSTALL_MOD_STRIP 1453 If this variable is specified, it will cause modules to be stripped 1454 after they are installed. If INSTALL_MOD_STRIP is '1', then the 1455 default option --strip-debug will be used. Otherwise, the 1456 INSTALL_MOD_STRIP value will be used as the option(s) to the strip 1457 command. 1458 1459 14609 Makefile language 1461=================== 1462 1463The kernel Makefiles are designed to be run with GNU Make. The Makefiles 1464use only the documented features of GNU Make, but they do use many 1465GNU extensions. 1466 1467GNU Make supports elementary list-processing functions. The kernel 1468Makefiles use a novel style of list building and manipulation with few 1469"if" statements. 1470 1471GNU Make has two assignment operators, ":=" and "=". ":=" performs 1472immediate evaluation of the right-hand side and stores an actual string 1473into the left-hand side. "=" is like a formula definition; it stores the 1474right-hand side in an unevaluated form and then evaluates this form each 1475time the left-hand side is used. 1476 1477There are some cases where "=" is appropriate. Usually, though, ":=" 1478is the right choice. 1479 148010 Credits 1481========== 1482 1483- Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net> 1484- Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> 1485- Updates by Sam Ravnborg <sam@ravnborg.org> 1486- Language QA by Jan Engelhardt <jengelh@gmx.de> 1487 148811 TODO 1489======= 1490 1491- Describe how kbuild supports shipped files with _shipped. 1492- Generating offset header files. 1493- Add more variables to section 7? 1494