Build system idea
rl at cse.unsw.edu.au
Wed Aug 13 08:47:18 EDT 2008
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
>> 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
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
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.
More information about the Glasgow-haskell-users