Begin using component-based builds

[snoyberg]

Originally discussed in #834, we shelved work on this until Cabal added support. Cabal added support for component based builds long enough ago that we can drop support for older versions and fully embrace a component based system (see #4475). Not only will this help address some bugs, but will also open the door for Backpack support (see #2540).

@qrilka is planning on taking a look at this to estimate how long an implementation will take. This is currently planned for Stack 2.0, but may be deferred if it turns out this is more complex than it seems.

Additional issues which may be affected by this (incomplete list):

• Builds are kind of not using Hyper Threading #4391
• "Conflicting family instance declaration" error with same type/definition #4705
• Stack fails to build "mutually recursive" packages #2583
• Don't record VersionRange for dependencies #3723

[snoyberg]

I've given this a bit more thought, and given the number of changes already planned for Stack 2.0, and the goal of releasing relatively soon, I'd rather hold off on this until Stack 2.2. I'm going to leave this in the P1 milestone for the Stack 2.2 release.

[Ericson2314]

What's the progress on this? 2.2 is the next non-patch release right? Correct me if I'm wrong, but the linked issues all are reverse dependencies on this. Are there other issues/PRs that are working towards this?

[snoyberg]

I believe there is currently no progress on this, unless someone is working on it that I'm not aware of. This would definitely be a great addition to get in, and I'd be happy to provide feedback/mentoring if someone is interested in tackling it.

[Ericson2314]

@snoyberg Thanks for the update! I came here from (surprise) the backpack issue (#2540), as this depends on this. Obsidian is potentially interested in working on this. I'll need to make estimates and roadmap.

[theobat]

So as @qrilka stated he won't be able to work on this, and this is needed for backpack support (and likely needed for additional cabal3 features such as public sublibraries). I started to look at the code a bit, I feel like this change is very pervasive in the code base such as changing all mentions of Package in Build to Component ? Is there type creation involved or is every notion of cabal component already in there (with a few additions to NamedComponent ?)

Also I'm not sure to what extent this is impacting the build plan ? Or is it only impacting the Task level ?

Maybe a more precise description of what you mean by "component-based builds" would help @snoyberg ?

tl;dr I'm interested in doing this, but I wouldn't mind a little help to assemble a "todo" list.

[theobat]

So, as far as I understand, the main structural change is to switch

-- extracted from Stack.Build.ConstructPlan
Task { taskProvides = PackageIdentifier
                    (packageName package)
                    (packageVersion package)
-- ... other stuff

Into something with an additional NamedComponent instead (and pass it from the cabal file representation, which, I havn't figured out yet).

This is however, (still, as far as I understand), not enough for a real component-based build; we should build all the transitive dependencies of a component with an appropriate NamedComponent specifier (e.g build lib or internal-lib xyz only if it's something with more than one option). SO quite a bit of change in the addPackageDeps function of Stack.Build.ConstructPlan.