[U-Boot] [PATCH] kbuild: move ARCH, CPU, etc. to top Makefile to fix random build error

[Stephen Warren <swarren@wwwdotorg.org>]

On 03/31/2015 06:02 AM, Masahiro Yamada wrote:
> Since the Kconfig conversion, some developers have reported that
> Kbuild sometimes fails completely at random.  According to the error
> reports, it seems to occur for any target board, but only on very
> fast computers.
>
> The log message for the fail case is like this:
>
>    make[1]: *** No rule to make target `../arch//cpu/u-boot.lds',
>    needed by `u-boot.lds'.  Stop.
>
> It looks like the top config.mk has not been included for *some*
> reason, and $(ARCH) has been left blank.
>
> I suspect "autoconf_is_current" is not working in some situation.

That's certainly true. The following code doesn't end up including 
config.mk in the bad case:

> # We want to include arch/$(ARCH)/config.mk only when include/config/auto.conf
> # is up-to-date. When we switch to a different board configuration, old CONFIG
> # macros are still remaining in include/config/auto.conf. Without the following
> # gimmick, wrong config.mk would be included leading nasty warnings/errors.
> autoconf_is_current := $(if $(wildcard $(KCONFIG_CONFIG)),$(shell find . \
> 		-path ./include/config/auto.conf -newer $(KCONFIG_CONFIG)))
> ifneq ($(autoconf_is_current),)
> include $(srctree)/config.mk
> include $(srctree)/arch/$(ARCH)/Makefile
> endif

That's because:

> [swarren at swarren-lx1 tegra-uboot-flasher]$ ls -l --full-time u-boot-*/{.config,include/config/auto.conf}|cat
> -rw-rw-r-- 1 swarren swarren 9219 2015-04-01 15:50:08.000000000 -0600 u-boot-bad/.config
> -rw-rw-r-- 1 swarren swarren  928 2015-04-01 15:50:08.000000000 -0600 u-boot-bad/include/config/auto.conf
> -rw-rw-r-- 1 swarren swarren 9219 2015-04-01 15:51:25.000000000 -0600 u-boot-ok/.config
> -rw-rw-r-- 1 swarren swarren  928 2015-04-01 15:51:26.000000000 -0600 u-boot-ok/include/config/auto.conf

In the bad case, the timestamps are equal (and hence the -newer check 
fails), whereas in the good case they're different. Recall ext* 
filesystems have a 1s timestamp resolution.

Note that this is state left over from "make xxx_defconfig"; If I just 
manually run "make all" in a tree in this state, it'll stay in this 
state forever, and vice-versa for a working tree.

I expect that simulating this condition with some judicious manually 
executed touch commands would be extremely easy.

Possible solutions are:

Is there a -newer-or-equal that could be used in the find command rather 
than -newer?

When running "make xxx_defconfig", can the code there compare the 
timestamp of those two files, and keep looping and touching the 
auto.conf file until the timestamps differ.

Something else entirely? I couldn't see anything relating to 
autoconf_is_current in the kernel's makefiles.