ghci 7.4.1 no longer loading .o files?

[Simon Marlow]

On 27/02/2012 05:08, Evan Laforge wrote:
>>> Indeed it was, I initially thought it wasn't because I wasn't using
>>> flags for either, but then I remember ghci also picks up flags from
>>> ~/.ghci.  Turns out I was using -fno-monomorphism-restriction because
>>> that's convenient for ghci, but not compiling with that.
>>>
>>> I guess in the case where an extension changes the meaning of existing
>>> code it should be included in the fingerprint and make the .o not
>>> load.  But my impression is that most ExtensionFlags let compile code
>>> that wouldn't compile without the flag.  So shouldn't it be safe to
>>> exclude them from the fingerprint?
>>>
>>> Either way, it's a bit confusing when .ghci is slipping in flags that
>>> are handy for testing, because there's nothing that tells you *why*
>>> ghci won't load a particular .o file.
>>
>> After some fiddling, I think that -osuf should probably be omitted
>> from the fingerprint.  I use ghc -c -o x/y/Z.hs.o.  Since I set the
>> output directly, I don't use -osuf.  But since ghci needs to be able
>> to find the .o files, I need to pass it -osuf.  The result is that I
>> need to pass ghc -osuf when compiling to get ghci to load the .o
>> files, even though it doesn't make any difference to ghc -c, which is
>> a somewhat confusing requirement.
>>
>> In fact, since -osuf as well as the -outputdir flags affect the
>> location of the output files, I'd think they wouldn't need to be in
>> the fingerprint either.  They affect the location of the files, not
>> the contents.  If you found the files it means you already figured out
>> what you needed to figure out, it shouldn't matter *how* you found the
>> files.
>>
>> And doesn't the same go for -i?  Isn't it valid to start ghci from a
>> different directory and it should work as long as it's able to find
>> the files to load?
>
> Further updates: this has continued to cause problems for me, and now I'm
> wondering if the CPP flags such as -D shouldn't be omitted from the fingerprint
> too.  Here's the rationale:
>
> I use CPP in a few places to enable or disable some expensive features.  My
> build system knows which files depend on which defines and hence which files to
> rebuild.  However, ghci now has no way of loading all the .o files, since the
> ones that don't depend on the -D flag were probably not compiled with it
> and those that do were.  This also plays havoc with the 'hint' library, which
> is a wrapper around the GHC API.  I can't get it to load any .o files and it's
> hard to debug because it doesn't tell you why it's not loading them.
>
> In addition, ghc --make used to figure out which files depended on the changed
> CPP flags and recompile only those.  Now it unconditionally recompiles
> everything.  I always assumed it was because GHC ran CPP on the files before
> the recompilation checker.
>
> If that's the case, do the CPP flags need to be included in the fingerprint at
> al?  It seems like they're already taken into account by the time the
> fingerprints are calculated.  I reviewed
> http://hackage.haskell.org/trac/ghc/ticket/437 and I noticed there was some
> question about which flags should be included.  Including the language flags
> and -main-is since that was the original motivation (but only for the module it
> applies to, of course) makes sense, but I feel like the rest should be omitted.

I don't see how we could avoid including -D, since it might really 
affect the source of the module that GHC eventually sees.  We've never 
taken -D into account before, and that was incorrect.  I can't explain 
the behaviour you say you saw with older GHC's. unless your CPP flags 
only affected the imports of the module.

Well, one solution would be to take the hash of the source file after 
preprocessing.  That would be accurate and would automatically take into 
account -D and -I in a robust way.  It could also cause too much 
recompilation, if for example a preprocessor injected some funny 
comments or strings containing the date/time or detailed version numbers 
of components (like the gcc version).

So for now I'm going to continue to take into account -D.

Cheers,
	Simon