On 2011-04-28 15:23 +0000, malcolm.wallace wrote: > Then I suggest that your build tools are broken. Rebuilding should > not depend on an _ordering_ between modification times of source and > object, merely on whether the timestamp of the source file is > different to its timestamp the last time we looked. (This requires > your build tools to keep a journal/log, yes, but it is the only safe > way to do it.)
Right. The /order/ of the timestamps is wrong when a build directory is shared between repositories (isn't that what I said?). Try it yourself with cabal: it will fail. Consider two repos, A and B, each with different versions of foo.x, that (when compiled) produces the output foo.y. We store the build in the directory "C". Initially, say A/foo.x has a mtime of 1, and B/foo.x has an mtime of 2. We do a build of A, producing the output file C/foo.y. say C/foo.y now has a mtime of 3. Now we do a build in B. The build system sees that C/foo.y has a mtime of 3, which is newer than B/foo.x's mtime of 2. The build system therefore does not rebuild C/foo.y. > It is relatively common to change source files to have an older > timestamp rather than a newer one. This should not cause your build > system to ignore them. It can happen for any number of reasons: > restoring from backup, switching repository, bisecting the history of > a repo, clock skew on different machines, .... All of these operations update the mtimes on the files... -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
