Specifying dependencies on Haskell code

[Simon Marlow]

David Roundy wrote:
> On Fri, May 09, 2008 at 01:00:11PM +0100, Simon Marlow wrote:
>> David Roundy 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 
>> 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