"Simon Marlow"
So here's a strawman proposal to address some of the use cases raised recently[1] that Cabal doesn't currently support well. This is just a first attempt; I expect we'll need to make changes or start over if we discover cases that it doesn't handle.
(snip proposal) Lots of this is stuff I've been wanting to ad at some point. I think that rather than overloading the build-depends field, we should add a new field for tool dependencies; otherwise, we could get name conflicts between the two and such. I'm not positive that the simple build infrastructure would be able to take all of the information in the tool-dependendencies into account; for instance, discovering the version of happy and ghc might be a bit tricky and error prone. (snip)
---------------- name: mylib version: 1.0 exposed-modules: My.Lib build-depends: base>=1.0 (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs-any [hugs])
Debian has something like this, where you can specify optional dependencies. I've always planned to implement something like this for Cabal. At the same time, I think we need to be careful not to re-invent make and re-invent dpkg / rpm via feature-creep. I understand Duncan's desire to have absolutely everything automated for gentoo without the gentoo packager having to intervene, but that's just what the OS packagers have been dealing with for every language. I want Haskell to be easier than other languages (historically, it's been harder) but if we make the package syntax more and more complex, I think we run the risk of expending a lot of energy for a small amount of benefit by creating a whole new language for packages. OTOH, maybe Haskell can become the generic packaging language, and people can start to use it to package everything... if anyone can create that, the Haskell community can ;) I'd really rather see the expansion of Cabal features going in a different direction: the Distribution library. Wouldn't it be great to have an embedded domain-specific language for packaging / building inside Haskell? Then the setup script could be like the sane man's makefile. As Hudak (I think) points out in a paper on embedded domain-specific languages, many languages grow from DSLs (like the .cabal file) into general-purpose languages. The reason I like the setup script is so that we don't have to keep expanding the .cabal file; we have all the power of Haskell at our fingertips in the Setup file. For Debian packages in most languages, we have a hunk of executable stuff for building and installing, and a relatively small amount of metadata to deal with dependencies and what-have-you. I think we should try to stick to that model wherever possible, of course, improving upon Debian where we can. I'm not saying that Simon's ideas can or should be implemented in the Setup script; but that's just something to think about when we're talking about expanding the .cabal file syntax.
[ghc62] other-modules: Compat.Ghc62
[hugs] other-modules: Compat.Hugs
Here we're starting to get complicated, though, and I'm a bit scared of this complication. Presumably, then you have something in the source code to optionally #include the correct module? This is perhaps one of the few places where I'd rather see Haskell itself altered to address this need than to patch it with Cabal. Anyway, these are all good ideas, this is just my first reaction and I'll keep thinking, and we should keep discussing this. More later. peace, isaac