Re: mtime of fresh .go

[Andy Wingo <wingo@pobox.com>]

Greets,

On Mon 19 Jul 2010 00:31, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Fri 16 Jul 2010 10:07, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>>   commit 535fb833b34dfc3cc11a679d39390b06fd7e9180
>>>   Author: Andy Wingo <wingo@pobox.com>
>>>   Date:   Fri Jun 5 10:51:21 2009 +0200
>>>
>>>       stamp .go with timestamp of .scm; a fresh go has same mtime of .scm
>>>
>>>       * libguile/load.c (compiled_is_fresh): Rename from compiled_is_newer.
>>>         Check that the mtines of the .go and .scm match exactly, so we don't
>>>         get fooled by rsync-like modifications of the filesystem.
>>>
>>> When packaging things “normally”, the .go has an mtime strictly greater
>>> than that of the source file, so checking for equality doesn’t work.
>>
>> But when reinstalling code from a binary packaging system, sometimes the
>> mtime can go backwards.
>
> Please forgive my ignorance, but can you give an example of how this can
> happen?

Well there are two cases really:

 * RPM or Deb systems typically timestamp their files based on the times
   they were built, not installed, and we don't have guarantees that
   upgrading a package won't actually move the mtime into the past.

 * When installing source code (via _SOURCES / _DATA), you don't have
   any guarantees about the relations between the times of the SOURCE
   and DATA files, *as installed*.

I think, anyway.

> Besides, what do you think packages that install scm and go files should
> do?

Preserve the timestamps as built, as Guile does.

> A package of mine basically lists .go’s in ‘nodist_foobar_DATA’ and
> .scm’s in ‘foobar_SOURCES’ (or similar).  Having to change the mtime of
> .go’s in ‘install-hook’ seems inconvenient and fragile to me.

I agree, FWIW. I don't know of a better option right now, though. We
should look to see what PLT/Racket does, as our current system has a
number of other disadvantages -- if a macro used by a module changes,
the module should be recompiled. Same goes for procedures called by a
macro used by a module, etc. They do it by linking to openssl (gross)
and doing SHA sums of various files, AFAIK, but I don't know all the
details.

Andy
-- 
http://wingolog.org/