in some respects, having fully deterministic builds is a very important goal: a lot of tooling for eg, caching builds of libraries works much much better if you have that property :)
On Tue, Oct 7, 2014 at 12:45 PM, <[email protected]> wrote: > > ________________________________________ > From: [email protected] <[email protected]> on behalf of Austin Seipp < > [email protected]> > > So I assume your change would mean 'ghc -j' would not work for 32bit. > I still consider this a big limitation, one which is only due to an > implementation detail. But we need to confirm this will actually fix > any bottlenecks first though before getting to that point. > > > > > Yes, that's what I'm saying. > > Let me just add that what I'm proposing by no means prohibits or hinders > making 32-bit GHC-versions be parallel later on, it just doesn't solve the > problem. It depends to what extent the "fully deterministic behaviour" bug > is considered a priority (there was something about parts of the hi-files > being non-deterministic across different executions of GHC; don't recall > the details). > > Anyhow, the work I'm doing now exposes a few things about Uniques that > confuse me a little and that could have been bugs (that maybe never acted > up). Extended e-mail to follow later on. > > Ph. > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
