[Exherbo-dev] Python improvements

Bernd Steinhauser exherbo at bernd-steinhauser.de
Wed Jul 20 22:07:51 BST 2011

On 20/07/11 22:41, Paul Seidler wrote:
> 2011/7/20 Bernd Steinhauser<exherbo at bernd-steinhauser.de>:
>> On 20/07/11 21:59, Paul Seidler wrote:
>>> 2011/7/20 Ciaran McCreesh<ciaran.mccreesh at googlemail.com>
>>>> On Mon, 18 Jul 2011 22:55:16 +0000
>>>> Paul Seidler<pl.seidler at googlemail.com>    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).
I think this would be the job of a the python exlib, so you wouldn't use 
option_enable directly, but i.e. python_enable which would echo --enable-python 
if any of the suboptions are activated and --disable-python if none.
>   Also
> it would be nifty if the SUBOPTION can get a description.
They can have descriptions. For example, kde_parts do have descriptions. Or do 
you mean the suboption itself?
I don't really think that would be necessary.

More information about the Exherbo-dev mailing list