Compiling Plutus dependencies with core bindings

[JoshMeredith]

With extensible interfaces, we can currently compile a package using a plugin to produce interface files that contain core bindings, which can be used to recover ASTs during Plutus compilation.

However, as a design choice of Cabal, we can’t include flags for dependencies as part of the build process. So, we can’t run our plugin to serialise core bindings on the dependencies automatically, and neither can we implement a specialised GHC flag to perform the serialisation - because we can’t get either of those flags into the build of each dependency.

This is unlikely to change with Cabal (haskell/cabal#4853), so we need an alternative solution.

One possible solution is to use a custom compiler that serialises core bindings by default - in which case we can get around the build tool’s limitations. This may involve building up the package-db in a more controlled way, depending on how isolated the build is.

[michaelpj]

That issue is about Cabal flags. You can pass GHC flags through to dependencies. Try

package *
    ghc-options: -Werror

and see everything fail!

So I think implementing a GHC flag should work. The main issue I see is picking a design that's acceptable upstream and not just "our thing".

[angerman]

@michaelpj this only works for packages that can be rebuilt. I think we might need a "way" here. Something similar to the profiling way. What we essentially want is a global configuration that carries the core metadata for every module ghc knows about. Am I misunderstanding something?

[michaelpj]

That's true. I would live if we didn't get access to base and friends, though.

Adding a way sounds like an even more substantial change, though...