Re: [help-gengetopt] mutually exclusive group of options

[Papp Gyozo (VBuster)]

> Papp Gyozo (VBuster) wrote:
> >>> What would happen if such a base option (btw how do you call it when
> >>> other options depend on it?) may not be required if it had a default
> >>> value? (Or enabled/switched on by default like "flag on")
> >> I see in dependant_option.h_skel which condition is needed to
> >> modify/extend:
> >> But I don't know how. (It was a long time ago when I made changes to
> the
> >> gengetopt source...)

> I'm a little bit reluctant about such a solution: if you make an option 
> of a group with a default value, what happens when another option of the
> same group is provided?  You'd need to unset the previously option with 
> default value?  Using flag options might be even harder to define a 

I think it is not a big problem at least for me. ;)
Group options have already their individual _arg & _orig fields in the 
structure, as far as I know. Let me rephrase what I mentioned previously: be 
able to set a default group option! If not specified anything at all from the 
group gengetopt may behave as if this option were set. (--init in my example.)

I admit this is not the best approach to this specific problem but:
- it suffices my needs
- and I think it is a really viable feature anyhow.

> clean semantics of group options (flag options was a legacy of the very 
> first version of gengetopt - I'm not the first author of gengentopt - 
> and I think that flag options make a little sense too)...  

Well, I share your point of view about flags. I just noted that we had to deal 
with them, too.

Even a "base"
> option with a default value might make dependent options harder to 
> understand: an option that depends on another option implicitly requires
> the other option to be provided, otherwise it would make a little sense.

You are right in theory. Actually my main concern is being compatible with 
previous version where this --init option was simply optional. Now this --init 
option seemed the best counterpart of the newly introduced --attach option, 
that was the reason why I wanted them to form a group. (From this point you 
could get know the whole story.)

> A situation like the one you describes implicitly requires mutually 
> exclusive groups (not groups of mutually exclusive options), i.e., the 
> 
> What do you think about that?

Well, actually I didn't like to dream about such rocking new features but if 
you are willing to add it I will be very glad to see and use it. ;)