Re: [gentoo-dev] IUSE variable clarification

[Bob Phan <bob@endlessrecursion.net>]

* [Jan 09, 2003] Paul de Vrieze <gentoo-user@devrieze.net>:
> On Wednesday 08 January 2003 20:18, Terje Kvernes wrote:
> > Nick Jones <carpaski@twobit.net> writes:
> > > It should contain _EVERY_ reference you make to a USE variable. So
> > > if you check ncurses, it contains ncurses... if you check gtk, it
> > > contains gtk. It's presently unused, but required for upcoming
> > > features like rebuild-on-use-change.
> >
> > isn't the IUSE-variable really redundant?  shouldn't portage be
> > able to get the USE-flags directly from the ebuilds
> > DEPEND-statement without adding an IUSE-kludge?  as far as I can
> > tell IUSE just moves the work of maintaining this list from
> > portage to the ebuild maintainer, who now has to update both
> > DEPEND and IUSE.
> >
> > there is no doubt that portage needs the functionality IUSE
> > provides, I'm just sceptical to the way that functionality is
> > being provided.
> 
> Only depend would not suffice. Also all use <flag> commands should be
> taken into account. Ofcourse this "could" be done automatically, but
> it is more complex than a IUSE flag.
It shouldn't really be all that complex.  A simple re should be able to
parse out any contiguous word character string followed by a question
mark on a line.

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.

My two cents.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 * http://www.endlessrecursion.net/
 */

--
gentoo-dev@gentoo.org mailing list