Build system idea

[Duncan Coutts]

On Wed, 2008-08-27 at 03:04 -0700, John Meacham wrote:
> On Wed, Aug 13, 2008 at 01:31:55PM +1000, Roman Leshchinskiy wrote:
> > 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.
> 
> I can't tell you how much I agree with this. the fact that cabal wants
> to be my build system as well as my configuration system means it is
> pretty much unusable to me in my projects.
> 
> Features are something that _hurts_ a system such as this. between a
> build system, a configuration manager, a packaging system, etc, it is
> rare for any large project that at least one isn't imposed on you by
> some external constrant or just a better choice for the job. I would
> much rather see cabals functionality split among a variety of different
> programs so the pieces can be used when appropriate, not as an all or
> nothing thing. (bring back hmake! :) ).

People are of course still free to use autoconf and make to implement
their own build system and have it still be a Cabal package (which has
the advantage of presenting the same meta-data and command interface to
packaging tools). It's been that way since the original design. Quite a
few packages to use autoconf though the use seems to be slightly on the
decline as people try and make their packages portable to Windows. Very
few packages use make as it involves re-implementing their own build
system which is a lot of work. That's partly a self-fulfilling prophecy
of course because nobody uses that interface so it does not get improved
so nobody uses it etc. Also, as far as I'm aware hmake still works, at
least for nhc, I've not used it recently for building with ghc. So
there's nothing stopping people from using that (except hard work), even
as part of a cabal package.

The different parts of the system are relatively separated. The
declarative bits that deal with package meta-data (.cabal files) are
available through the Cabal library (Distribution.*) and many tools make
use of this. Then the 'Simple' build system is in the same library but
fairly cleanly separated (Distribution.Simple.*). As I mentioned, you
do not have to use the 'Simple' build system, but the vast majority of
packages do. Then there are the packaging tools like the tools for
converting to native packages and cabal-install which use the Cabal
library and the command line interface that Cabal packages present.

I'm not saying it's perfect, but it's not as monolithic as some would
suggest.

Duncan