It's doing what you — but not ghc — consider "extra work", though. ghc expects to be compiling code, and doesn't have a separate code path for "load symbols from an external module by parsing its source code" instead of "load symbols from an external module by loading its .hsc file and object code", aside from HscInterpreted.
On Tue, Oct 8, 2019 at 10:37 AM Sam Halliday <sam.halli...@gmail.com> wrote: > Thanks Brandon, > > Brandon Allbery <allber...@gmail.com> writes: > > Cabal will build all that stuff the first time and then reuse it the > next, > > so it's not quite the same thing. Since you told ghc no object code, > > Sorry, I meant that I used targetAllowObjCode=True for everything, > except the file under inspection. Do you mean that if I used > targetAllowObjCode=False for just one module it will invalidate the > object code for everything it depends on? That is unexpected. > > > > In short, you may want to rethink this; ghc is a compiler, not an IDE, > and > > doesn't quite work the way you had hoped. > > How would you suggest rethinking it? Bare in mind that the api is > working exactly the way I want from a functional point of view (just > slow) with HscNothing... and seems to work exactly the way I want with > HscInterpreted (but with all the ghci caveats like unboxed tuples etc). > > -- > Best regards, > Sam > -- brandon s allbery kf8nh allber...@gmail.com
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
