
I wonder if this is the source of the problem I had with ^C'ing parallel rebuilds. I'll often build, realizing I should be doing something differently, ^C out, tweak something start a build again, etc. but if I have -j on then I find that doing so occasionally causes me to start missing dyn_hi files after the package builds. If I ^C'd in between generating one and the other being written, could that be what is causing other consistency problems later in my build? I've hesitated on reporting it (other than mentioning it in passing to Austin) because it has been fiendishly hard to reproduce and only happens on my more er.. monolithic projects. I've gone back to sequential builds as a result of this though. -Edward On Mon, Jun 23, 2014 at 1:58 PM, Christopher Rodrigues < pointlessmonad@gmail.com> wrote:
Hello,
I’ve investigated an issue (#9176) where ghc with --make -dynamic-too appears to run successfully but doesn’t generate some .dyn_hi files. The cause seems to be that GHC silently turns off dynamic-too output when it finds an inconsistency between the .hi and .dyn_hi interface hashes of an imported module. The symptom, for me, is that some cabal packages will build but fail to install. The real problem is most likely not in the failing package, but in an imported module from a package that’s already installed.
I’m inclined to say that GHC should stop with an error in this situation, which would produce a visible error when the file fails to compile. However, since GHC carefully avoids bailing out, I wonder if I’m missing something. Is there a good reason to turn off dynamic-too output instead of reporting an error?
Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with different interface hashes? Or is it invalid data, in the same way that a corrupted .hi file is invalid data? I’m inclined to say that it is invalid data, because -dynamic-too promises to generate two different (static and dynamic) implementations of the same Haskell code, taking two different implementations of the same imported Haskell modules as input. If the inputs aren’t really two different implementations of the same Haskell code, you’ve somehow provided invalid input.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs