mad.one at gmail.com
Sun Sep 21 04:03:31 EDT 2008
Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008:
> 1. How is putting something into a Cabal package different from just
> handing somebody the source code and telling them to run ghc --make?
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
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.
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 since you will always get the
most up-to-date code - plus mixing and matching native package
managers and e.g. cabal install doesn't really work well IME; for
example if you want to install alex from macports, it will
automatically install ghc too, even if you actually have it installed,
but you didn't install it through macports (I just used the .dmg file
that Manual Chak. made.) Likewise you may want to get something and it
might depend on the HTTP library - it could very well already be
installed via cabal-install, but the native manager won't dig into GHC
to find out and will instead just work based on what it knows is
installed in its package database.
More information about the Haskell-Cafe