Re: Extensions to options

On 02/22/2012 09:08 PM, Tim Marston wrote:
> Hi again,
>
> I had a couple of ideas regarding options.
>
> 1. Many programs like to provide "alias" options. For example:
>
>    --quiet    the same as --silent.
>
> Typically, these are added to provide backwards compatibility, or
> compatibility with another piece of software and the lack of support for
> them in gengetopt might be problematic to people switching existing
> software over to it.
>
> I have two suggestions of ways that these could be implemented, but
> neither of them are entirely elegant.
>
> One solution might be to add a new .ggo file directive. For example, of
> the form 'alias<long>  <short>  <aliased option>  {desc="<description>"}'
> and which also takes some parameters ("details", "typestr" and "hidden")
> but inherits the values for others ("argtype", "values", "default",
> "dependon", "required", "argoptional" and "multiple") from the option
> that is being aliased. In terms of generated code, these options would
> simply be another case label in the switch statement that falls through
> to the option being aliased.
>
> The major drawback to the above idea is that it would be hard to specify
> *only* a short option that aliases another. One way round this would be
> to introduce a way to specify that there is no long option (such as
> giving an unquoted '-') that is only permitted in the alias directive.
>
> Another option might be to add two new parameters to option directives
> in the .ggo file. Something like, 'alias_short="<short>"' and
> 'alias_long="<long>"', both of which could be specified multiple times
> for the same option. The downside to this is that there would be no way
> to specify the alias option's "description" or, for example, to specify
> any "details" or a different "typestr" for it.
>
> 2. Facility to make options config-file-only, or command-line-only.
>
> Currently there is no way to limit the contexts in which options are
> permitted. For example, a "--config-file=FILE" option would have no
> place in a config file.
>
> A suggested solution to this would be to add a parameter to option
> directives in the .ggo file to allow the developer to specify the
> contexts in which an option is permitted. For example,
> 'context="<context1>","<context2>",...' where the context values are,
> basically, the names of the parsers that will accept the option.
>
> Another thing to consider here is that programs sometimes have system
> configuration files, and user configurations files. Some options may not
> be appropriate for one or the other. These contexts would of course be
> application-dependent.
>
> All the best,
>

Concerning this I can only say that it looks interesting, but, again:

For the moment, I cannot add any new feature to gengetopt myself: it's 
such a busy moment that I really can't work on it... especially if it 
requires to write C code (as opposite to C++ code), as in the case of 
the runtime wrapping...

Of course, if you can provide patches (and unit test cases) I'll be 
happy to collaborate

cheers
	Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
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