[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HP-UX make causes autoconf timestamp issues

From: Ralf Wildenhues
Subject: Re: HP-UX make causes autoconf timestamp issues
Date: Mon, 24 Jan 2011 22:00:07 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Eric,

thanks for the reviews!

* Eric Blake wrote on Mon, Jan 24, 2011 at 05:14:49PM CET:
> On 01/23/2011 03:56 AM, Ralf Wildenhues wrote:
> > all due to the bug that HP-UX make considers targets out of date when
> > they have the same time stamp as a prerequisite (cf. pending
> > autoconf.texi patch).  The symptom is that autoconf is triggered during
> > `make distcheck' due to aclocal.m4 having same time stamp as configure,
> > which of course then fails in the read-only distdir tree:
> > My question is, (how) should autotools cater to this HP-UX make wart?
> > Many users might use GNU make for their projects anyway, for them it
> > would not be nice to turn off caching outright.
> Is there any way to detect which make is in effect,

I guess we can look at uname output for HP-UX, and whether ${MAKE-make}
is GNU or not.

> as to whether to use
> the cache?  That is, maybe teach autom4te to see which make is on PATH
> and ignore the cache directory if the platform is HP-UX but gmake is not
> present?

Could be done.  But see below.

> > Thus I suggest to document the issue, as below.  I'm turning off
> > autom4te.cache for my future testing on this system.

> >     Recommend turning off autom4te.cache for HP-UX make.
> >     
> >     * BUGS: Document HP-UX make bug causing failed autom4te.cache
> >     creation during `make distcheck'.
> Is BUGS the right place for this?

No idea really.  I should have written RFC, as this was more of a post
to get discussion going.

> That is, is it only an autoconf bug,
> where if you fix the autoconf bug, then all other victims will be fixed?

No.  If you are building from a read-only tree, or, more generally, any
source tree that has been generated elsewhere and that is not supposed
to see updates, and the tree has rules that update shipped files, then
there are potentially problems with HP-UX make.

This can affect shipped gperf output as much as it can affect lex or
yacc output.  Or generated autotools files.  Basically, HP-UX make is
just broken in this respect.  HP-UX make also causes repeated 'make'
invocations to rebuild things a few times on a fast machine.  The
behavior is a pain on file systems with second granularity only.

> I think this belongs in BUGS only if we think there might be a way to
> teach autom4te how to not cause problems with autom4te timestamps when
> run on HP-UX, in a manner transparent to the user.
> Independent of the BUGS question, I think that this is something that
> should be documented in INSTALL, since it affects end users as well as
> developers, even on platforms that do _not_ have autoconf installed, but
> do have a package with an autoconf-generated configure script along with
> an automake-generated makefile.  That is, the mere presence of  an
> autom4te.cache file can cause spurious failures for random packages due
> to the HP-UX make bug, so the only document that also gets put in random
> packages (INSTALL) should mention how to work around the make bug by
> avoiding autom4te.cache on that platform (we already use INSTALL as the
> vehicle for documenting our recommendation of avoiding make VPATH bugs,
> so this falls in that same category).

Yes.  Even more generally, we might just want to warn against any use of
HP-UX make at all for building off of tarballs.

> > --- a/BUGS
> > +++ b/BUGS
> > @@ -35,3 +35,8 @@ and use with caution an Autoconf with ``Important bugs''.
> >    possible that other difficulties will be encountered, whether with
> >    shell or platform limitations; help is appreciated in improving
> >    parallel testsuite support.
> > +
> > +* The non-Posix time stamp semantics of HP-UX make can cause Automake's
> > +  `make distcheck' to fail due to failed autom4te.cache directory creation.
> Can we reword this to be more broad, maybe:
> The non-Posix time stamp semantics of HP-UX make coupled with
> autom4te.cache directory creation can cause spurious failures in
> testsuites of various projects.

Why testsuites?  This make can cause failure if you just do

gzip -dc foo-1.2.tar.gz | tar xf -
cd foo-1.2

because due to how time stamps are, aclocal or autoconf reruns might be
triggered (and might fail, due to version skew, non-presence, or what
not else).

How about:

The non-Posix time stamp semantics of HP-UX make can cause spurious
rebuilds of generated files in the source tree.

and then continue with this:

> > +  It is recommended to turn off autom4te caching on these systems if GNU
> > +  make cannot be used (see info Autoconf 'Customizing autom4te').


reply via email to

[Prev in Thread] Current Thread [Next in Thread]