David Roundy wrote:
On Fri, May 09, 2008 at 01:00:11PM +0100, Simon Marlow wrote:
Maybe the problem is that noone seems to know what problem cabal is supposed to be solving. What problem is that? Some say it's a configuration/build system. Others say it's a packaging system. I think it's the latter. Does it matter? It's fine for a system to not fit entirely into one of the
David Roundy wrote: predefined boxes that you know about (e.g. is ZFS a file system or a volume manager?). Cabal solves a specific problem, which is:
it allows a package to be built from source, and installed, on a system with only a Haskell compiler (and Cabal).
the last part is important for people on Windows who don't want to install Cygwin or MSYS just to build Haskell packages.
Now, we discovered that by adding bits here and there we could solve other problems too: e.g. Cabal also builds programs. But the above statement was originally the main reason for Cabal's existence.
I guess my problem is that some of the advocates of cabal don't seem to understand this, and seem to think that it's some sort of a general-purpose build system. The trouble is that it isn't an autoconf-replacement or a make-replacement, but folks keep comparing it with those programs and arguing that it should replace them. Indeed, it can replace them for simple packages, as you note, but it doesn't compete in terms of either generality or flexibility.
The problem we found before Cabal was that people would appear and ask how to build a Haskell package, and they generally didn't know enough make or autoconf to do it alone. Even if they did, it's still a daunting task. Cabal just automates all this nicely. Before Cabal I could count on one hand the number of third-party Haskell packages available, and they all had their own hand-written build systems, which were often flaky. Now we have hundreds of packages that just work. We designed Cabal so that you could use it with autoconf as your configuration tool, and many packages do this. But you can't use autoconf to configure Haskell dependencies, because we want to know dependencies up front for things like cabal-install. So Cabal was never designed to replace autoconf or make, except for the particular case of building Haskell packages and programs. Generally the approach has been that if we can get rid of the need for autoconf by adding a tiny bit to Cabal, then that's a trade worth making, but I don't think anyone's saying we should re-implement autoconf in Cabal. However, re-implementing make in Cabal isn't nearly such a bad idea :-) Cheers, Simon