mutually exclusive group of options

[Papp Gyozo (VBuster)]

Hi

I've encountered a problem and don't know how to resolve it. I'm developing a commandline tool which can use either of two shared libraries (.so in short) but only one of those at a time. Furthermore, both .so require different options which are available (meaningful) only if the corresponding .so is chosen. For example:

 scan --init   --dir1=... --dir2=... ; create an own scanning process

or

 scan --attach --address=... ; attach to a daemon

(I hope it is clearer a little bit now what I'm talking about.)

I know I can specify "init" and "attach" as mutually exclusive group options but I don't know how to induce gengetopt to allow dir options only if --init is given and --address if --attach is given.

Any ideas? Thanks in advance

--
Papp, Gyozo


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

> Hi
>
> I've encountered a problem and don't know how to resolve it. I'm developing a commandline tool which can use either of two shared libraries (.so in short) but only one of those at a time. Furthermore, both .so require different options which are available (meaningful) only if the corresponding .so is chosen. For example:
>
>  scan --init   --dir1=... --dir2=... ; create an own scanning process
>
> or
>
>  scan --attach --address=... ; attach to a daemon
>
> (I hope it is clearer a little bit now what I'm talking about.)
>
> I know I can specify "init" and "attach" as mutually exclusive group options but I don't know how to induce gengetopt to allow dir options only if --init is given and --address if --attach is given.
>
> Any ideas? Thanks in advance
>

Hi there

you can use the "dependon" specification of an option:

dependon
    this option depends on another option (whose long name description
is specified). If this option is given at command line but not the
option it depends on, an error will be generated.

for instance,

option  "dependant"         D
   "option that depends on str-opt" int optional dependon="str-opt"

does this solve your problem?

hope to hear from you soon
cheers
        Lorenzo

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> >  scan --init   --dir1=... --dir2=... ; create an own scanning process
> >
> > or
> >
> >  scan --attach --address=... ; attach to a daemon
> >
> > I know I can specify "init" and "attach" as mutually exclusive group
> options but I don't know how to induce gengetopt to allow dir options
> only if --init is given and --address if --attach is given.
> >
> you can use the "dependon" specification of an option:

It seems I lag behind the rapid development of gengetopt, thanks.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> option  "dependant"         D
>    "option that depends on str-opt" int optional dependon="str-opt"
>
> does this solve your problem?

More or less. I actually idealize the situation to strip down my problem:

> > scan --init   --dir1=... --dir2=...
> > scan --attach --address=...

The first usage is default (used much more than the second one), moreover the distinctive option (ie. --init) is not required even more a hidden option actually *without* default values. So in most cases the user doesn't specify the "main" option either because he has not to do so or because he simply are not aware of it.  Thus in my understanding if --init is not present, error will be generated each time if a dependant option is given.

    scan --init=/path/to/lib/to/load.so --dir1=... --dir2=... ; no error

    scan --dir1=... --dir2=... ; error because no --init is given

Unfortunately this latter one is the most common use-case with this application. :-(
I'm thinking about what default value I can define for --init to be compatible with previous versions.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

>> option  "dependant"         D
>>    "option that depends on str-opt" int optional dependon="str-opt"
>>
>> does this solve your problem?
>
> More or less. I actually idealize the situation to strip down my problem:
>
>>> scan --init   --dir1=... --dir2=...
>>> scan --attach --address=...
>
> The first usage is default (used much more than the second one), moreover the distinctive option (ie. --init) is not required even more a hidden option actually *without* default values. So in most cases the user doesn't specify the "main" option either because he has not to do so or because he simply are not aware of it.  Thus in my understanding if --init is not present, error will be generated each time if a dependant option is given.
>
>     scan --init=/path/to/lib/to/load.so --dir1=... --dir2=... ; no error
>
>     scan --dir1=... --dir2=... ; error because no --init is given
>
> Unfortunately this latter one is the most common use-case with this application. :-(
> I'm thinking about what default value I can define for --init to be compatible with previous versions.

Hi there

from your original mail I seemd to understand that --dir options can
appear only if --init is given, isn't it so?  If not, then you can
simply make them independent from --init, can't you?

Or am I missing something?

cheers
        Lorenzo

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> >     scan --init=/path/to/lib/to/load.so --dir1=... --dir2=... ; no
> error
> >
> >     scan --dir1=... --dir2=... ; error because no --init is given
> >
> > Unfortunately this latter one is the most common use-case with this
> application. :-(
> > I'm thinking about what default value I can define for --init to be
> compatible with previous versions.
>
> from your original mail I seemd to understand that --dir options can
> appear only if --init is given, isn't it so?  If not, then you can
> simply make them independent from --init, can't you?

Yes, I think they are actually independent because the program now works only in one mode (standalone mode w/ optional --init) which means it can accept --init argument only and has no --attach at all. That's why --dir can be given now independently from the fact whether --init was given or not. In other words --init is an optional parameter with a very common default value.

1.)  scan --init --dir1 --dir2 ... ; standalone mode
2.)  scan --attach                 ; shared mode (attach to daemon)

Up to now the users have had to specify the initialization options in the standalone mode because the application was responsible to start and configure the daemon itself. (Most common ones have default values, so the users hadn't have to type too much ;)

But if I introduced the new mode ("attach to daemon" w/ --attach option) I'd had to disable (inhibit) some of the options which simply would make no sense in this new mode. (ie. do not give initialize an already initialized daemon) This is my first original problem.

My next concern is that I'd like that the application be compatible with previous versions so users can simply use it in the following way (like before), eg:

  scan --dir2  ...
  scan --dir1 -dir2 ...

The common in both examples is that --init is omitted.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

>>>     scan --init=/path/to/lib/to/load.so --dir1=... --dir2=... ; no
>> error
>>>     scan --dir1=... --dir2=... ; error because no --init is given
>>>
>>> Unfortunately this latter one is the most common use-case with this
>> application. :-(
>>> I'm thinking about what default value I can define for --init to be
>> compatible with previous versions.
>>
>> from your original mail I seemd to understand that --dir options can
>> appear only if --init is given, isn't it so?  If not, then you can
>> simply make them independent from --init, can't you?
>
> Yes, I think they are actually independent because the program now works only in one mode (standalone mode w/ optional --init) which means it can accept --init argument only and has no --attach at all. That's why --dir can be given now independently from the fact whether --init was given or not. In other words --init is an optional parameter with a very common default value.
>
> 1.)  scan --init --dir1 --dir2 ... ; standalone mode
> 2.)  scan --attach                 ; shared mode (attach to daemon)
>
> Up to now the users have had to specify the initialization options in the standalone mode because the application was responsible to start and configure the daemon itself. (Most common ones have default values, so the users hadn't have to type too much ;)
>
> But if I introduced the new mode ("attach to daemon" w/ --attach option) I'd had to disable (inhibit) some of the options which simply would make no sense in this new mode. (ie. do not give initialize an already initialized daemon) This is my first original problem.
>

and in order to do this, using groups should be enough, shouldn't it?

> My next concern is that I'd like that the application be compatible with previous versions so users can simply use it in the following way (like before), eg:
>
>   scan --dir2  ...
>   scan --dir1 -dir2 ...
>
> The common in both examples is that --init is omitted.

and again, putting --dir1 and --dir2 in the same group of init should be
enough, shouldn't it?  This way, if you provide --dir1, --dir2 or even
--init, you cannot provide any --attach's group options...

did I get the point?

cheers
        Lorenzo

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Gyozo Papp]

> >   scan --dir2  ...
> >   scan --dir1 -dir2 ...
> >
> > The common in both examples is that --init is omitted.
>
> and again, putting --dir1 and --dir2 in the same group of init should be
> enough, shouldn't it?  This way, if you provide --dir1, --dir2 or even
> --init, you cannot provide any --attach's group options...

IN this --dir1 and --dir2 will be mutually exclusive along with --init
and --attach, won't be?
This is not exactly what I want.

> did I get the point?
Maybe but I'm afraid I'm getting lost. ;)

--
Papp, Gyozo


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Gyozo Papp wrote:

>> >   scan --dir2  ...
>> >   scan --dir1 -dir2 ...
>> >
>> > The common in both examples is that --init is omitted.
>>
>> and again, putting --dir1 and --dir2 in the same group of init should be
>> enough, shouldn't it?  This way, if you provide --dir1, --dir2 or even
>> --init, you cannot provide any --attach's group options...
>
> IN this --dir1 and --dir2 will be mutually exclusive along with --init
> and --attach, won't be?
> This is not exactly what I want.
>
>> did I get the point?
> Maybe but I'm afraid I'm getting lost. ;)
>

Actually, I'm the one that got lost, sorry :-)
I thought that groups options were not mutually exclusive among them (I
didn't implement that feature personally in first place, and actually
never used that, so I never remember correctly how they work :-)
I actually remembered that if you specified an option of a group you
couldn't specify an option of another group, but that's not right.
Instead, if you specify an option of one group and another option of
another group is allowed.

So the only solution is to make --init and --attach belong to the same
group (so that they're exclusive with each other), and then use dependon
for all the other options.

Unfortunately, this requires --init to be specified explicitly (which is
not what you want...).

Do you have any proposals of a new mechanism to solve this?

Of course, one could perform checks manually, but one would want most of
the checks to be performed automatically, right? :-)

hope to hear from you soon
cheers
        Lorenzo

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



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> So the only solution is to make --init and --attach belong to the same
> group (so that they're exclusive with each other), and then use dependon
> for all the other options.
>
> Unfortunately, this requires --init to be specified explicitly (which is
> not what you want...).
>
> Do you have any proposals of a new mechanism to solve this?

Well a sort of ... but I haven't think it over yet. Let's see what I've already:

We agree that the bottleneck is the obligatory presence of --init option.
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")

defgroup "mode"
groupoption "init"   default="..." group="mode"
groupoption "attach"               group="mode"

option "dir1" dependon="init"
option "dir2" dependon="init"

option "attach-arg" dependon="attach"

This way all below are valid:

  scan --dir1
  scan --dir2
  scan --dir1 --dir2
  scan --init --dir1 --dir2
etc.

but these generate errors in parsing phase:

  scan --init --attach-arg
  scan --attach --dir1
  scan --attach --dir2

What do you think about this?

> Of course, one could perform checks manually, but one would want most of
> the checks to be performed automatically, right? :-)

Of course, I can work around it and I think I'll indeed do that while gengetopt comes up with this new feature. I just started to think louldy in the list ...


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> 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:

if (args_info->@option_var_name@_given && ! args_info->@dep_option@_given)
  {
...
  }

But I don't know how. (It was a long time ago when I made changes to the gengetopt source...)
So here is my theory as a pseudo code:

if (args_info->@option_var_name@_given
    && !(args_info->@dep_option@_given

#if @dep_option@ is flag
        || args_info->@dep_option@_flag
#elif @dep_option@ has arg
        || !args_info->@dep_option@_arg
#endif

        ))
  {
...
  }

AFAIR gengen supports some kind of #if .. #endif contructs.

> defgroup "mode"
> groupoption "init"   default="..." group="mode"
> groupoption "attach"               group="mode"
>
> option "dir1" dependon="init"
> option "dir2" dependon="init"
>
> option "attach-arg" dependon="attach"
>
> This way all below are valid:
>
>   scan --dir1
>   scan --dir2
>   scan --dir1 --dir2
>   scan --init --dir1 --dir2
> etc.
>
> but these generate errors in parsing phase:
>
>   scan --init --attach-arg
>   scan --attach --dir1
>   scan --attach --dir2
>

_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> > 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;
  }


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:
> 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.)

