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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe