Re: mutually exclusive group of options

Lorenzo Bettini <[email protected]>
Newsgroups gmane.comp.gnu.gengetopt.general
Message-ID <[email protected]>
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...)
> 
> Well I'm getting enjoy it:) Here is the modified version of the skeleton. UNfortunately I haven't time to propagate all the necessary changes in the source tree, so if any help and contribution is very appreciated.
> 
> if (args_info->@option_var_name@_given
>     && !(args_info->@dep_option@_given
> @if@ dep_option_is_flag  @then@
>         || args_info->@dep_option@_flag
> @elseif dep_option_has arg @then@
>         || args_info->@dep_option@_arg
> @endif@
>         ))
> 
>     ))
>   {
>     fprintf (stderr, "%s: @option_descr@ option depends on option '@dep_option_descr@'%s\n", @package_var_name@, (additional_error ? additional_error : ""));
>     error = 1;
>   }
> 

Hi there

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 
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)...  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.

A situation like the one you describes implicitly requires mutually 
exclusive groups (not groups of mutually exclusive options), i.e., the 
program accepts two different (or more than two) mutually exclusive 
syntaxes (besides a possibly common options).  And probably the best 
thing would be to add such features.

What do you think about that?

cheers
	Lorenzo

P.S. glad you used gengen too :-)

-- 
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.