[Haskell-cafe] Cabal (was: Compilers)

[Matthias Kilian]

On Sat, Nov 29, 2008 at 11:31:52AM -0800, Don Stewart wrote:
> > I don't see any advantage in Cabal, except that a .cabal file
> > provides some metadata and dependency information that can help the
> > build.
> 
> And we have tools to automate the packaging of cabal-specified code.
> So for example, there are already native packages of LHC, but not of
> JHC.
> 
>     http://aur.archlinux.org/packages.php?ID=21749
> 
> Because of the automatic packaging for cabal-specified software.

Oh, maybe I'll write similar tools for OpenBSD ports some day (when
I've enough time). Yet I consider this (useful) configuration and
dependency information metadata.  IMHO, Cabal is nice for specifying
this metadata, it maybe nice wrt hackage, some people even may like
to just cabal-install something and go ahead, but this are already
too much tasks it's trying to fulfill, leaving alone Cabal as a
*build* tool.

I'm probably biased, because I had so much trouble with ghc and the
Cabal/make maze, so I may be a little bit unfair (because ghc's
requirements are more complicated than just an ordinary program or
library). However, I really believe in the unix philosophy (one
tool for one task), and Cabal clearly doesn't follow it.

There's an example for a tool capable of dependency and (to a certain
degree) configuration management in the java world: ivy
(http://ant.apache.org/ivy/). Well, they added a lot of bload since
they moved to apache, and of course one could question why everything
has to be XML, but the basic idea was: deal with dependencies, add
support for repositories containing dependencies in several versions,
but nothing more. No build tool, no packaging or install tool. Yes,
it's tightly coupled with apache-ant, but if you have an ivy-file,
there's nothing stopping you from converting the information contained
in this file to some includable makefile snippet.

I didn't have a very close look at the ghc-new-build-system yet,
but I think the idea here is basically the same: use the .cabal
files (and the Cabal library) to generate files that then are used
by make(1) to do the real work.

I hope that I make at least a little bit sense. The problem I've
with Cabal is that it tries to be the swiss army knife of dependency
and configuration management, building, packaging and installation,
but like those swiss army knifes on steroids (with too much features),
it doesn't fit in you pocket any longer.

Ciao,
	Kili