On Mon, Jun 23, 2003 at 10:38:40AM +0200, Marcelo E. Magallon wrote: > On Sun, Jun 22, 2003 at 09:07:05PM -0400, Colin Walters wrote: > > > Right, but that approach definitely has some disadvantages, namely > > fragility and the fact that we're kind of subverting the whole idea of > > binary packages. > > It kind of depends on what "Haskell library" means. Is it more like a C > library (potentially complex build system, dependencies, etc) or is it > more like a Perl module?
I think the problem is that it could vary, and probably there needs to be at least support for binary haskell libraries. Certainly any library that is pure haskell probably will have a pretty simple build system. But a lot of interesting haskell "libraries" would involve bindings to other libraries, so installing them on the users' machine would require dev versions of those libraries, which would be annoying to an end user... on the other hand, as far as I know haskell doesn't support dynamic linking, which would mean that the library packages would themselves be -dev packages, and dependency (as opposed to just build-dependency) on -dev packages would be normal. On consideration, I think I'd vote for the "build binaries at install time" approach. The only problem with it is that it may take an awful lot of time to do so. But as long as haskell developers (or people compiling a haskell package from source) are the only ones to suffer from this wait, it seems like a good tradeoff. If we require a separate package for each compiler, I imagine many library packagers would opt for just packaging their library for ghc, which would be a shame as far as portability goes. -- David Roundy http://www.abridgegame.org
