Hi Ralf,
> I guess I don't understand why everyone hates stamp files.
I don't like them either [1], from past experience.
Maybe we need to look at the operations that are hurt by stamp files:
- Building distributions. If stamp files are included in a tarball,
then merely unpacking the tarball (with 'cpio', not 'tar') or
copying it (with 'cp -r', not 'cp -a') sets the modification times
of all files, and the modification time of the stamp may end up
being a little bit earlier than the one of the main file.
- Building on a NFS mounted file system, with a time shift between
the server and the client. The problem here was that "echo >> foo"
and "touch foo" assign different time stamps to the file 'foo'.
- Removing or touching the main file by hand must cause a rebuild.
In some variants of the stamp rules, you also had to remove or
touch the stamp file in order to get "make" do something.
- "make -n" ends up rebuilding things, while the developer does not
want "make -n" to do anything.
- Or, "make -n" displays more or less statements than "make" will
actually execute. So "make -n" becomes unreliable.
Paul, Jim, Eric, others, do you remember other problems of stamp files?
> The config.h rule (among others) has been using one for years,
> and the last time I've heard complaints or bug reports about it
> has been years also.
For reference, here's the rules automake generates for config.h:
config.h: stamp-h1
@if test ! -f $@; then \
rm -f stamp-h1; \
$(MAKE) $(AM_MAKEFLAGS) stamp-h1; \
else :; fi
stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
@rm -f stamp-h1
cd $(top_builddir) && $(SHELL) ./config.status config.h
$(srcdir)/config.h.in: $(am__configure_deps)
($(am__cd) $(top_srcdir) && $(AUTOHEADER))
rm -f stamp-h1
touch $@
distclean-hdr:
-rm -f config.h stamp-h1
Is that the kind of rule you would recommend?
Bruno
[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00045.html
--
In memoriam Ludwig Beck <http://en.wikipedia.org/wiki/Ludwig_Beck>
