RE: [gentoo-alt] Crossdev in a prefix / bug 384167

On Fri, 14 Jun 2013, at 20:05, heroxbd thusly quipped:
> From my own point of view, multilib is not cool compared to multiarch from
> Debian. lib vs lib32 vs lib64 is crazy to me with inconsistent
implications across
> distros, even among people in the same community. LSB/FHS has not done a
> good job here.

I'll take your word for that, having not looked into it myself.  However, so
long as prefix-profile has a deprecated parent-profile, I fear the number of
headaches stemming from incorrect hard-coded assumptions in ebuilds and
eclasses will tend to rise over time.  If multiarch achieves the benefits of
multilib in a better ("cooler"?) way, perhaps we should consider building a
multiarch profile for Gentoo... or does that already exist?  Sorry, I may
have fallen behind a bit during the past few months where I've only had
sporadic access to a working computer with floppy disks smaller than my
torso :) 

I have tried (some time ago, back in the good ole' days) bootstrapping a
cross-arch prefix (specifically, an x86 prefix from an amd64 no-multilib
native gentoo), and, except for a few small hiccups, it worked great.

>> I'd be curious to hear more about what your GSOC objectives are,
>> especially whether it's the "easy" or the "hard" fix, above, you are
>> shooting for.
>
> A long version of proposal is here:
>
>   http://www.awa.tohoku.ac.jp/~benda/projects/android.html

Sweet idea.  If you pull that off I might just buy a smartphone.

> I'd like to start a piece of document to definitely describe what we
expect for
> a portage/toolchain/crossdev combo to do in diferent situations, and what
> we interpret for different environment variables. I think Ruud already has
his
> own version.

I need a name for the following: aspects of Gentoo that assume $CHOST and/or
$CBUILD are the same as $CTARGET.  Perhaps "the vice of presumed nativity."
(But hopefully something that rolls off the fingertips a bit easier... I'm
open to suggestions).

For example, when building a cross-compiler, what does it mean if the
multilib use flag is true?  IIUC, right now it pertains to the target.  But,
correct me if I'm wrong, everywhere else, it's a host-specific use flag, and
it is not Gentooly Correct to have global use flags with context-dependent
meanings like that.

Crossdev does a great job of building a cross compiler, but unfortunately,
cross-emerge doesn't do a fantastic job, in my (admittedly, not-recent)
experience, of building a cross-Gentoo.  I need to fix this, partially, for
cygwin (long, boring story).  Embedded, broadly speaking, is another --
arguably much more compelling -- reason to fix it as well, and completely.

Anyhow, sorry, I'm actually veering off topic.

My point is, I think what really causes muddle-headedness in the case of
tool-chain ebuilds is that, in a regular cross-emerge of a non-toolchain
package, $CHOST == $CTARGET -- or, more accurately, CTARGET is really
meaningless.  That's the standard case, so there's nothing wrong with
building portage around this assumption as the default.  CBUILD can differ
depending on whether this is a cross-emerge or not, and as mentioned above,
forgetting that possibility is a source of problems that need fixing.  But
with toolchain ebuilds, we have the rather confusing issue that all three
variables actually mean something (for example, all three can be distinct if
we are cross-emerging a cross-compiler).

Gentoo just wasn't designed with these cases in mind, and I am starting to
believe that the best solution to these sorts of problems is to enhance
portage to the point where crossdev is no longer needed, or is a trivial way
to drop a few simple defaults into ${EPREFIX}/etc.

Think about it: anywhere we need crossdev to make something work, by
definition, represents -- whatever we want to call it -- the "vice of
presumed nativity."  If portage and the ebuilds had the right features
in-built, we wouldn't /need/ crossdev to run around whispering half-truths
into everybody's ears until the right thing happens.

In an ideal world, I think crossdev should set up links in an overlay, like
it does now, and maybe a simple make.conf.cross-foo-triplet, and be done.
 
And, basically, I think creating a coherent specification for exactly how
everything is supposed to work is a fantastic first step -- but, "first"
step really ignores all the fantastic hard work that's already been done, so
let's say, "next" step -- towards realizing that vision.  If we start
bumping up against places where we need to look at the code to figure out
how things work, I think it's worth considering whether we should be
documenting, or, instead, innovating.

> Zac Medico and Mike Frysinger did masterful jobs for portage and
> toolchain/crossdev. As the two pieces are central to our distribution,
they are
> not willing to accept random ideas. Let's make a proposal for
cross-triplet and
> cross-eprefix in Gentoo in a systematic, robust and consent way before
> getting our hands dirty with the serious implementation.

OK, sounds like you read my mind, or maybe I read yours.  Anyhow, +1.

> I'll roll out a draft and put it on a git repo/wiki/google drive for
> cooperative edition.

Looking forward to it!  On my end, my gentoo git user repo is in production,
but, meanwhile, I've gone ahead and started preparing to publish on github,
if only to ensure I can't accidentally rm -rf the whole business.  With any
luck, that should be ready for eyeballs in a day or three.

-gmt