On 28 July 2005 22:24, Isaac Jones wrote:

"Simon Marlow" writes:

...

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.

ok - I put them in the build-depends field because I wanted to do the cool stuff with optional stanzas and use it with compiler and tool versions too. There's no reason you couldn't do this in a separate field.

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.

We already discover the version of GHC. And it can't be any more tricky than using autoconf :-)

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

I don't think it's a question of re-invention - we really do need a more expressive language for dependencies in Cabal. Otherwise some packages will have dependencies that can't be written precisely in the .cabal file, and we'll end up with ugly hacks to work around it. Or we have to allow the build-depends field to be generated by the Setup script, perhaps via hooks. But that means Visual Studio won't be able to work with a package with a dynamic build-depends field. I think a small extension to build-depends is warranted - and I think the suggestion I put forward has pretty good bang per buck.

OTOH, maybe Haskell can become the generic packaging language, ... [ daydreaming deleted :-) ]

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.

That's fine by me, as long as *enough* of the metadata is concrete so that our tools can manipulate it as necessary. There's always going to be a tension here, but I think we can use the dev environment example as a dipstick to tell us whether we've got enough concreteness.

...

[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?

Ok, this wasn't a great example. Yes, you'd also have to optionally import the right module using conditional compilation of some kind. Try this instead: [ghc62] hs-source-dirs: ghc62-compat [hugs] hs-source-dirs: hugs-compat Cheers, Simon