20.07.2011, 21:31 +0100 schrieb Ciaran McCreesh: > On Wed, 20 Jul 2011 19:59:55 +0000 > Paul Seidler <[email protected]> wrote: > > > On Mon, 18 Jul 2011 22:55:16 +0000 > > > Paul Seidler <[email protected]> wrote: > > > > I think it would be really nifty if suboptions can be treated like > > > > options, so that there could be an suboption python with a > > > > description and when the option is enabled the different python > > > > versions appear and can be enabled/disabled. > > > > > > Could you explain what you mean by that please? > > > > I'll try it but I've modified the idea a little bit: > > I mean to bind an option to a suboption (in this case PYTHON to > > python) so if -python is selected you don't get the "PYTHON:*" output > > for resolving foo/bar. > > e.g. git: > > +python: " -xinetd PYTHON: -2.6 2.7 -3.1 build_options: " > > -python: " -xinetd build_options: " > > Oh. You mean, not having certain options shown at all if other options > aren't selected? There are three things sort of relevant to this > currently.
Exactly! > First, there's HIDDEN_SUBOPTIONS, which is used to unconditionally hide > a suboptions group. Unfortunately this is no solution for this case. > Second, there's MYOPTIONS requirements, which can be used to express > interdependencies between options. > > I wonder whether something like this is the way to go: > > MYOPTIONS=" > python > ( python_abis: 2.6 2.7 ) [[ *hidden-if = [ !python ] ]] > " > > Except I'm worried it'll be abused... In particular, I suspect people > will use it when they should just be using requires -- usually options > should be visible, even if an option they require is disabled. I like this one for the simplicity, but also I see the resulting trouble rise at the horizon. > Third, choices (which is what options map to in Paludis internals) > support having values, as per build_options: jobs and symbols. If an > option is off, its values are irrelevant. So maybe instead: > > MYOPTIONS=" > python [[ values = [ 2.6 2.7 3.1 ] ]] > " > > But then we have to introduce a whole new mechanism for values, since > values have interdependencies and can be used in dependencies and so on. > > Or maybe we could map an option with values onto a suboption somehow... > So doing this: > > MYOPTIONS=" > python [[ values = [ 2.6 2.7 3.1 ] ]] > " > > would automatically give you something equivalent to: > > MYOPTIONS=" > python [[ values = [ 2.6 2.7 3.1 ] ]] > ( python: 2.6 2.7 3.1 ) > " > > for the purposes of dependencies etc, and where the suboption would > automatically be hidden. This one is clearly my favorite and I think that's the "clean-way"(TM) especial the first part of it. Tragically, the "right" way is usually a synonymous for the most work. For a map I'm more thinking in this direction: MYOPTIONS="python [[ bind_suboption=PYTHON ]]" > Also, I dunno if there are issues having a suboption named the same as > an option. Or for that matter whether having it named PYTHON would upset > configure scripts -- I suspect some packages probably look at the > $PYTHON environment variable to find Python and will get upset if it > contains "2.6 2.7". Indeed, maybe that can be a problem. I run into a similar problem with dev-scm/git, as PYTHON is also the string which is used to transport the used python executable and it got replaced in "option_with". I have to look at this again and will probably rename the suboption to python_abi (thanks for the suggestion). This would also make that discussion superfluous (at least regarding the python suboption) because I think it will not be confusing anymore (with a reworded description of python_abi:*). Sometimes the answers are so simple that you can't see them. Of course it would be still nifty if it can be handled like in your third idea. _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
