[racket-dev] module mismatch with .zos

Besides what Eli says, another approach is to run 'raco setup -Dxi'
after getting things out of perforce. That uses hashes for the files
to determine what to compile (so nothing will get compiled if the zos
are actually right), but it updates the timestamps (so racket won't
get confused). This is probably easier/better than changing racket to
ignore .rkt files.

(FWIW, it is not really wrong to consider this behavior a bug at a
number of different levels (why rely on timestamps? why does
compilation not produce the same thing each time?) and it is something
we've struggled with for a long time, so maybe your experience here
will give us another piece to the puzzle on dealing with this issue
overall.)

Robby

On Tue, Oct 16, 2012 at 1:56 PM, Eli Barzilay <eli at barzilay.org> wrote:
> A few minutes ago, Dan Liebgold wrote:
>> It seems like the timestamps among just the .zo and .dep files will cause us
>> issues as well due to how Perforce works. When you sync, Perforce sets the
>> timestamp of the file to the time of sync. If I sync all of a Racket
>> distribution my file timestamps will not be coherent from Racket's point of
>> view, right?
>>
>> As far as I can tell, one of these things must change for our setup to be
>> reliable:
>>
>> - use of precompilation (going without .zos entirely should eliminate this
>> problem)
>> - use of Perforce; with proper timestamps Racket will not complain
>> - the compilation manager; if we change the default implementation to ignore
>> timestamps and just go by file existence we should be ok
>>
>> Does this sound like an accurate assessment?
>
> FWIW, it sounds like a bad idea to distribute .zo files (or any other
> compilation results in any language) through a CMS.  You'd get the
> same problems with git, and I think that svn was fine but even there
> you'd have some issues to consider.  So I'd get rid of #2.
>
> I also think that #3 is dangerous -- it looks like it's a recipe for
> all kinds of nasty surprises when things don't work right.
>
> I'd try to go with a variant of #1: have a simple conventional
> repository with just source code files.  Then tell people how to get
> it to build so work can go on as usual.  And finally, you can do
> something similar to what we use in the nightly builds (though
> probably everyone ignores it these days): compile the tree yourself,
> and create a tarball with the resulting .zo and .dep files, then write
> a quick script that untars it on top of a repository.  I don't know if
> perforce has any scriptability feature, but with git the whole thing
> can be packaged into a new in-house git command.
>
> But to make it more complete -- if you still want to try the .zo
> distribution via the repository, you can try to make people use `raco
> setup' with the `--trust-zos' flag which (IIRC) makes it assume that
> the zo files are all updated and just update the file time stamps.
> (I'm not completely sure about it; but I do remember this being added
> as a result of a similar situation where you end up with the correct
> .zo files but broken time stamps.)
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!