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').