Build system idea

[Duncan Coutts]

On Wed, 2008-08-13 at 11:34 +0100, Simon Marlow wrote:

> Cabal has two parts: some generic infrastructure, and a "simple" build 
> system (under Distribution.Simple) that suffices for most packages.  We 
> distribute them together only because it's convenient; you don't have to 
> use the simple build system if you don't want to.

The two parts also have different degrees of stability. In particular
there are lots of tools that rely on the declarative parts, the types
and parsers so we try not to break those so often. Roman asks for a
"separate, stable library which ghc (and nhc?) could use" but since this
part of Cabal is fairly stable I don't think it needs to be separate. I
don't think it'd be more stable by being in a different package. The
reasons to change it are usually to add new fields, and that usually
does not affect clients that do not need to know about the new fields.

> I think perhaps you're objecting to the fact that the "simple" build system 
> isn't so simple, and we keep adding more functionality to it.  This is 
> true, but the alternative - forcing some packages to provide their own 
> build system - seems worse to me.

As Isaac used to say, it's not the Simple build system because it's
simple. It's because it does complex things to simple packages.

The Make build type was supposed to let people wrap existing make-based
build systems. Unfortunately it's not used much so is not well developed
and for ghc is really the wrong way round. I think your approach of
exporting the info in make syntax makes more sense for ghc, since it's
not trying to pretend it's a cabal package anyway (which is what the
Make build type was for, wrapping things up so people building packages
didn't need to know what was used underneath).

Duncan