#4012: Compilation results are not deterministic
-----------------------------------+----------------------------------------
Reporter: kili | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.2
Resolution: | Keywords:
Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Other | Patch: 0
-----------------------------------+----------------------------------------
Comment(by kili):
Replying to [comment:5 simonmar]:
> The bootstrapping GHC is a red herring, as I mentioned - the fact is
that compilation results aren't deterministic. They never have been, in
fact.
And it's good that the problems are detected now with the hashes.
> Even if compilation results were deterministic, under what circumstances
would you want to have two systems "use each others packages", when
they're both using a GHC independently built from source? If they
independently build GHC from source, why wouldn't they build packages from
source too?
For example, if two persons are working on a ghc package for their
operating system, and also on updates for all the stuff that needs ghc
(xmonad, alex, happy, monadius, to mention the most important ones), it's
a pity if they're not able to exchange packages.
You mentioned that even a `make clean; make' may change the interfaces.
Indeed, I remember at least one case where ghc segfailted during the build
(this doesn't happen often, only every 20th or 30th build) and I just
restarted the build -- and got interface changes.
> Note that packages are registered with an MD5 hash of the interface, so
the package system will spot if you try to register an incompatible
package.
And that's good, but it's just a workaround, UMHO.
> Anyway, I do agree that having deterministic compilation results is a
desirable thing, so on second thoughts I've re-opened the bug and retitled
it.
Thanks. But is this really *one* Bug? There are the problems with non-
determinisms, but I think that the CSE on inlined constants (like
cBooterVersion and cProjectVersion) is a separate problem.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4012#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
