Mail Archives: cygwin/2004/11/20/15:27:47
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/
- Raw text -