autoconf-patches
[Top][All Lists]
Advanced

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

Re: HP-UX make causes autoconf timestamp issues


From: Eric Blake
Subject: Re: HP-UX make causes autoconf timestamp issues
Date: Mon, 24 Jan 2011 09:14:49 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

[dropping bug-automake]

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, 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?

> 
> 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?  That is, is it only an autoconf bug,
where if you fix the autoconf bug, then all other victims will be fixed?
 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).

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

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.

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

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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