ghci 7.4.1 no longer loading .o files?

[Simon Marlow]

On 21/02/2012 04:57, Evan Laforge wrote:
> 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?

I agree - I'll omit all these flags from the recompilation check in 7.4.2.

Cheers,
	Simon