
Dear Masahiro Yamada,
This series uses the followings as prerequisites:
- First step towards Kbuild: Use Kbuild style makefiles (19 patch files)
- Second step towards Kbuild: Descend down like Kbuild (6 patch files)
In 'First step towards Kbuild' series, I changed more than 150 makefiles. And in this series, I have changed the remainders, more than 600 makefiles.
After applying first step thru third step, all makefiles under arch/, board/, drivers/, api/, common/, disk/, dts/, fs/, lib/, net/, post/, test/ are converted to Kbuild style.
( doc/, tools/, nand_spl/, example/ have not been changed yet. I'm planning to convert these directories. But I need something prepared before that: hostprogs-y, etc.)
Before converting makefiles to Kbuild style, I want to fix some makefile. This is done in 01/18 and 02/18.
01/18 fixes the link error of sparc architecture. Please see the snippet of arch/sparc/lib/Makefile:
LIB = $(obj)lib$(ARCH).o SOBJS = COBJS = board.o cache.o interrupts.o time.o COBJS-$(CONFIG_CMD_BOOTM) += bootm.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) $(LIB): $(obj).depend $(OBJS) $(call cmd_link_o_target, $(OBJS))
Both COBJS and COBJS-y are used. But this makefile missed to add $(COBJS-y) to OBJS. So, bootm.o is never compiled.
Here, you will notice the advantage of switching to Kbuild style.
Makefiles in sub-directories have very similar form. But there exists a slight difference for each Makefile.
For ex. some makefiles use COBJS and the others use COBJS-y. Some use both of them mixed, and sometimes a mistake like above happens. We should use consistently use obj-y, for both C and Assembler objects.
02/18 fixes arch/sh/cpu/{sh2,sh3,sh4}/Makefile. The snippet is as follows:
LIB = $(obj)lib$(CPU).o SOBJS = start.o COBJS = cpu.o interrupts.o watchdog.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) SOBJS := $(addprefix $(obj),$(SOBJS)) $(LIB): $(OBJS) $(SOBJS) $(call cmd_link_o_target, $(OBJS) $(SOBJS))
start.o is linked into lib$(CPU).o, but it shouldn't.
03/18 thru 15/18 convert arch-specific, board-specific makefiles.
16/18, 17/18 convert commonly used directories.
16/18 shows another big advantage of switching to Kbuild style. Check how simply post/Makefile was re-written by using obj-$(CONFIG-FOO) += foo/ systax.
18/18 convert the rest of makefiles and abolishes the support for U-Boot conventional makefile. After this commit, we cannot use U-Boot style makefiles any more. (exception: doc/, tools/, nand_spl/, example/ directory) Going forward, we must use only Kbuild style makefiles. Take care when you add a new makefile!
Of course, I tested carefully this series. I built as many boards as possible over all architectures.
Here is the site I downloaded the prebuilt crosstools from:
arm, avr32, m68k, mips, openrisc, powerpc, x86: ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/
blackfin, microblaze, nds32, nios2, sh, sparc: http://dev.gentoo.org/~vapier/u-boot/
I could not build some boards because the boards are already broken before this series or the crosstools are not suitable. But I could build more than 1100 target boards and I confirmed this series does no harm.
- 02 thru 18 did not break any boards.
- 02 thru 15 and 17, 18 did not change output ELF files at all. This was check by comparing md5sum.
- It was difficult to simply compare md5sum for patch 16 because it changes how the objects are linked under post/ directory. But I confirmed 16 did not change the section size.
Note: For comparing md5sum, there are some items you should take into account: Disabling time stamp, version, compiling in the same path, linking the objects in the same order... For detailed, refer to [U-Boot] [PATCH 00/19] First step towards Kbuild: Use Kbuild style makefiles Message-Id: 20130917093533.738A.AA925319@jp.panasonic.com
Note2: I confirmed this series can be applied on v2013.10 tag
- First step towards Kbuild: Use Kbuild style makefiles (19 patch files)
- Second step towards Kbuild: Descend down like Kbuild (6 patch files)
Cc: Simon Glass sjg@chromium.org Cc: Tom Rini trini@ti.com Cc: Wolfgang Denk wd@denx.de Cc: Gerhard Sittig gsi@denx.de
[...]
Reviewed-by: Marek Vasut marex@denx.de