[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mtime of fresh .go
From: |
Andy Wingo |
Subject: |
Re: mtime of fresh .go |
Date: |
Mon, 19 Jul 2010 21:10:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Greets,
On Mon 19 Jul 2010 00:31, address@hidden (Ludovic Courtès) writes:
> Andy Wingo <address@hidden> writes:
>
>> On Fri 16 Jul 2010 10:07, address@hidden (Ludovic Courtès) writes:
>>
>>> commit 535fb833b34dfc3cc11a679d39390b06fd7e9180
>>> Author: Andy Wingo <address@hidden>
>>> 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/
- mtime of fresh .go, Ludovic Courtès, 2010/07/16
- Re: mtime of fresh .go, Andy Wingo, 2010/07/18
- Re: mtime of fresh .go, Ludovic Courtès, 2010/07/18
- Re: mtime of fresh .go, Andy Wingo, 2010/07/20
- Re: mtime of fresh .go, Ludovic Courtès, 2010/07/20
- Re: mtime of fresh .go, Andy Wingo, 2010/07/20
- Re: mtime of fresh .go, Ludovic Courtès, 2010/07/21