Making compilation results deterministic (#4012)

[Bartosz Nitka]

2015-09-16 12:18 GMT+01:00 Simon Peyton Jones <simonpj at microsoft.com>:

>
> |  My understanding is that currently, if you build a Haskell project
> |  from clean sources with ghc --make, then wipe all the .o/.hi files,
> |  and rebuild again from clean, with all the same flags and environment,
> |  you are unlikely to end up with identical binaries for either the .o
> |  or .hi files
>
> Is that right Bartosz?  If that's the goal, then can we please say that
> explicitly on the wiki page?
>
> Let's hypothesise that it it's the goal. Then I don't understand why, in a
> single-threaded GHC, you would get non-det results.  Presumably not from
> lazy-interface-file-loading.  After all the same things would be loaded in
> the same order, no?
>
> Before we can propose a solution we need to understand the goal; and
> having understood the goal we need to understand why the results are
> non-det right now.   Otherwise we risk fixing the wrong problem.
>
> Anyway, one step at a time :-) Goal first; then a concrete example that
> demonstrates the problem; then a hypothesis of what is going wrong...


There are two related goals here that I'm trying to tackle at the same
time: build speed and binary file compatibility.

I've created a wiki and added a concrete example of how the same
environment leads to different interface files:
https://ghc.haskell.org/trac/ghc/wiki/DeterministicBuilds#Aconcreteexample.
Simon Marlow has already explained what goes wrong there and the difference
is that the first build doesn't have any old interface files that the
second build from the same sources does. This happens often in practice in
production environments when people switch branches. Another way to trigger
it is to remove all the .o files and leave .hi files before rebuilding.

| Depending on exactly what the problem is, one “solution” might be to not
use –make mode.


This is not specific to the --make mode.

I've answered other questions on the wiki.
| Anyway, one step at a time :-) Goal first; then a concrete example that
demonstrates the problem; then a hypothesis of what is going wrong...

I'm sorry, I unloaded everything I've learned about this in one post
without a clear narrative.

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150917/0d3325b8/attachment.html>