<div dir="ltr">I think the build system could stand some cleanup so that external build would not be needed and building many mainboards in one tree would be easy.<div><div><br></div><div>LinuxBIOS V1 allowed you to build any number of mainboards in one source tree -- it was initially modeled on the BSD</div><div>build system. objects were placed in a tree that followed the mainboard naming conventions.</div><div><br></div><div>We might want to think about getting back to multi-mainboard builds in one tree. Requiring people to use external build or overlayfs is kind of a burden.</div><div><br></div><div>It might be as simple as rewiring the build/ naming to something like</div><div>build/vendor/mainboard</div><div><br></div><div>There's also no fundamental reason for using the name .config other than tradition. We could, for example, create</div><div>build/vendor/mainboard/config and use that. </div><div><br></div><div>Then it's as simple as saying something like</div><div>MAINBOARD=vendor/mainboard make</div><div>and letting the build system figure out the rest. </div><div><br></div><div>You could also</div><div>export MAINBOARD=vendor/mainboard</div><div>when you are doing lots of builds for one mainboard.</div><div><br></div><div>I personally would find this extremely useful. Having to bounce around between the various riscv boards has been</div><div>inconvenient at best. </div><div><br></div><div>I'm willing to do the work if no one objects.</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 20, 2016 at 10:43 AM Trammell Hudson <<a href="mailto:hudson@trmm.net">hudson@trmm.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Nov 13, 2016 at 03:34:49PM -0500, Charlotte Plusplus wrote:<br class="gmail_msg">
> With the cross compiling tool chain, coreboot takes 1G. If you are a bit<br class="gmail_msg">
> short on space, or if you want to save writes to your SSD, instead of<br class="gmail_msg">
> having multiple copies of the coreboot source folder, I have found out<br class="gmail_msg">
> overlayfs is very practical. [...]<br class="gmail_msg">
<br class="gmail_msg">
An alternative is to use the "external build" option if you're building<br class="gmail_msg">
for multiple targets with different .config files for each.  It isn't<br class="gmail_msg">
quite as simple as the Linux kernel's kbuild O= syntax, but works<br class="gmail_msg">
fairly well.<br class="gmail_msg">
<br class="gmail_msg">
I have three main builds that I'm alternating between (x230, chell and qemu)<br class="gmail_msg">
so I've created three directories and have a .config for each stored in<br class="gmail_msg">
a top-level config directory.  From the coreboot directory I can modify<br class="gmail_msg">
the configs and build them independently:<br class="gmail_msg">
<br class="gmail_msg">
        make obj=./x230 DOTCONFIG=./config/x230 menuconfig<br class="gmail_msg">
        make obj=./x230 DOTCONFIG=./config/x230 -j 8<br class="gmail_msg">
<br class="gmail_msg">
The builds will share the same cross build tree, so the actual build<br class="gmail_msg">
output is only 64M per configuration.<br class="gmail_msg">
<br class="gmail_msg">
Also note that any paths to external files like bzImage and initrd in<br class="gmail_msg">
each buld's .config are relative to the coreboot tree, not the output<br class="gmail_msg">
directory.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Trammell<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" class="gmail_msg" target="_blank">coreboot@coreboot.org</a><br class="gmail_msg">
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" class="gmail_msg" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a><br class="gmail_msg">
</blockquote></div>