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?
claus
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
