[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mtime of fresh .go

From: Ludovic Courtès
Subject: Re: mtime of fresh .go
Date: Mon, 19 Jul 2010 00:31:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)


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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]