Don Stewart wrote:
kili:
On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: [...]
As for Cabal - we had a thread on cvs-ghc last week, and as I said there we'd love to hear suggestions for how to improve things, including wild and crazy ideas for throwing it all away and starting again. However, as I explained, there are good reasons for the way things are done now, the main one being that the build system for packages is not written twice.
Well, at least the Makefile creation was a step (the first step?) into the wrong direction, IMHO. I'll run a GHC build to get some of those generated Makefiles and followup on cvs-ghc, but for a starter, Cabal shouldn't know anything about implementation-specific internal build systems; instead it should rely only on it's own metadata. Implementation-specific stuff (such as how to run the compiler) should be supplied by the implementation, not by Cabal. if we're going to kick on cabal I might throw in my two cents.
I see an increasing problem in that every community comes up with their own package system, instead of reusing existing frameworks. dependencies to other non-haskell libraries has to be addressed for every other coexisting package system (such as apt-get), if it is addressed at all. likewise, other languages depending on haskell will have trouble resolving dependencies. so my point is, if there will be any bigger reworking of cabal, I think one should consider how it could work as a module in a bigger (maybe future) meta-packaging framework, lifting up binaries to for example .deb, .exe-installer, .dmg or whatever is the most native for the platform. I see a point in language specific package systems as they have more insight into the build process, but the current implementations assume a very ideal world in which there are no other dependencies involved. /Johan