Re: Automated Option Processing for Guile

[Bruce Korb]

Marius Vollmer wrote:
> 
> Bruce Korb <address@hidden> writes:
> 
> > Why would you *not* want to use it?  ;-)
> 
> We already have "ice-9/getopt-long.scm".  In what way does AutoOpt
> differ from this?

ice-9/getopt-long.scm does not handle:

1.  environment variables
2.  rc/ini/config files (whatever you want to call them)
3.  partial matches on long option names
4.  generation of usage text
5.  option interdependencies (-a can only be used if -b
    is present and cannot be used if -c is present)
6.  generate a man page
7.  generate the ``invoking'' section of a texinfo doc

This was paraphrased from the features section of the
AutoOpts chapter of AutoGen:

  http://AutoGen.SourceForge.net/doc/autogen_6.html

Of course, it *also* differs in that the quick hack
I did to insert the data into  the Guile name space
does not produce the structure that getopt-long.scm
does.  Instead of putting the data in an association
list, they are put into top-level definitions a la:

> I then generated a complete program and ran it thus:
> 
> > test_guile -s 'value 1 for second.' -s 'value number two' <<EOF
> > have-opt-second
> > opt-enabled-second
> > opt-ct-second
> > opt-args-second
> > have-opt-option
> > opt-enabled-option
> > EOF
> 
> The output was this:
> 
> > guile> #t
> > guile> #t
> > guile> 2
> > guile> ("value 1 for second." "value number two")
> > guile> #f
> > guile> #t
> > guile> 

Obviously, it would not be difficult to export the data in another
form.  This way was just quick, easy and had obvious usage for me.

Another big difference, of course, is that AutoOpts currently
must have C text linked into the executable.  What that means is
that were there sufficient interest, AutoOpts could be taught to
emit the getopt-long.scm alist + the usage text.  That way, even
without linking a new main() you still get #-s 4, 6 and 7 above.

Is that enough reason?