[racket-dev] module mismatch with .zos

From: Eli Barzilay (eli at barzilay.org)
Date: Tue Oct 16 14:56:18 EDT 2012

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!

Posted on the dev mailing list.