ghci 7.4.1 no longer loading .o files?

[Evan Laforge]

>> 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.