public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Erik Grinaker <erikg@wired-networks.net>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] ebuild USE priority
Date: 15 May 2002 12:51:47 +0200	[thread overview]
Message-ID: <1021459908.4468.5.camel@maas.wired> (raw)
In-Reply-To: <1021438533.3630.45.camel@sartre.shacknet.nu>

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

On Wed, 2002-05-15 at 06:55, Matthew Kennedy wrote:

> On Tue, 2002-05-14 at 17:23, Erik Grinaker wrote:
> > The ebuild is for the Unix Amiga Emulator, or uae for short. uae allows
> > you to select which backend to compile against during ./configure, and
> > you can choose *either* x, svgalib, ncurses or sdl.
> 
> When creating the xemacs-gamma ebuild I encountered the same dillema.
> When you say "*either*", I assume you mean that X, svga, ncurse and sdl
> are optional, but mutually exclusive.

Yep, that's right.


> > If a user has, say, both X and svga in his USE variable, how do I
> > determine whether to use X or svgalib for backend?
> 
> XEmacs gamma supports gtk OR motif OR lucid interfaces (each of which
> can be considered a use flag) in mutual exclusion. Of course, I don't
> want to dictate one of those three to the user, since my preference may
> not be theirs.
> 
> I thought of a priority scheme, but couldn't see clearly how that would
> be done. How did you do it, BTW?

Well, I haven't completed the ebuild yet, but I decided to go for my own
priorities ;

    use ncurses &&  backend="--with-asciiart"
    use svga &&     backend="--with-svgalib"
    use sdl &&      backend="--with-sdl --with-sdl-sound --with-sdl-gfx"
    use X &&        backend="--with-x"

These are set in reverse so that the last one that matches will be
active. But I'm really not satisfied with this, because if a user would
like to have, as you say later in your mail, an svga emulator while
having both x and svga in his USE then his only option would be to
manually change USE before emerging.


> What I ended up doing was checking for an env. var. named USE_PREF which
> is localized to xemacs-gamma. It allows the user to merge xemacs-gamma
> like this:
> 
>    USE_PREF=gtk app-editors/xemacs-gamma

This seems to be quite sensible, even though it creates it's share of
troubles when checking DEPENDs. Does any of the Gentoo developers have
any thoughts on this?


-- 

Erik Grinaker
Freelance UNIX/Linux systems consultant

"Perfection is acheived not when there is nothing more to add, but
rather when there is nothing more to take away"
- Antoine de Saint-Exupéry


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2002-05-15 11:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-14 22:23 [gentoo-dev] ebuild USE priority Erik Grinaker
2002-05-14 22:51 ` Per Wigren
2002-05-14 23:53 ` Spider
2002-05-15  0:44   ` Erik Grinaker
2002-05-15  0:55     ` Spider
2002-05-15  4:55 ` Matthew Kennedy
2002-05-15 10:51   ` Erik Grinaker [this message]

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=1021459908.4468.5.camel@maas.wired \
    --to=erikg@wired-networks.net \
    --cc=gentoo-dev@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