Build system idea

[Duncan Coutts]

On Thu, 2008-08-28 at 10:27 +0100, Simon Peyton-Jones wrote:
> | So Cabal takes the view that the relationship between features and
> | dependencies should be declarative.
> ...
> | The other principle is that the packager, the environment is in control
> | over what things the package 'sees'.
> ...
> | that we can and that the approach is basically sound. The fact that we
> | can automatically generate distro packages for hundreds of packages is
> | not insignificant. This is just not possible with the autoconf approach.
> ...
> | Do you think that separating the Simple build system from the
> | declarative part of Cabal would help? It'd make it more obvious that the
> | build system part really is replaceable which currently is not so
> | obvious since they're in the same package. I'm not averse to splitting
> | them if it'd help. They're already completely partitioned internally.
> 
> 
> Duncan, I'm not following every detail here, but it's clear that you
> have some clear mental infrastructure in your head that informs and
> underpins the way Cabal is.   Cabal "takes the view that...", has
> "principles", and "is clearly partitioned internally".
> 
> These things are clear to you, but my sense it that they are *not*
> clear even to other well-informed people.  (I exclude myself from this
> group.)  It's like the Loch Ness monster: the bits above the waves
> make sense only when you get an underwater picture that shows you the
> monster underneath that explains why the humps surface in the way they
> do.
> 
> This isn't a criticism: one of the hardest thing to do is to
> accurately convey this underwater stuff.  But I wonder whether there
> might be a useful paper hiding here?  Something that establishes
> terminology, writes down principles, explains the Cabal viewpoint,
> contrasts with alternatives, and thereby allows discussion about Cabal
> to be better informed.

Yes. Of course there is Isaac's existing Cabal paper from '05 but there
are also some more recent ideas.
http://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/24num.pdf

I think the way forward is after the upcoming GHC+Cabal release to take
a step back and think about a design document for Cabal-2.x. It should
incorporate the things we think were right from the original Cabal
design document, things we've learnt along the way and try as much as
possible to incorporate the criticisms that people have been making in
recent months.

The goal should be a design with a somewhat greater ambition than the
original Cabal design which was mostly aimed at relatively simple,
single package projects (a goal which has mostly been achieved).

This would also be the right place to explain the configuration model
properly, so that the people who are familiar with the autoconf model
don't think we're just crazy. Not that they have to agree with us, but
at least we should explain the tradeoffs and limitations in either
direction. That should also help to clarify what is a limitation in the
model vs what is a limitation in the current implementation of the model
in current Cabal.

The most obvious and immediate problem (apart perhaps from handling
complex multi-package systems) is in specifying dependencies on Haskell
code. I did start a discussion on this topic on the libraries mailing
list in April/May. We didn't reach any really firm conclusions but it's
clear that specifying just module names or just package versions is only
an inexact proxy for what we really mean. Modules can be renamed,
modules can move between packages, neither capture names or types of
exported/imported entities let alone semantics. Various ideas were
floated like precisely specifying or inferring interfaces, in a style
somewhat like ML functors.

> PS: concerning your last point, about "separating the Simple build
> system", that might indeed be good.  Indeed, the GHC plan described
> here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is (I
> think) precisely using the declarative part but not the build-system
> part.

I don't think it affects that really. GHC would still come with both
parts if it were split into two packages and the exported modules and
apis would not be changed by splitting. If splitting allowed one part to
be separated out and not need to be a boot lib then it'd be a different
matter but I don't think that's the case (which I think Ian confirmed in
his reply). Splitting might help nhc98 and external perceptions. A
possible downside is that it might make bootstrapping Cabal harder.

Duncan