You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The second number is the set of modules GHC knows that may need building, and the first is the placement of the current module in the linearized module graph.
If this plugin could report how many modules are built in a given run, and how many modules are to be built total, then we'd be able to know how many modules were skipped. This would be useful information for understanding how incremental builds or caching is working, as well as how entangled the module graph is (ie "changing these imports resulted in a X difference in how many modules are rebuilt").
The text was updated successfully, but these errors were encountered:
... but the ModuleGraph is not populated at driver initialization, so we'll want to record that at the start of the Hsc phase. We probably want to ensure that we only add the attribute once, otherwise it'll be expensive. Potentially, we can start with an MVar () that is full, and each thread can tryTakeMVar. The first one to get a Just () can do addAttribute to the parent span.
OK, here's I think another issue. The parent span from the environment is a FrozenSpan, so we can't attach to that. We'll need to attach to a different span, one that is created live, or we need a way to signal to an external process that we want to add an attribute to a span.
To keep track of how many modules are compiled, we'll need to have an IORef that is incremented with every Hsc phase. Part of plugin cleanup should read that IORef and attach an attribute.
A common build log will include this prefix text:
The second number is the set of modules GHC knows that may need building, and the first is the placement of the current module in the linearized module graph.
If this plugin could report how many modules are built in a given run, and how many modules are to be built total, then we'd be able to know how many modules were skipped. This would be useful information for understanding how incremental builds or caching is working, as well as how entangled the module graph is (ie "changing these imports resulted in a X difference in how many modules are rebuilt").
The text was updated successfully, but these errors were encountered: