Build system idea

[Roman Leshchinskiy]

On 13/08/2008, at 20:34, Simon Marlow wrote:

> Roman Leshchinskiy wrote:
>
>> Of course there should be a standard build system for simple  
>> packages. It could be part of Cabal or a separate tool (for which  
>> Cabal could, again, act as a preprocessor).
>>> GHC is a special case: we already need a build system for other  
>>> reasons.
>> I agree. I just don't think that adding a full-fledged build system  
>> to Cabal is the solution. In my experience, huge monolithic tools  
>> which try to do everything never work well. I much prefer small,  
>> modular tools. A Haskell-based build system is an interesting  
>> project but why does it have to be a part of Cabal?
>
> Hmm, but you said above "there should be a standard build system for  
> simple packages.  It could be part of Cabal...".

On second thought, it shouldn't be part of Cabal :-)

> 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.

My impression of Cabal is that it is a build system with a bit of  
generic infrastructure. In particular, a large part of the .cabal  
syntax is specified in terms of this build system and some of it only  
really makes sense for this build system.

> 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.


Cabal packages do provide their own build system; it's just that they  
use Cabal syntax instead of, say, make. The advantage of doing this  
is, of course, that Cabal's syntax is simpler. Adding things to the  
"simple" build system erodes this advantage. Complex projects will  
still have complex build systems - the complexity will be in  
the .cabal files. If Cabal's goal is to be able to build any project  
it will basically have to duplicate the functionality of autoconf,  
automake, libtool, make and a couple of other tools *and* be just as  
flexible. I think this is neither realistic nor necessary. So where do  
we stop? And what about the packages that Cabal won't support when we  
stop?

IMO, we should have stopped some time ago. A .cabal file should  
describe a package, not how to build it. Building should be handled by  
different tools with a clear interface between them and Cabal. If the  
build system of choice needs additional information, then that  
information should be provided in a separate file and not in the  
package description.

Again, I'm not arguing against a build system written in Haskell. I'd  
just like it to be completely separated from Haskell's packaging  
system. In particular, "polluting" a package description with build  
information seems wrong to me.

Roman