Raja R Harinath wrote:
>
> Hi,
>
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> > An observation with cvs-autoconf and automake-1.4d:
> > # ./configure
> [snip]
> > Note: style of include "include"
> >
> > Now touching/editing configure.in and rerunning make:
> >
> > # touch configure.in
> > # make
> > [..]
> > /bin/sh ./config.status --recheck
> > running /bin/sh ./configure --no-create --no-recursion
> [snip]
> > Note: style of include "#"
>
> I've seen something similar.
AFAIS, any automake based configuration using dependency tracking is
subject to this issue, because AM_DEPENDENCIES "am_requires"
AM_MAKE_INCLUDE (Thanks for the hint, Lars)
> Running './config.status --recheck'
> again seems to fix it.
>
> Unfortunately, the output of make is redirected to /dev/null. My
> suspicion is that this could do with the timestamp warning sometimes
> emitted by GNU make. Is the directory NFS mounted from a Solaris m/c?
No. It is a local filesystem.
Meanwhile, I think to have found the cause.
Somehow, after having touched configure or configure.in, "make" runs
the "include check" by recursively running make.
Due to recursively running make, __gmake__ emits a "Entering
directory ..." message to __stdout__, which interferes with
autoconf's AM_MAKE_INCLUDE check, which expects a string containing
plain "done" instead of
"make[1]:Entering directory ..done", which it actually seems to
receive.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
