Refactoring package to component centered design

[theobat]

This is a first step towards a component based architecture in stack and a package representation closer to the cabal one.
The idea is, following this : #6065, we had too many scattered representations of component centric data. This is a good stab in regrouping everything in a very cabal-close design.

The main refactoring this MR propose is to have collections of cabal-like components, such as for instance :

data StackLibrary = StackLibrary
  { name :: StackUnqualCompName,
    buildInfo :: !StackBuildInfo,
    -- | This is only used for gathering the files related to this component.
    exposedModules :: [ModuleName]
  }
  deriving (Show, Typeable)

Which is a mirror of Cabal's Library, with only the things Stack needs.

This MR already brings a lot of change, but keep in mind that :

• I'm still working on implementing all the consequences of this new design, primarily around refactoring the dependencies to simply iterate on each component's dependencies. So I believe this MR is good enough to be merged, but it's paving the way of even better changes (refactorings really).
• It's a pure refactoring nothing is changed functionally

[mpilgrem]

@theobat, the integration tests are failing because (I think) you have edited the stack.cabal file 'by hand'. The autogenerated stack.cabal has the same other-modules: modules, but listed in a different order. If you stack build, you will get the stack.cabal file that is expected, and that is the one that needs to be committed.

Stan is complaining because the ignored OBS-STAN-0203-fki0nd-1111:21 how has a different location (OBS-STAN-0203-fki0nd-1118:21). The .stan.toml file needs to be updated.

[theobat]

All good, thanks @mpilgrem

[mpilgrem]

@theobat, I likely will not work through all of this tonight. However, I have pushed to your branch my progress so far. I am applying consistent formatting as I go (that is what almmost all of my further changes are about); as we discussed elsewhere - I don't ask that you waste your own time thinking about that.

[mpilgrem]

Still working through it, also reformatting for consistency as I go (another batch of commits). Some of this has picked up some unrelated formatting.

[mpilgrem]

@theobat, all looks good to me, but I did ponder about the naming of a small number of things. See my specific comments. What do you think?

[mpilgrem]

@theobat, with the exception of a little reformatting and my renaming a small number of identifiers, I have merged what you proposed. However, I have a question you may be able to help with: the following expressions evaluate to the same value. Can one be rationally be preferred over the other?

Set.toList $ buildableSubLibs package

getBuildableListText $ packageSubLibraries package

[theobat]

Thanks ! @mpilgrem
While both are equal now in terms of computation and meaning, I'd rather use the latter, as it allows for direct folds over the underlying CompCollection structure. In fact, this collection may or may not continue as the combination of a set and a hashmap of buildable components. In particular, it'd be better globally for stack to bend towards the usage of HashSets because benchmarks show they are more performant, and in this case we'd remove the asNameSetin CompCollection as it'd be strictly redundant over a simple HashMap.

[mbj]

Sorry for deleting my earlier comment, I thought my bisect went wrong but it did not. So the commit: a5ff987 is (according to my bisect) the first commit showing the symtoms of this issue: #6365