Re: stamp-vti and OpenBSD make

[Ralf Wildenhues]

Hi Bruno,

* Bruno Haible wrote on Sat, May 15, 2010 at 03:13:07PM CEST:
> I'm trying to build a slightly modified libunistring-0.9.3
> on OpenBSD 4.5. With GNU make, there is no problem. But with
> /usr/bin/make, I get this error:

Thanks for the good bug report and analysis.

[...]
> (1)   all: all-am
> 
> (2)   all-am: Makefile $(INFO_DEPS) all-local
>       INFO_DEPS = $(srcdir)/libunistring.info
> 
> (3)   .texi.info:
>       ...
> 
> (4)   $(srcdir)/libunistring.info: libunistring.texi $(srcdir)/version.texi 
> $(libunistring_TEXINFOS)
> 
> (5)   $(srcdir)/version.texi:  $(srcdir)/stamp-vti
> 
> (6)   $(srcdir)/stamp-vti: libunistring.texi $(top_srcdir)/configure
>       ...
> 
> Rules (1)-(6) are all generated by automake.
> 
> The problem is that the stamp-vti rule (6) can leave on disk a stamp-vti
> file that is newer than version.texi. The OpenBSD 'make' then interprets
> rule (5) as a declaration that version.texi is out-of-date. But when
> version.texi is out-of-date, rule (4) says that libunistring.info
> should be rebuilt, and this requires more than the "usual tools"
> (namely, a new enough 'makeinfo' program).
> 
> Can the stamp-vti handling be rewritten some way?

We might be able to ensure that version.texi and stamp-vti have the same
time stamp on OpenBSD systems.  But I'd like to find out first why these
rules were done the weird way they look now.  It'll likely be the
weekend until I get to this though.

> Or should the GNU standards and the INSTALL file be changed to specify
> that on OpenBSD, GNU 'make' is necessary for building packages?

No.  It seems wrong to amend GCS in order to legitimize an Automake bug.
Well, if OpenBSD make behavior really is Posix-conforming, that is.  I
think I've seen similar behavior on other BSDs as well, though.

Cheers,
Ralf