[U-Boot] [PATCH 0/6] Second step towards Kbuild: Descend down like Kbuild

[Masahiro Yamada]

I have been just wondering why the U-Boot top Makefile is so dirty.

It is sprinkled with SoC-specific code as follows:

    ifneq ($(CONFIG_OMAP_COMMON),)
    LIBS-y += $(CPUDIR)/omap-common/libomap-common.o
    endif
    
    ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610))
    LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o
    endif
    
    ifeq ($(SOC),s5pc1xx)
    LIBS-y += $(CPUDIR)/s5p-common/libs5p-common.o
    endif
    ifeq ($(SOC),exynos)
    LIBS-y += $(CPUDIR)/s5p-common/libs5p-common.o
    endif
    ifneq ($(CONFIG_TEGRA),)
    LIBS-y += arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o
    LIBS-y += arch/$(ARCH)/cpu/tegra-common/libcputegra-common.o
    LIBS-y += $(CPUDIR)/tegra-common/libtegra-common.o
    endif

And it describes drivers not right under the top directory, which should be essentially cared
by drivers/Makefile.

    LIBS-y += drivers/bios_emulator/libatibiosemu.o
    LIBS-y += drivers/block/libblock.o
    LIBS-$(CONFIG_BOOTCOUNT_LIMIT) += drivers/bootcount/libbootcount.o
    LIBS-y += drivers/crypto/libcrypto.o
    LIBS-y += drivers/dma/libdma.o
         ...

This series adds the directory descending feature like Kbuild.

0001 tweaks scripts/Makefile.build to support 'obj-y += foo/' syntax.
When the build system find 'foo/' (trailed by a slash),
it visits foo directory.

0002-0006 demonstarate how we can refactor makefiles with this syntax.

  0002: Move some drivers LIBS from top Makefile to drivers/Makefile
  0003: Move some fs LIBS from top Makefile to fs/Makefile
  0004: Move Tegra specific lines from top Makefile under arch/arm
  0005: Move OMAP specific lines from top Makefile under arch/arm
  0006: Move Samsung SoC specific lines from top Makefile under arch/arm

Note:
This series can be applies on v2013.10-rc2 +
'First step towards Kbuild: Use Kbuild-style makefiles' (19 patch files).

Please apply 'First step towards Kbuild: Use Kbuild-style makefiles' first.

I believe no boards are broken by this refactoring, but
it is humans who can make a mistake.
So, it is very important to do build check before patches are applied.

I tested for ARM and sandbox:

    $ CROSS_COMPILE_ARM=arm-linux-gnueabi- ./MAKEALL -a arm -a sandbox

and I got:

    --------------------- SUMMARY ----------------------------
    Boards compiled: 336
    ----------------------------------------------------------

But I can not test other architectures.
I will be grateful for any custodians' help.

Cc: Simon Glass <sjg at chromium.org>
Cc: Tom Rini <trini at ti.com>

Masahiro Yamada (6):
  Makefile: support descending down to subdirectories
  drivers: move some drivers to drivers/Makefile
  fs: move some file system to fs/Makefile
  ARM: tegra: delete Tegra specific code from toplevel Makefile
  ARM: omap: delete OMAP specific code from toplevel Makefile
  ARM: s5pc, exynos: delete Samsung ARM SoC specific code from toplevel
    Makefile

 Makefile                      | 42 +++---------------------------------------
 arch/arm/cpu/Makefile         |  2 ++
 arch/arm/cpu/arm720t/Makefile |  2 ++
 arch/arm/cpu/armv7/Makefile   |  9 +++++++++
 drivers/Makefile              | 13 +++++++++++++
 fs/Makefile                   | 11 +++++++++++
 scripts/Makefile.build        | 15 +++++++++++++++
 spl/Makefile                  | 14 +-------------
 8 files changed, 56 insertions(+), 52 deletions(-)
 create mode 100644 arch/arm/cpu/Makefile
 create mode 100644 drivers/Makefile

-- 
1.8.1.2