Build system idea
rl at cse.unsw.edu.au
Wed Aug 13 04:51:30 EDT 2008
On 13/08/2008, at 17:47, Simon Marlow wrote:
> Roman Leshchinskiy wrote:
>> On 12/08/2008, at 20:11, Simon Marlow wrote:
>>> - Extract the code from Cabal that generates Makefiles, and treat
>>> it as
>>> part of the GHC build system. Rather than generating a Makefile
>>> complete with build rules, we generate a Makefile that just
>>> has the package-specific metadata (list of modules, etc.), and put
>>> the code to actually build the package in the GHC build system.
>> Sounds good. It would be nice if the .cabal parser from Cabal could
>> be made into a separate, stable library which ghc (and nhc?) could
>> This makes me wonder, though. Wouldn't this model make more sense
>> for Cabal in general than the current approach of duplicating the
>> functionality of autoconf, make and other stuff? If it works ghc,
>> it ought to work for other projects, too. Cabal as a preprocessor
>> seems much more attractive to me than as a universal build system.
> So packages would be required to provide their own build system?
> That sounds like it would make it a lot harder for people to just
> create a package that others can use. The ease of making a Cabal
> package has I think a lot to do with the wealth of software
> available on Hackage.
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?
> It was a design decision early on with Cabal that we didn't want to
> rely on the target system having a Unix-like build environment. You
> might disagree with this, but it certainly has some value: a Windows
> user can download GHC and immediately start building and installing
> external packages without having to install Cygwin.
I agree with this decision but IIUC, this only really works for simple
(wrt building) packages which don't even use configure. Making Cabal
into a modular preprocessor and providing a thin wrapper for ghc --
make which can act as a target for Cabal would achieve this just as
More information about the Cvs-ghc