Package global build-depends should apply constraints to all components

[ezyang]

A common complaint is that there is no capacity for shared Cabal fields between components, c.f. #1949 and #2832. build-depends in particular is a common complaint, since a common Cabal idiom is to rebuild the same source files as part of multiple components.

I think there is at least a partial solution to this problem: top-level build-depends should be brought back, with the following semantics:

1. If I write p >= 3 in the top-level build depends, IF we would have solved for a version of p, then we apply the constraint that its version is >=3
2. Top-level build depends do not affect visibility of packages in components; so you still have to write build-depends: p inside any component that wants to use p.

In effect, we can centralize version bounds in one part of the Cabal file, while having fine granularity for specifying what components need what dependencies (so that the library doesn't need to depend on the package test suite). Of course the old syntax is still supported, so components can add their own bounds (toggled if the component is enabled.)

What do people think about this?

[mgsloan]

Why not make the inclusion of a package in a component be implicit? This is how hpack works, and it works very well indeed. Why try to reduce the number of deps for non-library components? AFAIK the only downside of more deps is potential module name ambiguity.

[ezyang]

I guess that's OK. Then this is a special case of #2832 (instead of putting a build-depends in all, just put it at the top-level).

(The reason why I didn't propose this originally was that I thought that if you have multiple test suite stanzas, you might want to specify a common bound for e.g. HUnit on all the test suites, without bringing in the dependency on the library which shouldn't depend on HUnit. But I guess this is a very weak reasoning.)

[mgsloan]

Yup, I think it's best to err on the side of concision, particularly if a bit of boilerplate can be used for those less common cases.

[23Skidoo]

Yes, I think it would be better to just implement #2832. I like the common stanza proposal a bit more than a top-level build-depends since it's more explicit and general. Another idea that we maybe can steal from hpack is populating other-modules automagically from hs-source-dirs.

[ezyang]

OK, closing.