On Mon, 08 Oct 2007 13:45:04 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Marius Mauch wrote:
> >>> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]>:
> >>>> I imagine there are a lot more cases where the simple on/off
> >>>> system we have now is suboptimal. I could be wrong of course.
> >>>> Please comment.
> >>> This key=value systems sounds interesting. Another use could be
> >>> the choice between xulrunner, seamonkey, firefox.
> >
> > We already have this with USE_EXPAND. Not exactly the same syntax,
> > but I don't see a terrible problem in that, and we don't have to
> > fix all three trillion related tools to handle it. Unless you can
> > come up with a case that can't be handled with USE_EXPAND.
>
> No, USE_EXPAND is only a way to abbreviate use flags with a common
> substring in their name, such as "impl_guile impl_sbcl impl_clisp"
> which could be encoded interchangeably as either
>
> # without USE_EXPAND
> IUSE="impl_guile impl_sbcl impl_clisp"
>
> or
>
> # with USE_EXPAND
> for impl in IMPL; do IUSE+="impl_${impl}"; done
>
> but the effect is that there are 3 use flags with a total of 2^3=8
> combinations, while really something with exactly 3 combinations is
> needed:
>
> IUSE="impl"
>
> case ${impl} in
> guile) #use guile as backend
> sbcl) #use sbcl as backend
> clisp) #use clisp as backend
So what you want is a USE_EXPAND version that only allows one value
per variable. That wouldn't be terribly difficult to do.
As for your idea (ignoring implementation issues), I'd expect that
sooner or later people will request multivalue functionality as well,
so we'd have the same situation there. Also in the given example, how
would the user/package manager actually know what values were
valid/available for "impl"?
Marius
--
[EMAIL PROTECTED] mailing list
