Build system idea
Simon Marlow
marlowsd at gmail.com
Tue Aug 12 06:11:38 EDT 2008
Simon PJ and I had a talk about the build system earlier today, I thought
I'd float the idea we discussed (I should admit that the idea was mine,
lest Simon PJ think I'm attributing bad ideas to him :-). This is not
completely thought through, but I'm pretty sure a solution exists along
these lines that would improve things for us.
Ok, the starting point is this:
- Cabal has code to generate Makefiles. Almost nobody uses it except
for the GHC build system. It essentially duplicates the build system
for compiling Haskell source (but not for installation, haddocking,
registration, configuration, etc.)
- Cabal is a library
I propose we do this:
- 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.
This means we still get to use 'make', we still get to use the .cabal files
as metadata, but the build system is more private to GHC, more extensible,
and hopefully more understandable and modifiable. We can express
dependencies that Cabal currently doesn't know about. It would let us
avoid the current uncomfortable situation where we have to feed all kinds
of configuration information from the GHC build system into Cabal - Cabal
would be essentially just a mechanism for translating the .cabal file into
Makefile bindings and package metadata for ghc-pkg.
There will undoubtedly be some sticking points where we have to tradeoff
duplicating things from Cabal against re-using parts of Cabal which might
require modifying Cabal itself. For instance, we could use Cabal for
installation, but that means that our build system has to leave everything
in the places that Cabal's installation code expects, so it might be more
feasible to do installation ourselves, but that means duplicating parts of
Cabal.
It will probably mean that we have a tighter dependency on Cabal, because
we use it as a library rather than a black box; but hopefully we can keep
our branch of Cabal more stable and not have to update it so often.
Anyway, this is an idea that I think is interesting. Obviously it needs a
lot more fleshing out to be a real proposal, but I'm interested in whether
anyone thinks this idea is worth persuing, or whether there are better
alternatives.
Cheers,
Simon
More information about the Glasgow-haskell-users
mailing list