Planned improvements to component handling in Cabal/cabal-install

[ezyang]

Cabal and cabal-install operate on a per-package basis, rather than a per-component basis; this is the source of many bugs:

• [nix-local-build] Recompiling packages with many components is still pretty slow #3049 nix-local-build always rebuilds all components of a package
• Specify components when configuring, not building #2802 Configuring a package requires dependency information for all components, even ones we don't intend on building
• Disable library building, only build other components #2775 You can't rebuild an executable without also rebuilding, e.g., the same-package library it depends on
• cabal configure making dependencies global #2725/Make Cabal accept --dependency flags qualified by components #3286 If you have multiple components in the same package which have mutually exclusive dependencies, there's no way to tell Cabal about this
• -j should build package components in parallel #2623 No parallelism while building components; you parallelize over packages but components are built serially

I had a previous proposal for a per-component setup interface at #3064 but after discussion, we are going to go for a more conservative plan:

• We'll partially fix Disable library building, only build other components #2775, proceeding a bit differently than suggested in the ticket. Presently, if you say cabal build myexe, this will build myexe as well as any components it depends on (e.g., the library). If you pass the --one-shot flag, we will assume that all of its dependencies are up-to-date and only build the immediate component. However, it will assume, e.g., the library it needs, has been built and registered in place; it would not be possible to request the executable to be built against an already installed version of the package. (I suppose if you fix Make Cabal accept --dependency flags qualified by components #3286 that will solve that problem, because you'll just configure the dependency to point elsewhere.)
• We'll add a --one-shot mode to ./Setup copy. If you don't specify a component it will instead install package-global information.
• We'll add a --one-shot mode to ./Setup register.
• Decouple InstallPlan from PackageIndex; i.e., have cabal-install have a copy of the code so that InstallPlan isn't implemented internally using a PackageIndex but with its own data type PlanIndex. See Refactor of PackageIndex and InstallPlan  #3525.
• Generalize InstallPlan to not be keyed on UnitId, but on a new data type that reflects various build items we may need to do, specifically (1) download a package, (2) configure a package, (3) build a component in a package (this step takes advantage of --one-shot). At the same time, rewrite the install plan runner to handle these steps individually.

[ezyang]

This ticket got obsoleted by #3662

[dcoutts]

Generalize InstallPlan to not be keyed on UnitId, but on a new data type that reflects various build items we may need to do, specifically (1) download a package, (2) configure a package, (3) build a component in a package (this step takes advantage of --one-shot). At the same time, rewrite the install plan runner to handle these steps individually.

Also, I don't think this last item is actually needed. The existing approach to the build runner can avoid re-configuring and can download in parallel.

[ezyang]

Well, it would be needed if took the approach described in this ticket (which we ended up not doing. Per-component builds as currently implement have to reconfigure for each component; not really possible to avoid without reimplementing configure in cabal-install.