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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
