autoconf-patches
[Top][All Lists]
Advanced

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

HP-UX make causes autoconf timestamp issues


From: Ralf Wildenhues
Subject: HP-UX make causes autoconf timestamp issues
Date: Sun, 23 Jan 2011 11:56:04 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

http://autobuild.josefsson.org/automake/log-201101181921247117000.txt
This HP-UX 11.31 system is fast enough to trigger test failures for
at least these Automake tests, besides the ones already fixed:

insthook
libobj16b
output10
posixsubst-data
posixsubst-scripts
subcond2
subpkg2
suffix13

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:

+ make distcheck
[...]
        CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh 
/tmp/build-ia64-hp-hpux11.31/tests/libobj16b.dir/libobj16b-1.0/missing --run 
autoconf
autom4te: cannot create autom4te.cache: No such file or directory

Now, with even faster systems, that problem will only get worse over
time, i.e., happen in many more tests, and maybe also in user projects.

Question is what to do about it.  Possibilities include:

- Add $sleep after every $ACLOCAL in problematic cases.  Not
  maintainable.
- sleep in aclocal, or even autom4te.  Ugh!
- Let autom4te not fail if, in a read-only directory, autom4te.cache
  creation fails but configure is actually up to date (seems doable,
  but would probably require a number of changes in Autoconf).
- Work around it by using a global cache (not so good) or turning off
  autom4te.cache creation completely, on HP-UX.  Modify Autoconf to do
  so by default, or at least recommend it?

The latter point deserves some explanation as to why I think it works:

autom4te updates an output file if at least one of its inputs is not
older than an existing output file.  IOW, the semantics actually match
that of HP-UX make.  Not using a cache means configure will be updated
at the first time $MAKE is run, and since files created after configure
are strictly newer than files created before, all will be well; at least
until one more dependency level is added to the bootstrap chain.
(Boy, am I glad gnulib-tool and aclocal are so slow.)

If a global autom4te.cache is used (which IIRC still has some bugs),
then autom4te will detect that configure doesn't change, but of course
time stamps persist in the problematic state, so several harmless but
time-consuming autoconf reruns will be triggered from within '$MAKE
distcheck'.  So this works reliably, but is a bit suboptimal.


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.

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

Thanks,
Ralf

    Recommend turning off autom4te.cache for HP-UX make.
    
    * BUGS: Document HP-UX make bug causing failed autom4te.cache
    creation during `make distcheck'.

diff --git a/BUGS b/BUGS
index 82c438e..6c95934 100644
--- 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.
+  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]