[gentoo-dev] Re: Re: [RFC] New keywords for non-Gentoo Linux platforms

[Steve Long <slong@rathaus.eclipse.co.uk>]

Michael Haubenwallner wrote:
> Fabian Groffen wrote:
>> Ciaran McCreesh wrote:
>> > Steve Long wrote:
>> > > Unless someone can say what using PROPERTIES=prefix would break, I'd
>> > > go with that. It's a /classic/ usage of that variable, as it's simply
>> > > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
>> > > support it. It'd be great to see the prefix branch finally merged so
>> > > we all get to play with it.
>> > 
>> > It would break. Prefix ebuilds won't work unless ED is set, and a non
>> > PROPERTIES aware or non-prefix-property aware package manager won't set
>> > ED. Unless prefix is reimplemented to require no package manager
>> > changes for the install to / case, PROPERTIES is out.

Nonsense; we just need some bash changes to integrate it iff we want to
allow prefix ebuilds into the main tree; we're a while away from actually
being at the stage where that would be feasible, even if it were desired.
By the time we do get there, we should be able to fulfil your last
condition, given a sane bash implementation for the mangler in question.

TBH I'm not really worried about alternative manglers atm; they can catch up
w/e afaic. IIRC PROPERTIES are part of EAPI-2, so one would hope they've
already done that by now.

>> 
>> Just to comment on this possibility; I see an option, given the
>> definition of ED and EROOT to do Prefix without them, by e.g. using
>> ${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
>> unset, this would result in simple ${D}, which is "backwards
>> compatible".  This is not all what is necessary, but a big deal of it.
>> 
>> Question here, however, is whether this is worth it.  Personally, I
>> prefer the shorthands, as they give a lot of readability.
>
Yeah the shorthands are nice, agreed. Ideally we wouldn't need to change
anything in the ebuild though. (I appreciate we're a while away from there,
but if we can at least get the ones which go via emake and econf, that's a
start. We can worry about {scons,distutils,..} later; pro-audio have a nice
exteutils.eclass we can 'borrow' for a start ;)

From the prefix docs, the only place D should be retained over ED is in a
DESTDIR="$D" (or "${D}") when configure --prefix=.. has been run. Is that
correct?
 
> Could it also work to initialize them in profile.bashrc if they are
> unset?
> 
> Something like
>         : ${EPREFIX=}
>         : ${ED=${D}}
>         : ${EROOT=${ROOT}}
> 
That would work yeah, though I think it would be better if we just
integrated that into ebuild.sh. We can check PROPERTIES to see if prefix is
in there, and then enable additional logic, and eg use a different PATH for
external helpers (most of which we can do internally in any case.) I
realise the latter is happening already, but if we're integrating, it
should be happening in the mainline code when applicable, imo. (Not saying
that is the applicable case, just that we can change w/e you see fit.)