help-gengetopt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lorenzo Bettini
Subject: Re: [help-gengetopt] mutually exclusive group of options
Date: Thu, 14 Jun 2007 14:46:36 +0200
User-agent: Thunderbird 1.5.0.12 (Windows/20070509)

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->@address@hidden
    && !(args_info->@address@hidden
@if@ dep_option_is_flag  @then@
        || args_info->@address@hidden
@elseif dep_option_has arg @then@
        || args_info->@address@hidden
@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]