[Aboriginal] toolchain placement options

[Rob Landley]

On 11/27/2013 06:21:14 PM, Patrick Lauer wrote:
> On 11/28/2013 06:51 AM, Rob Landley wrote:
> >> I guess if you are not planning to develop Aboriginal in direction  
> of a
> >> flexible build system this is fine by me.
> >
> > I'm not turning it into a full-fledged distro. what I want to do is
> > create bootstrap images for distros, so you can do a  
> debian-boostrap and
> > gentoo-bootstrap and fedora-bootstrap and so on that create a chroot
> > within which their build tools will run to add more packages,  
> building
> > them from source and loading them into their repository on whatever  
> the
> > host happens to be. So if you want to create "slackware on sh4",  
> you can
> > do so.
> >
> > Alas, that turns out to be a big job (gentoo assumes it's building  
> under
> > gentoo, _and_ every ebuild file in portage is annotated with the
> > complete list of every target it's allowed to run on, so adding a  
> new
> > target to the portage tree requires touching just about every ebuild
> > file in the tree because they weren't THINKING...)
> 
> Let me just disagree with you ;)

Happens a lot. :)

> There's a very reasonable assumption that things will fail on a new
> architecture, so it makes more sense to whitelist things when they  
> have
> been tested, patched and beaten into submission.

So a package that works on 8 architectures already is obviously going  
to blow up on a 9th.

If you have 16,000 packages and 400 of them are going to blow up on a  
new architecture, (of which 300 of that means you need to fix your  
toolchain and uClibc and not touch anything in the package), the  
logical thing to do is change the ebuilds of the 98% that didn't have a  
problem to say "yup, didn't have a problem".

What the hexagon guys did at Qualcomm was have the gentoo hexagon  
architecture pretend to be a derivative of the gentoo x86 architecture  
to globally disable that craziness. (And then not bother to push  
anything back upstream to gentoo because that was such a gross hack and  
they were never going to bother to do it the way you wanted.)

> Blacklisting things is not good when you want everything to build,
> because it's hard to get enough test coverage (build everything on  
> HPPA?
> You funny person ...) and to keep the blacklist updated for new  
> versions
> (Who would have guessed that Java/Icedtea still doesn't build on  
> SPARC?)

A) The point of this project is so you _can_ natively regression test  
builds, under qemu or on real hardware.

B) How does failing closed instead of failing open change the "we  
haven't got a scalable test environment for this architecture"?

> (On a sidenote, if you are in a I-Don't-Care mode you can just tell
> portage to accept anything - or that anything that works on x86 should
> be ok too. But that's Not A Good Idea :) )

It gets things done, and then it means you will never try to interface  
with upstream because it's not their way of doing it.

(It also means your coverage pass hits cases where it tries to compile  
x86 assembly packages for x11 and such, so the gentoo based build  
system is making more work for you and you eventually abandon it and  
switch to Beyond Linux from Scratch instead. Or at least that's what  
hexagon did back in 2010.)

> And luckily your "Gentoo needs Gentoo" claim has been undermined over
> the years, first by Gentoo Prefix (which even works on win32 and other
> mad platforms) and lately by RAP ("RAP ain't Prefix") which started as
> an experiment on Android (
> http://wiki.gentoo.org/wiki/Project:Android/build )

I'll give this fifth approach a try, sure.

Rob