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. Thus build-depends: logger-null: logger-db: db-any db-any: postgresql || mysql postgresql: logger-db mysql: logger-db > 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 > self-contained. 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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
