GHCi recompilation avoidance UI

[Ben Gamari]

David Feuer <david at well-typed.com> writes:

> I started digging back into this today, particularly considering Simon PJ's view
> that it's a bit odd for optimization flags to imply -fobject-code (specifically
> because we could potentially support optimization for the bytecode
> interpreter some day). I'm left even more lost about exactly what we want.
> I believe it's fairly clear that, as Simon M wrote,
>
>> [W]e'll want at least -fignore-optim-changes to be the default, so that GHCi
>> does the expected thing when you have compiled object files.
>
> Based on Simon PJ's comment, I believe we want to *continue* to discard
> optimization flags when -fobject-code is not enabled. As for my suggestion in (2),
> I spent the last couple hours attempting to figure out what would be necessary
> to allow :load *M to load a module  interpreted even when using -fobject-code,
> but found myself utterly lost in the module loading logic. I see that the IIModule
> constructor is deeply involved in this, but I haven't been able to figure out
> where/how that interacts with -fobject-code to determine whether the module
> will actually be loaded interpreted or compiled. Can someone give me a clue?
>
It seems to me like the place to start would be occurrences of the
targetAllowObjCode field of Target.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171121/e361ff9e/attachment.sig>