andrewcoppin at btinternet.com
Sun Sep 21 09:52:51 EDT 2008
Austin Seipp wrote:
> Cabal can handle things for you like when your package depends on
> external data files; when cabal compiles the code it autogenerates a
> module which you import that will give you the path name to where-ever
> it is installed, which is nifty in case you for example are uploading
> a language for an interpreter and want to store the languages' prelude
OK, fair enough. I'm unlikely to ever need this personally, but it has
> It also allows for more tight constraints on dependent package versions
> i.e. with it you can specify the exact package and version you need to
> build (for example, parsec < 2.1 && > 3.0 which a few packages do.)
> With --make you would have to include a lot of -hide-package flags and
> a lot of other things, too.
So you're saying that using Cabal allows you to check that all your
build dependencies are already installed?
(Certainly just building something with GHC means that if some package
isn't installed, you're going to have a hard time figuring out what's
> It is also naturally the easiest way to actually install libraries
> since it will register that library with ghc-pkg for you.
>> 2. If we already have a Cabal package, why do we also need seperate
>> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
> Having these packages available as native packages for a package
> manager lets you distribute applications easier for example; if
> someone just wants to install <appname> from say, the archlinux user
> repository (which is source-based, mind you - the official repo is
> binary based,) it may also depend on parsec, haskell98, HTTP,
> etc.. Having these packages available natively to the manager means it
> can track the dependencies and install the application by itself -
> this is useful for example if someone just wants to use a haskell
> application but they don't code haskell (example: darcs or pandoc.)
> Of course, if you are doing haskell development, the best possible way
> to go (IMO) full-blown cabal install.
Having native packages for stand-alone applications such as Darcs makes
sense to me - after all, you don't need to install GCC just to use (say)
KEdit, so why would you need to install GHC and build Darcs from source
just to use it? However, managing individual Haskell libraries via the
local package management system seems slightly redundant to me.
More information about the Haskell-Cafe