From: Michael Haubenwallner <haubi@gentoo.org>
To: gentoo-alt@lists.gentoo.org
Subject: Re: [gentoo-alt] Names of Prefix variants
Date: Thu, 31 Oct 2013 08:37:12 +0100 [thread overview]
Message-ID: <527208A8.7080503@gentoo.org> (raw)
In-Reply-To: <201310292302.28939.redlizard@gentoo.org>
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/
next prev parent reply other threads:[~2013-10-31 7:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 22:54 [gentoo-alt] Names of Prefix variants Ruud Koolen
2013-10-26 0:23 ` Greg Turner
2013-10-26 0:28 ` Ruud Koolen
2013-10-26 7:41 ` Fabian Groffen
2013-10-26 8:13 ` Ruud Koolen
2013-10-26 9:28 ` Fabian Groffen
2013-10-31 15:50 ` heroxbd
2013-10-29 7:40 ` Michael Haubenwallner
2013-10-29 22:02 ` Ruud Koolen
2013-10-31 5:03 ` Jeremy Olexa
2013-10-31 7:37 ` Michael Haubenwallner [this message]
2013-11-18 4:28 ` Ruud Koolen
2013-11-18 9:24 ` Fabian Groffen
2013-11-18 15:33 ` Ruud Koolen
2013-11-19 10:20 ` heroxbd
2013-11-19 11:37 ` Michael Haubenwallner
2013-11-19 15:48 ` Fabian Groffen
2013-11-19 10:13 ` heroxbd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527208A8.7080503@gentoo.org \
--to=haubi@gentoo.org \
--cc=gentoo-alt@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox