Workflow with many separate library / executable / test-suite stanzas is slow

[simonmar]

Describe the bug We have a project with a .cabal file that contains 40+ library stanzas, a dozen or so executables and 50+ test-suite stanzas. Working with this project is painful, because every change to the .cabal file causes all the libraries to be re-configured on the next cabal build.

Instead I would hope that changes only cause re-configuring of any affected libraries or executables or tests.

To Reproduce

Build instructions here https://glean.software/docs/building/

But you probably don't need to reproduce it using Glean, it should be easy to construct a simpler repro.

Expected behavior Changes to the .cabal file, e.g. adding a new module or a new item to a build-depends, don't cause so much re-configuring.

System information Linux Fedora 35

[gbaz]

I talked about this with Simon a tad at ICFP and think this would be good to work on. If Meta engineering has anyone willing to slice off a little time to look at this I would much prefer to help provide thought and direction than take it up myself of course. But as we do have increased use of multi-stanza cabal files at scale, this sort of request seems eminently reasonable, and a good way to help us think about improving our caching story more generally.