public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paul de Vrieze <gentoo-user@devrieze.net>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] IUSE variable clarification
Date: Thu, 9 Jan 2003 23:35:04 +0100	[thread overview]
Message-ID: <200301092335.22644.gentoo-user@devrieze.net> (raw)
In-Reply-To: <20030109210546.GA3312@endlessrecursion.net>

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1529 bytes --]

On Thursday 09 January 2003 22:05, Bob Phan wrote:
>
> That would grab a use var right out of depend.  My complaint isn't that
> IUSE shouldn't exist, but that it shouldn't overlap the DEPENDs.
> Redundancy like that just screams maintenence problems.  I think the way
> that USE variable usage inside of ebuilds is handled should be more
> similar to the way that they're presented to the user.  There are
> multiple sources with priority to get an end list of USE variables.  To
> grab the list of USE vars in the ebuild it should scan DEPEND and
> RDEPEND, then append IUSE to it.  IUSE needn't contain anything that can
> be placed in a DEPEND variable, instead it should _only_ contain USE
> variables that are used, but aren't dependancies, like sse and mmx as
> someone stated earlier.  This should be trivial to implement in python.

No DEPEND overlap is not clear either. That introduces a second place where 
information can be stored. Normally that is not good design. Second. I didn't 
talk about getting uses from DEPEND lines. Yes, that's easy. I was thinking 
about understanding shellscript on such a level that all invocations of use 
sse (where sse is an example of a DEPEND independant useflag) etc. are 
recognized to compose an IUSE flag.

Paul

ps. A validation tool that validates IUSE based on DEPEND is of course OK.
pps. The use function might also be adapted to through an error if the flag is 
not in IUSE

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-01-09 22:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08 14:31 [gentoo-dev] IUSE variable clarification Burton Samograd
2003-01-08 14:59 ` Maik Schreiber
2003-01-09 16:44   ` Burton Samograd
2003-01-09 17:00     ` [gentoo-dev] " Wilbert Berendsen
2003-01-09 17:05       ` Maik Schreiber
2003-01-09 17:06       ` Yannick Koehler
2003-01-09 17:03     ` [gentoo-dev] " Maik Schreiber
2003-01-08 15:04 ` Nick Jones
2003-01-08 19:18   ` Terje Kvernes
2003-01-08 19:52     ` Felipe Ghellar
2003-01-08 20:11       ` Terje Kvernes
2003-01-09 15:42     ` Paul de Vrieze
2003-01-09 21:05       ` Bob Phan
2003-01-09 22:35         ` Paul de Vrieze [this message]
2003-01-10 12:28           ` Bob Phan

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=200301092335.22644.gentoo-user@devrieze.net \
    --to=gentoo-user@devrieze.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