bugs in autotools wrapper scripts

[Eric Blake]

The autotools wrappers (automake 1.7.9-1, autoconf 2.59-1, and libtool
1.5b-1) all have argument parsing bugs.  They are trying to parse every
option known to either <autotool>-stable or <autotool>-devel, but fail in
several respects.

First, the wrappers are not robust to new options being added.  For example,
libtoolize 1.9f_20041024-1 treats --ltdl as a long-option with an optional
argument, but the wrapper rejects 'libtoolize --ltdl=libltdl'; likewise
aclocal 1.9.2-1 has a --force option which the wrapper rejects.

Second, the wrappers do not recognize multiple short options in a single
argument.  For example, 'automake -fiv' is not treated as equivalent to
'automake -f -i -v'.

And finally, the wrappers do not allow for option rearranging, like the
underlying tools do.  For example, 'automake Makefile --help' does not
recognize the help option and complains that no configure.ac file exists,
while '/usr/autotool/devel/bin/automake Makefile --help' prints the help in
a directory with no configure.ac.

I think it would be smarter to simplify the wrappers by just parsing for
help and version options rather than trying to track every option of the
underlying tool, since only help and version have the special behavior in
the wrapper.  That way the wrapper is immune to the underlying tool adding
options, and lets the underlying tool do multiple short options from
a single argument and option rearranging.  Attached is my proposed patch for
automake, something similar would apply to all the wrappers.  There are two
ambiguous corner cases where we cannot decide whether --help was requested
without tracking every option of the underlying tool; because we do not know
whether the previous option takes an argument.  My patch treats '--option --
--help' as not printing the wrapper help, even if it should mean
'--option=-- --help'; and treats '-zh' as not printing the wrapper help,
even if it should mean '-z -h'.  But this should be okay, as those two
ambiguous uses are rare in practice; and the result is the user will either
get a spurious warning about not having configure.ac, or the underlying tool
will correctly reparse the arguments and print the tool help.

If this approach is not considered satisfactory, and you really want to
maintain the wrappers to know all options of the underlying tool, I can also
prepare patches for that approach that know how to split multiple short
options and how to rearrange arguments.

-- 
Someday, I might put a cute statement here.

Eric Blake             ebb9@byu.net


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: automake.diff
URL: <http://cygwin.com/pipermail/cygwin/attachments/20041120/6a8b70d5/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/