Completely reproducible Haskell builds

[Simon Marlow]

On 26/05/2011 17:15, Greg Steuck wrote:
> I am trying to get ghc-7.0.3 build procedure down to a byte-identical
> rebuild on Linux-amd64.

This is likely to be very fragile with GHC at the moment, due to some 
non-deterministic behaviour in its internals.  I have tried to eliminate 
as much as I can, but there are still a couple of known sources, and 
possibly more unknown ones.  See the last bullet point here:

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/RecompilationAvoidance#Interfacestability

Having said that I think it's a good idea to fix any sources of binary 
differences as you're doing.

> The best option for dealing with this seems to be using gcc ability to
> accept input from a pipe. I know I could make this work on a Posix
> system. Yet I suspect getting it to work on Windows would be overly
> onerous.
>
> Next best idea is to make GHC use repeatable temporary .c&  .o file
> names for each invocation. There is already a unique temporary
> directory where all the the temporary files are created. This suggests
> I do not need to worry about adversarial races. So GHC just need to
> avoid racing with itself. I see a couple of options:
>
>    1) newTempName should create a new subdirectory for each call and
>       the return a fixed name inside of this (so /tmp/ghc28016_0/ghc28016_0.c
>       above would become /tmp/ghc28016_0/0/dummy.c)
>    2) mkExtraCObj could compute some hash function of its xs
>       argument (C program text) and then create a file named, e.g.
>       /tmp/ghc28016_0/38eb8d8eb0abe9c828ba60983e2a97f7a069ec41.c
>
> Which of these two looks better? Other ideas?

The first is easier, and would be fine with me.

> Would people be open to accepting a patch along these lines if I were
> to write one?

Sure.  But as I mentioned above, this might not be enough, or at least 
you might still get random differences from time to time.

Cheers,
	Simon