Re: mtime of installed files

[Ludovic Courtès]

Hi Ralf,

Ralf Wildenhues <address@hidden> writes:

> * Ludovic Courtès wrote on Tue, Jul 20, 2010 at 06:28:46PM CEST:
>> Background: Guile 1.9/2.0 has an auto-compilation feature whereby if a
>> source file has no corresponding object file in the search path, or if
>> the object file is older than the source file, then the source file is
>> automatically recompiled and stored in ~/.cache/guile/ccache.
>
> I assume this part has nothing to do with Automake per se, right?

Right.

>> Packages that use Guile can also choose to pre-compile all their source
>> files and install both the source and object files.  This saves the need
>> for users to auto-compile the source.  (This is what Guile does with its
>> own source files.)
>
> I assume this, too, is currently done without help of Automake, or make,
> for that matter.

Correct.

>> 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.?
>
> This is actually a tough question; it has little to do with Automake,
> much more with any or all of make, tar, cp, touch, install, libc, file
> system, and the kernel.
>
> `info Autoconf --index timestamp' leads to two nodes describing some of
> the problems with time stamps.  The gist is that in the worst case, any
> of the above tools independently may have full or only limited timestamp
> resolution (nowadays that would mostly be either nanosecond or 1 second).
> Even well-run software distributions without user-compiled tools
> typically can't afford to (or don't) update all of these tools at once.

Indeed.  Thanks for the pointer.

[...]

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

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

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

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

Thanks,
Ludo’.