yes probably this is quite a clean semantics:

- check that only one group option has a default
- set the default
- then use only the _given field to check conflicts

probably this should do

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

indeed, my main idea was to depecrate them and remove them in new releases

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

great :-)
then as soon as I have something ready I'll post it!

cheers
        Lorenzo

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> then as soon as I have something ready I'll post it!

It means I may except this feature will be included, too:

> - check that only one group option has a default
> - set the default
> - then use only the _given field to check conflicts

The check is performed at compile time by gengetopt while the others at runtime by the generated source. This way a default group option (groupdefault?) will behave exactly the same as if it were specified by the user at commandline. Am I right?

Btw, default group option resembles to "flag on" a little bit however makes much more sense because to make default one of option from a mutually exlcusive group makes sense ;)

I remember now that some gengetopt users were asking in the list how to deal with more than one .ggo files each one defining options of different "subcommands" to the application. If default group option (groupdefault in short) was implemented such subcommands (with their multiple .ggo files) may be converted into a single .ggo file. Not always but sometimes it can be very handy...


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Andre Noll]

On 14:46, Lorenzo Bettini wrote:

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

Yes, that would be _very_ useful. There are many programs that have
"general" options such as --verbose as well as "subcommand" options
(like Papp Gyozo's --init, --attach), each of which requires its own
set of options.

Regards
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi

nice to hear about the new gengetopt version.
I kindly ask what's about this groupoption refactoring?

--
Papp, Gyozo
Virusbuster Kft

---

From: Papp Gyozo (VBuster) [mailto:gypapp@...]
To: Users list for gengetopt [mailto:help-gengetopt@...]
Sent: Fri, 15 Jun 2007 14:27:01 +0200
Subject: Re: [help-gengetopt] mutually exclusive group of options

> then as soon as I have something ready I'll post it!

It means I may except this feature will be included, too:

> - check that only one group option has a default
> - set the default
> - then use only the _given field to check conflicts

The check is performed at compile time by gengetopt while the others at runtime by the generated source. This way a default group option (groupdefault?) will behave exactly the same as if it were specified by the user at commandline. Am I right?

Btw, default group option resembles to "flag on" a little bit however makes much more sense because to make default one of option from a mutually exlcusive group makes sense ;)

I remember now that some gengetopt users were asking in the list how to deal with more than one .ggo files each one defining options of different "subcommands" to the application. If default group option (groupdefault in short) was implemented such subcommands (with their multiple .ggo files) may be converted into a single .ggo file. Not always but sometimes it can be very handy...


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:
> Hi
>
> nice to hear about the new gengetopt version.
> I kindly ask what's about this groupoption refactoring?
>

Hi there

I was thinking of working on that during July; hope to have something
ready soon

cheers
        Lorenzo

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Gyozo Papp]

> > nice to hear about the new gengetopt version.
> > I kindly ask what's about this groupoption refactoring?

It sounds great. do not misunderstand me!
I don't know if we agreed on a clear solution. Did we?

We were talking about it would be great if groups can be mutually
exclusive and one can define default option(s) from a specfic group as
if it was declaered at the commandline (in case of any other mutually
exlusive option is missing). Something like that?

--
Papp, Gyozo


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt