Claus Reinke wrote:
btw, it would still be nice to have ghci limitations (vs ghc) summarized on a wiki page. i've seen fragments here and there, but no complete list answering my questions.
:set -fobject-code :reload
ah, thanks! i had forgotten about that one. it doesn't solve my main problem but i guess what i'm asking for could be rephrased as: an _implied_ {-# OPTIONS_GHC -fobject-code #-} for only those modules which ghci can't handle itself.
:load M.hs N.hs
i also liked the suggestion that ':m *M' should always use the source, from the same thread.
take darcs stable as a medium sized example that already has a 'make ghci' target. by default, that target loads object code built by 'make' and it falls over at various places if one adds '-fforce-recomp' to the ghci call. using a general '-fobject-code' doesn't help, and having to figure out which modules cause ghci headaches is no fun, either.
what i'm looking for is a way to let ghci pretend as far as possible that it has no limitations (compared with ghc), so that i can simply load a project's main module, have no failures because of ffi, etc. while still having as many of the dependencies as possible loaded in source form.
is there a way to do that that works with the darcs stable repo example?
Not right now. But I think the right way would be to allow `-fobject-code` to be used in an OPTIONS_GHC pragma to indicate that the module *must* be loaded as object code. That way GHC can take it into account during the planning stage before starting to compile anything, because it might force other modules to be compiled to .o too. http://hackage.haskell.org/trac/ghc/ticket/1365 Cheers, Simon