bugs in autotools wrapper scripts

[Charles Wilson]

Eric Blake wrote:
> 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.

True.

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

Yes.  The reason for all this cruft in the wrappers was to support the 
<stdin> behavior that the underlying tools do: the wrappers grab the 
stuff from stdin, save it to a tmp file, and then re-invoke the actual 
tools -- but they must use slightly different options, and point the 
actual tool to the temp file instead of stdin.

I note that the wrappers used by most linux systems do NOT support this 
feature of the underlying tools.

I've been thinking for a long time of ditching the current wrappers and 
using something more like the linux distros do -- and sacrificing the 
<stdin> behavior, just like they do.

So here's the question: does anybody actually USE <stdin> with the 
autotools?  Does ANYBODY do '<some prog that generates a configure.ac on 
stdout> | autoconf' ?

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

Depending on the response to my question above, I'll probably adopt 
something like this ... but we'll have a fairly long probationary period 
where the wrappers are in 'test' status, regardless.

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

Let's wait and see what develops on the "Do you use <stdin> + autotools" 
question.  And thanks for your interest and pro-activeness.  THIS is 
what opensource development should be like.

--
Chuck
autotools-wrapper maintainer

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