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
somewhere.
OK, fair enough. I'm unlikely to ever need this personally, but it has
utility.
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
missing.)
It is also naturally the easiest way to actually install libraries
since it will register that library with ghc-pkg for you.
Mmm, OK.
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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
