> 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. ;) _______________________________________________ Help-gengetopt mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gengetopt
