Build system idea

[John Meacham]

The problem with the way cabal wants to mix with make/autoconf is that
it is the wrong way round. make is very good at managing pre-processors,
dependency tracking and calling external programs in the right order, in
parallel, and as needed. cabal is generally good at building a single
library or executable given relatively straightforward haskell source.
(I know it _can_ do more, but this is mainly what it is good at).

The way this should work is that make determines what haskell libraries
need to be built, and what haskell files need to be generated to allow
cabal to run and calls cabal to build just the ones needed. cabal as a
build tool that make calls is much more flexible and in tune with each
tools capabilities.

The other issue is with cabal files themselves which are somewhat
conflicted in purpose. on one hand, you have declarative stuff about a
package. name, version, etc... information you want before you start to
build something. but then you have build-depends, which is something
that you cannot know until after your configuration manager (whatever it
may be, autoconf being a popular one) is run. What packages you depend
on are going to depend on things like what compiler you have installed,
your configuration options, which packages are installed, what operating
system you are running on, which kernel version you are running, which c
libraries you have installed. etc. things that cannot be predicted
before the configuration is actually run.

Then you have cabal as a packaging system (or perhaps hackage/cabal
considered together). Which has its own warts, if it is meant to live in
the niche of package managers such as rpm or deb, where are the
'release' version numbers that rpms and debs have for one example? If it is
meant to be a tarball like format, where is the distinction between
'distribution' and 'source' tarballs? For instance, jhc from darcs for
developers requires perl,ghc,DrIFT,pandoc,autotools, and happy.  however the jhc
tarball requires _only_ ghc. nothing else. This is because the make dist
target is more interesting than just taring up the source. (and
posthooks/prehooks don't really help. they are sort of equivalent to
saying 'write your own build system'.)

One of the biggest sources of conflict arise from using cabal as a
configuration manager. A configuration managers entire purpose is to
examine the system and figure out how to adapt your programs build to
the system. this is completely 100% at odds with the idea of users
having to 'upgrade' cabal. Figuring out how to adapt your build to
whatever cabal is installed or failing gracefully if you can't is
exactly the job of the configuration manager. something like autoconf.
This is why _users_ need not install autoconf, just developers. since
autoconf generates a portable script is so that users are never told to
upgrade their autoconf. if a developer wants to use new features, he
gets the new autoconf and reruns 'autoreconf'. The user is never
asked to update anything that isn't actually needed for the project
itself. This distinction is key fora configuration manager and really
conflicts with cabal wanting to also be a build system and package
manager. It is also what is needed for forwards and backwards
compatibility.

All in all, I think these conflicting goals of cabal make it hard to use
in projects and have led to very odd design choices. I think external
tools should not be the exception but rather the rule. Not that cabal
shouldn't come with a full set of said tools. But as long as they are
integrated I don't see cabal's design problems being fixed, meerly
augmented with various work-arounds.

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