[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to package Haskell libraries



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



Reply to: