ghci 7.4.1 no longer loading .o files?

[Evan Laforge]

On Mon, Feb 20, 2012 at 8:33 PM, Evan Laforge <qdunkan at gmail.com> wrote:
> On Mon, Feb 20, 2012 at 1:14 AM, Eugene Crosser <crosser at average.org> wrote:
>> On 02/20/2012 10:46 AM, Evan Laforge wrote:
>>> Is there something that changed in 7.4.1 that would cause it to decide
>>> to interpret .hs files instead of loading their .o files?  E.g.:
>>
>> I don't *know* but could this have anything to do with this?
>>
>> http://hackage.haskell.org/trac/ghc/ticket/5878
>
> 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?