That could work with GHC if we could create an entity from a subset of the modules, e.g. all the GHC.StgToCmm.* modules.
That sounds interesting! Currently, guardian-as-an-executable does not support adapters other than stack and cabal-install. However, guardian-as-a-library already provides an abstraction over adapters, and the core logic doesn’t depend on the details of adapters.
So there are two possible ways:
- Build a new binary depending on
lib:guardian with custom module-level adapter implementation.
- Enhance guardian-as-an-executable so that it accepts inputs from an external custom adapter (in the spirit of
bios cradle of hie-bios in some sense).
Option (1) might seem relatively hard for those unfamiliar with the guardian internals.
It would be better to go with (2) for extensibility.
If we choose (2), an external adapter must emit the following information (in some suitable format; perhaps graphviz dot?):
- The list of all entities (e.g. packages in the standard settings; modules in the hypothetical case of today’s GHC) in the project without external dependencies, and
- The dependency graph between entities.
Given that, guardian takes care of everything left. As there is no restriction on the name of the entities, one can just use module names instead of packages’.
In the case of modules, one challenge is to collect module dependencies, of course. Package dependencies can be computed without actually compiling the code, but extracting the module dependency graph might need some computation, and perhaps must be done after the compilation. Perhaps we could borrow some ideas from graphmod.
