Re: [gentoo-dev] Dynamic SLOTs

[Jason Stubbs <jstubbs@gentoo.org>]

On Wednesday 04 August 2004 08:57, Mike Frysinger wrote:
> On Tuesday 03 August 2004 07:34 pm, Jason Stubbs wrote:
> > That better solution is what I'm looking for here.
>
> even though the rest of the e-mail suggested otherwise, the truth is a
> solution does not exist yet to satisfy the needs of cross compiling ebuilds

You may have read it in IRC today, but I'll repeat it for verbosity's sake.

I think we can get portage managed cross compilation happening with relatively 
few changes. Note that this doesn't extend to multilib, which I can't see as 
being solvable in the same way. Note this also assumes that cross-compilation 
will always be done into a different root.

1. Allow a profile to define aliases for arbitrary commands. This will allow a 
   profile (even customization of an official profile) to specify to use a 
   cross compiler.
2. Fix portage so that the make.conf, /etc/profile/* and /etc/portage/* found 
   in ${ROOT} are used and the ones found in / are not used at all for any 
   package being compiled for ${ROOT}.
3. Have portage define ${ROOT} as "/" when it is not set by the user.
4. Fix ebuilds so that they link against ${ROOT} rather than assuming "/".

#1 is available as of 2.0.51_pre15 (pre14?). #2 is a little difficult but is 
not beyond reason. #3 is dead simple. #4 is up to everyone else. Is anything 
else required for cross-compilation?

As for gcc slotting the cross-compiler, I don't think it's necessary nor has 
any bareing on cross-compilation. Having gcc respond to architecture USE 
flags (prepended with cc- if necessary) and building the cross-compilers in 
the same merge would work, no? No files get lost track of, all the compilers 
are upgraded on an emerge --update and, best yet, it's possible to do right 
now. Am I missing something here? Is there some reason that the gcc ebuilds 
couldn't work in that way? Same question re mod_php and mod_scgi.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list