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.