<div dir="ltr">It reuses the .hi files already built for other modules. Those aren't in the source directory but under a build directory. If they don't exist there, it will build the dependencies to create them.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 8, 2019 at 10:57 AM Sam Halliday <<a href="mailto:sam.halliday@gmail.com">sam.halliday@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Brandon Allbery <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>> writes:<br>
<br>
> It's doing what you — but not ghc — consider "extra work", though. ghc<br>
> expects to be compiling code, and doesn't have a separate code path for<br>
> "load symbols from an external module by parsing its source code" instead<br>
> of "load symbols from an external module by loading its .hsc file and<br>
> object code", aside from HscInterpreted.<br>
<br>
<br>
I'm confused: it sounds like you saying that only HscInterpreted can<br>
load symbols of dependencies from object code. Then how does cabal+ghc<br>
do this when I make a change to one file in my project and do a<br>
recompile of the package?<br>
<br>
BTW, I am seeing modules going through CodeGen that are not part of the<br>
file's dependency graph... LoadUpTo is behaving more like LoadAll.<br>
<br>
-- <br>
Best regards,<br>
Sam<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>