On Tue, 2006-02-21 at 20:13 +0200, Einar Karttunen wrote:
On 21.02 16:50, Simon Marlow wrote:
I lost the argument for include files, but this is why libraries cannot currently be specified inside source files. Back in the FFI discussion, we didn't have Cabal, but now that we do, Cabal is the natural place to specify these things.
Cabal is a good place, but does not handle very well optional dependencies that most programs linking against the library don't need.
I think there are some improvements planned to Cabal in the area of optional dependencies.
I don't understand this - surely if you just put those two modules in separate packages, then everything works? Or is it that you don't want to do that?
Think about a database library supporting e.g. mysql, postgresql, sqlite and odbc. Now it needs six packages to do this: 1) foo-common for common code that does not import any of the implementations 2) foo-mysql (depends on 1) 3) foo-pgsql (depends on 1) 4) foo-sqlit (depends on 1) 5) foo-odbc (depends on 1) 6) foo (this has a connect function which uses any of the above, thus depends on 1, 2, 3, 4, 5)
I don't consider this very good design and in practise this is quite tedious for the library writer.
However this is exactly the package structure that we want for distro packages. We really do want all those foo-mysql packages. Think about what the debian package would be like if there were only one. You'd have one package that depended on all of those different database systems. Now in practise they would not do this because it's not an acceptable solution. They would be forced to split the package up into several bits, on for each db system. So it's much better if it's done this way from the start. Oh except will really complain about item 6) above. People really really will not like installing postgres and mysql just to use a binding for sqlite. hsql and hdbc have all these backends but there is no package that depends on all the backends so you can install just the ones you need. Duncan