First of all, my position on this has always been (since we argued about this during the design of the FFI) that include files and libraries should be kept out of the source file and specified separately, since they are a part of the build infrastructure, and vary across platforms. 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. On 21 February 2006 14:13, Einar Karttunen wrote:
But it is not possible to have e.g. Foo.Bar.MySQL (depends on -lmysql) Foo.Bar.PgSQL (depends on -lpq)
and with suitable optional compiler support create an executable that depends only on those libraries that it actually uses. This is not possible if library dependencies are per-package. Of course compilers can still default to actually handling dependencies on a per package level if they want without breaking anything.
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? Cheers, Simon
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 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. - Einar Karttunen
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
On Tue, Feb 21, 2006 at 04:50:20PM -0000, Simon Marlow wrote:
First of all, my position on this has always been (since we argued about this during the design of the FFI) that include files and libraries should be kept out of the source file and specified separately, since they are a part of the build infrastructure, and vary across platforms.
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.
the problem is that package granularity is way to big for specifying dependencies, jhc wants all dependencies attached to each FFI import. the reason being that it collects only the dependencies for things that are actually used so for instance the following works: foreign import ccall "fcntl.h open" c_unix_open ... foreign import ccall "win32.h OpenFile" c_win_open ... foreign import lvm "lvmOpen" c_lvm_open ... openFile = case os of "unix" -> ... c_unix_open ... "lvm" -> .... c_lvm_open ... "win32" ->.. c_win_open ... and all the intermediate code remains platform independent. now, I concur that this always isn't possible, but when it is I feel it is the right way to do things. at least in jhcs model. requiring a correlation between packages and C libraries would be overly restrictive (but so would disallowing such a thing) libraries are a little odd to keep in the source file, I am still thinking about that, perhaps just a token will be propegated that the build system can expand into the appropriate libs. in any case, I want to assosiate dependencies with individual foreign calls. it makes writing portable programs a whole lot simpler and obviates a lot of the need for a preproccesor and generating different libraries for different targets. not that this is incompatable with package-wide dependencies, a package-wide dependency would just be equivalent to adding the dependency to every foreign call within that package. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (4)
-
Duncan Coutts -
Einar Karttunen -
John Meacham -
Simon Marlow