This certainly does look like a bug. However, AC_MSG_RESULT should not
be needed because the AC_CACHE_CHECK should already have printed out the
result. I would suggest the following simpler patch instead:
2001-03-13 Steven G. Johnson <[EMAIL PROTECTED]>
* aclang.m4 (AC_PROG_F77_C_O):
On Mar 12, 2001, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> However, invoking config.status like the line below will also cause
> config.status to execute the EXTRA-COMMANDS argument for config.status.
> CONFIG_FILES=dstfile CONFIG_HEADERS= CONFIG_LINKS= ./config.status
Yep. You left `CONFIG
Invoking config.status like the below line will only create dstfile.
./config.status --file=dstfile
However, invoking config.status like the line below will also cause
config.status to execute the EXTRA-COMMANDS argument for config.status.
CONFIG_FILES=dstfile CONFIG_HEADERS= CONFIG_LINKS=
(sorry if I just posted this - random keystrokes made me miss what mutt
was doing)
Anyways, I've found out that invoking config.status in the following
two ways doesn't produce the same result:
1) ./config.status --file=dstfile
2) CONFIG_FILES=dstfile CONFIG_HEADERS= CONFIG_LINKS= ./config.s
I just tried out today's cvs tree on NetBSD-1.5S/i386. The tests give me the
usual Fortran problem - fair enough I still haven't found what it's meant to
do - but on the way this appeared:
2: tools.at:76 testsuite: warning: no at-check-line which means a
failure happened
testsuite: warnin
I just checked the new cvs version of autoconf, and found something
strange in the above macro that would behave axectly opoosite as it should
(I suppose).
I suggest:
--- aclang.m4.cvs Mon Mar 12 14:32:36 2001
+++ aclang.m4 Mon Mar 12 14:33:14 2001
@@ -1331,7 +1331,10 @@
fi
rm -f conf
