[Aboriginal] Prepping for a release.

[Rob Landley]

On 06/11/2011 05:43 PM, David Seikel wrote:
> On Sat, 11 Jun 2011 13:24:40 -0500 Rob Landley <rob at landley.net> wrote:
> 
>> I'm poking at OpenEmbedded because Khem Raj said he had sh4 working
>> with Linux 2.6.38 under QEMU.  Alas, so far it's just a big pile of
>> packages for bitbake (yet ANOTHER package repository to go with rpm,
>> dpkg, portage, and so on).  The "getting started" web page is
>> incomplete. There's no obvious "build a base sh4 system" switch.  I
>> made a debian chroot, installed a dozen extra packages into it,
>> downloaded two different git repositories, made a wrapper script to
>> set environment variables, and now I'm reading through a config file
>> that's full of little land mines to ensure the default configuration
>> doesn't work to require you to read the whole thing...
> 
> I looked at OpenEmbedded, coz the head developer of the EFL stuff I'm
> using is enamoured of it, and has suitable stuff for building EFL on
> top of that in the EFL repo.  Looked like too much to me.  OE was too
> big, AL is just right.  I might add "bare minimum linux to run EFL"
> stuff to the EFL repo later.

It's not a bad project, it's just not the same kind of thing I'm trying
to do.

Aboriginal is not a distro, it just creates a native development
environment for the target and then _stops_.  What you build on the
target _with_ that native development environment is none of our
business (unless it demonstrates a bug in that development environment).

Openembedded, like buildroot, is a distro.  If you have a package
repository, you are a distro, and this thing recipes/xmame which it'll
cross compile for the target.

Which unfortunately means that if you're trying to get it to do what
aboriginal linux does and get it to build a basic sh4 target system to
boot under qemu, it's not immediately obvious how to go about it.  I'm
current reading classes/siteinfo.bbclass which at least mentions sh4...

>> The real problem though is that right now, you can drop a
>> miniconfig-linux or miniconfig-uClibc (or miniconfig-alt-linux or
>> miniconfig-alt-uClibc) file in the arch directory and it'll override
>> the baseconfig.  Some architectures still haven't been converted to
>> use baseconfig, and I need to do that, but some things like the
>> hw-targets aren't _ever_ going to use baseconfig at all, they need to
>> continue to override this
> 
> Yep, I'm using that for my project.  That i486 arch I added before is
> being used as the base for a new i486-MyLinux target where I add things
> to the kernel for my project that are not needed just for the i486
> target.  This should grow later to be the next release of my
> SourceForge MyLinux project.

It's definitely something users need to do, I'm just trying to figure
how where this capability fits into the design from a UI perspective.  I
want to make it easy for you to do this, and clean for me to track it in
the repository if it gets checked in...

I do note that the horrible "hw-" overlay stuff never fit cleanly into
the current design, and I'm tempted to make that distinction be between
targets that are directories and targets that are files, instead of a
magic prefix.  Possibly a directory could have a "base" symlink to the
architecture file (../i486 in your case), and then it could have
settings (stuff appended to the base config allowing arbitrary
overrides), and config-linux and config-uclibc files?

Hmmm...  OR what I could do is ignore directories entirely, then if a
given config wanted to create a subdirectory to suck files out of, it
could in the current directory...

Aesthetic decisions are always the hard ones...