| 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. Simon 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.