<div dir="ltr"><div>Hmm. The issue of build parallelism is kind-of orthogonal to .hs-boot files/circular imports.</div><div><br></div><div>The impact of .hs-boot files on build parallelism depends on their announced imports; at least in my semantic model of them (which might be incorrect) they just break cycles.</div><div>The degree of parallelism is visible as a property of this DAG where cycles are broken through insertion of .hs-boot nodes.<br></div><div><br></div><div>The issue here is one of transitive dependencies, which is a property on the original cyclic dependency graph.</div><div><br></div><div>So while we have the dependency graph</div><div><br></div><div>HsExpr <--> TcRnTypes <--> PmOracle</div><div><br></div><div>This is of no issue for build parallelism, because the .hs-boot files remove "feedback vertices" from the graph, rendering it acyclic:</div><div><br></div><div>TcRnTypes.hs-boot <- HsExpr <- TcRnTypes <- PmOracle</div><div>PmOracle.hs-boot <- TcRnTypes</div><div><br></div><div>Yet a package including HsExpr must also include PmOracle to compile.</div><div><br></div><div>The parallelism issue is best tackled by hadrian based profiles, on which we could compute try to come up with the optimal schedule and compare it across multiple CI runs.</div><div>But the dependency issue here is rather specific to the set of modules that should be included in ghc-lib-parser, I'm afraid, and I don't see how to solve it in a general way other than pre-computing the set of transitive dependencies for specific blessed modules. Which might be a thing we want... One set for each major entry point to the compiler pipeline, for example.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 17. Sept. 2019 um 10:19 Uhr schrieb Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is precisely the problem I was worried about in April.<br>
<br>
<a href="https://mail.haskell.org/pipermail/ghc-devs/2019-April/017493.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-devs/2019-April/017493.html</a><br>
<br>
Any fix should ensure adding a test to make sure it doesn't happen again.<br>
<br>
Cheers,<br>
<br>
Matt<br>
<br>
On Mon, Sep 16, 2019 at 10:38 PM Shayne Fletcher via ghc-devs<br>
<<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br>
><br>
> Hi Sebastian,<br>
><br>
> On Mon, Sep 16, 2019 at 5:23 PM Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" target="_blank">sgraf1337@gmail.com</a>> wrote:<br>
>><br>
>> Hi Shayne,<br>
>><br>
>> Sorry to hear that! We didn't consider modularity at all and I would be happy to try to refactor in a way that would allow `ghc-lib-parser` to be properly separated again.<br>
>> I'm fairly certain that I didn't directly touch anything parser related, but apparently the new cyclic import of PmOracle within TcRnTypes (which is also exposed from `ghc-lib-parser`) pulled in the other half of GHC.<br>
>> I'll see if I can fix that tomorrow, if only by extracting a separate `Types`-style module.<br>
>><br>
><br>
> That sounds awesome. Tremendous. Thank-you! Please feel free to reach out to me if there's anything I can do to help your analysis[*]!<br>
><br>
> [*] For the record, the procedure for calculating the `ghc-lib-parser` modules is a little complicated by there needing to be some generated equivalents of `.hsc` files present for this to work but the procedure is at the end of the day just `ghc -M` invoked over `Parser.hs`.<br>
><br>
>><br>
>> Cheers,<br>
>> Sebastian<br>
><br>
><br>
> Fingers crossed and all the best!<br>
><br>
> --<br>
> Shayne Fletcher<br>
> Language Engineer / +1 917 699 7663<br>
> Digital Asset, creators of DAML<br>
><br>
> This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at <a href="http://www.digitalasset.com/emaildisclaimer.html" rel="noreferrer" target="_blank">http://www.digitalasset.com/emaildisclaimer.html</a>. If you are not the intended recipient, please delete this message._______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>