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/RecompilationAv... 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