[coreboot] [LinuxBIOS] [PATCH] buildrom: add extract andbusybox-config, uclibc-config targets

[Myles Watson]

> 
> I've implemented that - the naming convention for the customconfig files
> is
> now
> 
>   customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)--$(COREBOOT_BOARD)

Nice.

> 
> and in the case of uclibc and the kernel, I've added the architecture in
> there as well:
> 
>   customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-
> $(COREBOOT_BOARD)
>   customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-
> $(COREBOOT_BOARD)
> 
> Custom config files will only be used if the payload, (architecture,)
> vendor
> and board match.

Great!

> 
> If a custom config file is used, buildrom will say so on stdout.
> 
> The *-config commands are a bit smarter now: they will copy an existing
> custom config file back to the source directory so that doing a subsequent
> make something-config will have the effect of editing the custom config,
> rather than overwriting it.
> 
> > I think that could be considered a matter of taste.  Maybe we should add
> the
> > custom-config option for the kernel as well.
> 
> I've added the kernel.
> 


Thanks. 

It's missing the ARCH=$(KERNEL_BUILD_ARCH) on the configure line for kernel
and TARGET_ARCH=$(UCLIBC_BUILD_ARCH) for uclibc.  On my x86_64 box it makes
a 64-bit configuration even for 32-bit targets.  

I'd like it if the verbose messages about using the custom config were
printed after the configuration was done.  I never saw the messages because
make menuconfig is so verbose.

At first I was worried about the dependencies that you added like:

+$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL)
$(FILO_STAMP_DIR) $(FILO_DIR)

I thought it would have the same problem we had before with the stamp
directory being "modified" when the stamps were, and forcing a complete
rebuild, but it didn't seem to happen.  I guess I don't understand that well
enough.

Besides that it looks very good.

Acked-by: Myles Watson <myles at pel.cs.byu.edu>

Myles

> Thanks,
> Ward.
> 
> --
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator