Since we fixed autoconf/lib/autom4te.cfg in Autoconf 2.60, now when we
call $ACLOCAL, the traces that were created by the $AUTOCONF before are
sufficient; and since they appear with the same time stamp as all known
input files to aclocal.m4, they are used by autom4te. So we have to
tell the
* quoting myself:
Since we fixed autoconf/lib/autom4te.cfg in Autoconf 2.60
The reasoning was wrong, the patch should still be right.
First, autoconf/lib/autom4te.in (sic) was fixed only after 2.60,
but second it was broken only for automake, not for aclocal.
So. There you have it. Now,
I have noticed the following problem (bug) in automake-1.10:
(1) A package (ImageMagick-6.3.0) uses configure to generate manpages with
substitutions (e.g., .1 from .1.in) but also distributes the
generated manpages from an older version (i.e., with wrong substitutions).
(2) The
Hello Greg and Ralf,
I think I have found the bug now.
There were two suspects: aclocal and autoconf.
First, I tried to find out whether aclocal does its work correctly by
that unfortunate grep (should have been `grep acinclude aclocal.m4').
But then Greg posted the diff, and I had an idea:
Hello,
some time ago I noticed that autom4te calls m4 with stdin redirected
to /dev/null. The redirection was a hack to work around a problem
with CVS m4.
The bug was discussed here
http://lists.gnu.org/archive/html/m4-discuss/2006-04/threads.html
and resolved by Eric here
Hello Stepan,
* Stepan Kasal wrote on Tue, Oct 24, 2006 at 09:09:48PM CEST:
This patch was one of the two pre-requisities for teaching autom4te
to handle `-' as a command line parameter.
I hate to spoil the party, but I'd like to add a couple more
prerequisites mentioned in HACKING:
- a NEWS
On Tue, Oct 24, 2006 at 06:04:30PM +0200, Stepan Kasal wrote:
I think I have found the bug now.
...
The fix is obvious: `autom4te' should always create the output file,
if --force was given. Patch attached.
I committed it to the Autoconf CVS.
Greg, if you are willing to test the fix,
