[U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files

[Stephen Warren]

On 05/01/2014 04:48 PM, Scott Wood wrote:
> On Mon, 2014-04-28 at 11:47 -0600, Stephen Warren wrote:
>> I guess the main issue I see here is that all the HW-configuration needs
>> to be repeated in seaboard_defconfig and spl/seaboard_defconfig.
>>
>> (As an aside, if there's nothing special about SPL-vs-not and they're
>> just different builds of U-Boot, why put the SPL configurations into a
>> special-case sub-directory, why not name them seaboard_spl_defconfig and
>> seaboard_defconfig, and put them in the same configs directory).
> 
> It's special in that both configs are built and assembled into what
> looks to the user like one output image.
> 
>> Can we allow one defconfig to include or inherit from another? I know
>> that ChromeOS stores kernel defconfigs in "split configs" that build
>> upon each-other. Probably, this feature comes from elsewhere, and we
>> could just crib the config split/combine script for U-Boot's use.
> 
> Yes, that'd be nice.
> 
>>  To make this work, we'd probably need the user to run something like:
>>
>> ./build-u-boot seaboard
>> or:
>> ./build-u-boot seaboard_spl
>>
>> ... rather than running make directly, so that script could generate the
>> .config from a set of defconfigs, and then invoke make.
> 
> Why couldn't the makefile do this when asked to use a board's defconfig?

Indeed, it should. Really, ./build-u-boot for seaboard should do
something like:

* Detect that Seaboard uses SPL (or TPL or ...)
* Build SPL
* Build main U-Boot
* Blend all the build results together

> The user shouldn't need to know about the details of SPL or that there
> are separate sub-builds.  Both seaboard and seaboard_spl would need to
> be built, not one or the other.

Indeed.

>> (as an aside, having the user run a script to build rather than make
>> directly gives us a huge amount more flexibility to add run arbitrary
>> code to set up the build process before invoking make. I've found this
>> kind of thing extremely useful in the past on other projects).
> 
> What arbitrary code do you want to run that can't be run in the config
> makefile target?  There is MAKEALL for users that want a one-step build.

It seems a bit redundant to have the user run make just so that make can
execute some kind of script, when we could simply have the user run the
script directly as the "entry point" into the build process.

Most of these don't apply to U-Boot at all, but I've seen such wrapper
scripts do things like:

* Building multiple targets, and combining them into the overall build
result. This is relevant to SPL/TPL/main U-Boot builds. Admittedly you
can do this with sub-invocations of make, but it often feels cleaner to
me to do the top-level build logic outside make.

* Set up the build environment, e.g. setting CROSS_COMPILE. This would
mainly apply to a more corporate(?) build environment where compilers or
other tools were checked into source control at a known location
relative to the source tree.

* Set up a chroot to perform the build inside of. This isolates the
build process from the host system, allows using standard compilers,
etc. This builds on (sorry for the pun) the above point.

* Set things up to build just the "module" starting at the sub-directory
of `pwd`, rather than the whole directory tree.