[Aboriginal] multi-build option request

[Rob Landley]

On 07/09/2013 06:32:08 PM, scsijon wrote:
> Any chance of adding an 'all' to the  './build.sh' cross compiler  
> line,
> and have it build the lot.

That's what "more/buildall.sh" is for (and more/buildall-native.sh to  
do native builds). The logs wind up in build/logs, and it does the full  
logs with more/record-commands.sh so there's a ton of forensic data on  
the build. (Some releases I post said logs. This time the build was a  
bit chopped up for the logs to be meaningful, which kinda turned around  
and bit me... :)

You can export FORK=1 for both (FORK=1 more/buildall.sh) to launch all  
the builds in parallel, it'll check how much ram you've got and how  
many CPUS and try not to overwhelm the server too badly, but it can't  
can't do less than CPUS=1 for each parallel build.

> Reason is to ensure all that is built are EXACTLY the same version  
> set.
> And yes, i've already managed to stuff-up using two different  
> 'current'
> tarballs i'd downloaded and built against for two different platforms  
> (-;!

I've been poking at aboriginal linux on and off since either 1999 or  
2002 (depending on how you want to look at it, someday I should finish  
http://landley.net/aboriginal/history.html), and the 3-ish relaunches  
were each because I'd figured how a SIMPLER way to do it, so I threw  
out what I had and started over.

The current design does what I set out to do, and it's organized into a  
series of orthogonal layers each of which may be skipped or replaced.  
(So ./download.sh doesn't have to be what populates the "packages"  
directory, if you don't run host-tools.sh it'll use the host $PATH and  
you have to set the host system up VERY carefully so this doesn't  
break, you can use a different simple-cross-compiler.sh if you like  
(just mkdir build/simple-cross-compiler/bin and make the appropriate  
symlinks so it finds the right names at the exptected $PATH), build.sh  
will skip cross-compiler.sh by default unless you set an environment  
variable asking for it (which buildall.sh does), and so on.

However, it's at pretty much complexity saturation level. The package  
cache speeds up the build tremendously (especially multiple parallel  
builds) but it's fiddly and complicated and half the FAQ is devoted to  
explaining how it works. (It's designed so you can completely IGNORE it  
and treat "setupfor" like it's extracting the tarball each time, but...)

All the files at the top level are build stages. That means if I want  
to implement something that's NOT a build stage, I have to put it in a  
subdirectory, where nobody notices it. "more" is the main subdirectory  
for doing this.

Please let me know how I should document this in a way that doesn't  
take hours to read. I've tried many times over the years. I suppose I  
should try again...

Rob
 1373420442.0