ekarttun at cs.helsinki.fi
Wed Oct 25 19:59:00 EDT 2006
On 25.10 09:06, Brian Smith wrote:
> Please point out some cases where splitting a package into multiple packages
> would lead to recursive package dependencies so I can study them.
There are two logging handlers: logger-null and logger-db.
Logger-db depends on a database connection. Database connections
are provided by postgresql and mysql modules which both depend
on a logger being selected.
db-any: postgresql || mysql
> I understand that this would increase the number of packages. But, if it
> would increase the number of packages 10x, then that means that the original
> package could be configured with 10 different subsets of functionality. In
> that case, saying "Build-depends: foo" for that package foo would be almost
> meaningless. You would need to add some kind of more specific dependency
> like "Build-depends: foo (Foo.Bar.A, Foo.Bar.C, Foo.Bar.D)" to indicate what
> modules you need from foo.
16 different subsets are created by e.g. 4 binary choices.
e.g. in network-alt I have one choice with 4 alternatives (the
backend) and the choice whether to use fps. Then there is
debugging. That is 4*2*2 = 16 choices.
And only the FPS one affects API.
> Packages should be created in such a way that the set of things exported
> from the package should not change based on configuration. If some features
> are only valid under one configuration, then they should be factored out
> into a seperate module and then a seperate package. For example,
> GHC-specific features should be factored out into a separate package,
> Windows-specific features should be factored out into a separate package,
> etc. More-or-less, that is how the hierarchical libraries are designed at
> the module level.
Except this is not true even for the base-package. See e.g.
Control.Concurrent. Another problem is that they usually use
internals of the package that one does not which to export.
> If I build package foo with base 1.0, then I am going to be missing some
> features from it. The dependency "foo >= 2.0" doesn't fully describe the
> dependency. We could change it to " foo >= 2.0, base >= 1.1," but I'm not
> sure that means "I depend on foo 2.0 or later being built with base 1.1 or
> later" and furthermore, it means that packages' dependencies are not
And package authors should take care on not doing evil things. There
are very many Haskell packages that do all kinds of magic with CPP
depending e.g. on compiler version.
- Einar Karttunen
More information about the cabal-devel