"Simon Marlow" <[EMAIL PROTECTED]> writes: > Darn. I really thought we'd got this filename stuff cleared up this > time! It seems that every time we try to fix things someone comes up > with a case that isn't handled the way they expect.
I know, these things always turn out to be trickier than we can forsee. :-( > http://www.haskell.org/~simonmar/separate-compilation.html > Please take a look at section 4.6.2. Thanks. Very helpful. The following text prompted me to think of another solution to the problem: "Currently (a bug, really) GHC is not clever enough to spot that the source file has changed, and so there is a danger that the recompilation checker will declare that no recompilation is needed when in fact it is. Solution: delete the interface file first." ... never write a Main.hi file! By definition no other module will ever need to import it, so there is no need to store it. (Hmm, yes, this introduces other problems I suppose, because the re-compilation checker will always insist on recompiling the Main module, even if it hasn't changed.) > It ought to be possible to incorporate your suggestion, but I have a > nagging feeling that I'm forgetting something. Maybe the evil mangler, or ghci dynamic loader (or something low-level like that) expects to find a Main.o file in order to locate the starting address? > > revert to hmake to issue a series of one-shot ghc commands, > > because at least it doesn't miss dependencies, even if it sometimes > > comes up with too many. > > What missed dependencies are you referring to here? Only the dependency of Main.o on Program.hs, nothing else. > I think this is because we don't want 'make' to stop recompiling > dependencies just because the current module didn't need any > recompilation. It might be the case that modules further up the > dependency tree still need recompiling. This is a result of the fact > that .hi files don't contain the transitive closure of stuff they refer > to any more (this change was made for Haskell 1.3, in GHC 2.1). The statement "Suppose module C imports module B, and B imports module A. So changes to A.hi should force a recompilation of C." seemed somewhat counterintuitive to me. Surely there is no /automatic/ need for any and all changes in A to force recompilation of C. Of course some changes /may/ propagate through B, but others might not be visible through B, depending on B's exports. I think the part I didn't fully understand before, is that ghc does not copy the necessary excerpts from A.hi into B.hi, but rather places a reference to them. Thus, even though the "true" (transitively closed) interface of B has changed due to a change in A, the actual .hi file does not change. So, updating the timestamp is just a way of indicating the potential "true" change, whilst the compilation step can be omitted as a performance optimisation. Cool. So, contrary to appearances, hmake is not finding extra spurious dependencies, but rather, ghc is eliding unnecessary compilation steps. Regards, Malcolm _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
