GHC silently turns off dynamic output, should this be an error?

[Edward Kmett]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140623/ba564734/attachment.html>