2011/7/20 Bernd Steinhauser <[email protected]>: > > On 20/07/11 21:59, Paul Seidler wrote: >> >> 2011/7/20 Ciaran McCreesh<[email protected]> >>> >>> 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: " >> >> I think that would be useful because PYTHON is ignored if python is >> disabled and that would left " -python PYTHON: -2.6 2.7 -3.1" over >> that is irritating but more user friendly (as python is default >> disabled and PYTHON: 2.6 enabled). Of course there are other solutions >> like disable PYTHON: * or enable python, but in my opinion none is >> perfect except of this one, other ideas are welcome. >> > Shouldn't the python support just be disabled if you set PYTHON: -*? > In other words: What's the point of the python option?
That was my thought in the first email but then we should modify option_enable/with so that "option_enable suboption" would work or we have unnecessary complicated configure (or do I miss something). Also it would be nifty if the SUBOPTION can get a description. _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
