This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: bugs in autotools wrapper scripts
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Sat, 20 Nov 2004 15:26:51 -0500
- Subject: Re: bugs in autotools wrapper scripts
- References: <419F9721.5000808@byu.net>
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/