Description
Quoting from Distribution.Client.ProjectPlanning.elaborateInstallPlan.elaborateSolverToComponents:
At this point in time, only non-Custom setup scripts are supported.
Implementing per-component builds with Custom would require us to create a newElabSetuptype, and teach all of the code paths how to handle it.
And from Distribution.Client.ProjectPlanning.setupHsScriptOptions:
TODO: Fix this so custom is a separate component. Custom can ALWAYS be a separate component!!!
So... what's at stake here? The problem is that packages with a custom setup (which currently includes Custom and Hooks build types) go through the "whole package" codepath in cabal-install, in that elaborateSolverToComponents returns a whole package instead of a collection of individual components. This is because cabal-install only has a half-baked notion of Setup as a separate component (e.g. we have compComponentName :: Maybe ComponentName, where Nothing <=> setup).
This means that packages which use those build types are locked out of certain newer features, such as multiple libraries.
Instead, we should make the setup a separate component, which other components in the package depend on. It would probably also be worth tackling #3984 while in this area, as otherwise we would get incorrect recompilation checking if the setup consists of more than one module.
I believe the core of an implementation would be to figure out how to populate the fields of ElaboratedComponent in Distribution.Client.ProjectPlanning.elaborateInstallPlan (see the notImpl function). Then remove the cuz_buildtype legacy fallback reason and try to build some packages with Hooks build-type (see the SetupHooks overlay for a repository of such packages).