Re: mtime of installed files

[Ralf Wildenhues]

Hi Ludovic,

* Ludovic Courtès wrote on Wed, Jul 21, 2010 at 06:27:46PM CEST:
> Ralf Wildenhues writes:
> > * Ludovic Courtès wrote on Tue, Jul 20, 2010 at 06:28:46PM CEST:
> >> For this to work, we need “make install” to guarantee the relation
> >> mtime(installed-object) >= mtime(installed-source), assuming we have
> >> mtime(builddir-object) >= mtime(srcdir-source), which will always be the
> >> case unless the computer’s clock is skewed.
> >> 
> >> Do Automake-generated makefiles provide such a guarantee?  Regardless of
> >> the ‘make’ implementation, OS, etc.?

> > Anyway, most of the time, these issues can be worked around, for example
> > by sleeping for a second before building builddir objects, or between
> > installing sources and installing object files, depending on whether
> > install -C is used or not.
> 
> The latter would be faster IIUC (sleep 1 second instead of N seconds,
> with N the number of source files.)

I'm not sure I understand.  I didn't mean you should sleep separately
for each of the objects.  Sleeping just once overall should be enough.
This semantics should not (need to) depend on whether 'install -C' is
used or not.

> The ‘install’ command is chosen by Automake or the user-specified
> $INSTALL, so we can’t really determine whether it uses ‘-C’, right?

Typically, that is right; well, at least we don't set it, the user does.

I'm not sure how -C helps you, though: it just doesn't update the time
stamp of a file already installed with the same contents; there is no
relation between stamps of different installed files.

> > Hope that helps.  It might be a bit tricky or ugly to actually put this
> > sleep command in a normal automake Makefile.am, so if you know what
> > exactly you need, we can create an example.
> 
> A typical Makefile.am looks like this:
> 
> --8<---------------cut here---------------start------------->8---
> dist_foobar_SOURCES = foo.scm bar.scm
> nodist_foobar_DATA  = foo.go bar.go
> 
> .scm.go:
>         guile-tools compile -o $@ $<
> --8<---------------cut here---------------end--------------->8---
> 
> Actually we currently have this hook, which Andy added some time ago
> (here $(moddir) contains installed source files and $(ccachedir) is for
> installed object files):
> 
> --8<---------------cut here---------------start------------->8---
> install-data-hook:
>       @$(am__vpath_adj_setup) \
>       list='$(nobase_mod_DATA)'; for p in $$list; do \
>         if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
>         $(am__vpath_adj) \
>         echo " touch -r '$$d$$p' '$(DESTDIR)$(moddir)/$$f'"; \
>         touch -r "$$d$$p" "$(DESTDIR)$(moddir)/$$f"; \
>       done
>       @$(am__vpath_adj_setup) \
>       list='$(nobase_ccache_DATA)'; for p in $$list; do \
>         if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
>         $(am__vpath_adj) \
>         echo " touch -r '$$d$$p' '$(DESTDIR)$(ccachedir)/$$f'"; \
>         touch -r "$$d$$p" "$(DESTDIR)$(ccachedir)/$$f"; \
>       done
> --8<---------------cut here---------------end--------------->8---
> 
> IIUC it copies timestamps from $(srcdir) and $(builddir) to the
> corresponding installed files.
> 
> It looks like this is all we need, right?

The code depends on internal Automake APIs am__vpath_adj_setup and
am__vpath_adj so is in principle not safe against Automake upgrades.

For extensibility (the user might need an install-data-hook for other
reasons too) you should write it somehow like:

  install-data-hook: guile-install-data-hook
  guile-install-data-hook:
        ... commands ...

  .PHONY: guile-install-data-hook

because only one set of rule commands is allowed with a non-double-colon
rule.

Then, the code ensures installed files have the same stamps as the
uninstalled ones, but that is not actually what you need: you need
to have newer timestamps on the installed objects over the installed
sources.

Now I need to ask in more detail: do you actually need "newer" or just
"not older"?  Because if the latter, then you could just let the rule to
install $(nodist_foobar_DATA) depend on the rule to install
$(dist_foobar_SOURCES), the latter of which I assume you still need to
write, and hook to install-data-local.  Or you do something like
  mod_DATA = $(dist_foobar_SOURCES)
  ccache_DATA = $(nodist_foobar_DATA)

The install rules then still have internal names
(install-nodist_foobarDATA or install-ccacheDATA or so) but at least the
right thing happens, as long as the same $(INSTALL_DATA) command is used
in both cases.

And if you need "newer" then you could "sleep 1" as last bit of your
hand-written rule to install $(dist_foobar_SOURCES), or let the
install-ccacheDATA depend on a guile-install-sleep helper rule which
itself depends on the install-nodist_foobarDATA rule or so.
However, that doesn't help you when "install -C" is used.

Now, there's one more technical complication for adding the dependency:
automake will not put out its own install-ccacheDATA rule if you use it
as target anywhere (on the grounds that it's the only method to override
an automake-provided target), which you don't want here; you can trick
automake by assigning the name to some variable though:
  guile_install_ccacheDATA = install-ccacheDATA
  $(guile_install_ccacheDATA): install-modDATA

> Problem is, each package that installs Guile object and source files
> needs this hook...

Well, for that you could put the code into a guile-rules.am fragment and
advise your users to put something like

include $(top_srcdir)/build-aux/guile-rules.am

into their Makefile.am files that need it.

Cheers,
Ralf