On 10/29/2013 11:02 PM, Ruud Koolen wrote:
> On Tuesday 29 October 2013 08:40:59 Michael Haubenwallner wrote:
>> On 10/26/13 00:54, Ruud Koolen wrote:
>>> It's bikeshedding time.
>>>
>>> The RAP project (prefix with libc) is now ready to start getting merged
>>>
>>> I propose "prefix-native" for rap as an alternative. Does anyone have any
>>> good ideas for classic prefix?
Actually 've read "prefix-native" to be the original Prefix without libc,
that is using the "native" libc, and have "prefix-libc" for RAP.
>> As you say "prefix with libc" above: Is it necessary to /split/ Prefix into
>> $rap and $classic, or would it also fit to have $rap to /supplement/
>> classic?
>
> In what sense? On the profile level, we factor out the common base shared
> between classic and rap (which is about 50%-75% of the existing profile), and
> have both variants inherit this base (neither can inherit the other
> directly).
Have thought one inheriting the other is possible, but OK with me if not.
> As for USE flags, the primary function of the new use flags is to
> disable certain hacks in rap. Writing those as `if use prefix && ! use
> prefix-libc` is not a nice situation, so we need both new flags.
>
> We keep USE=prefix, of course. The vast majority of cases of prefix support
> in
> ebuilds applies equally to classic and rap; those will keep using `if use
> prefix`. The new flags are solely for the handful of ebuilds that need to
> distinguish between the variants.
Trying to be conservative with new USE flags (along Jeremy's comment):
Any real counts already for the "handful of ebuilds" to benefit from having
"prefix-native" in addition to "prefix-libc" USE-flag?
>> In case of the latter, I could think of:
>>
>> profiles/base/make.defaults:
>> USE_EXPAND_UNPREFIXED+=" PREFIX" # for backwards compat, or we get
>> "prefix_prefix" USE_EXPAND_HIDDEN+=" PREFIX"
>> USE_EXPAND_IMPLICIT+=" PREFIX"
>> USE_EXPAND_VALUES_PREFIX="prefix prefix-libc"
>> And to help bug#473598 eventually:
>> USE_EXPAND_VALUES_PREFIX+=" ${USE_EXPAND_VALUES_ARCH//*-*}" # the
>> base-archs only
>
> I don't think I understand this.
Just a proposed implementation detail, without having tried out.
/haubi/
