On Sat, Apr 3, 2010 at 12:45 PM, Don Stewart
schlepptop:
Don Stewart schrieb:
While at ZuriHac, a few of us GSoC mentors got together to discuss what we think the most important student projects for the summer should be.
Here's the list:
http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gso...
Please consider applying to work on these tasks!
For me a cabal-install that can cope with dependencies reliably would be the most important project. (I get frequently bug reports because data-accessor-template cannot be installed by cabal-install although it can be installed with plain Cabal.)
That's interesting. Why can't it be installed? Does data-accessor-template, or somethiing it depends on, have incorrectly specified version ranges?
I'm no cabal expert, but I've had the same issue with other packages - when it needs to build different with different versions of of template-haskell the easiest thing to do is to have a flag in the package description for different versions of the template-haskell packages. But then cabal-install thinks it can use either version in its install plan, but it really can't as template-haskell is one of the libs that is tied to your GHC install (even after fixing old th for GHC 6.12 and installing it, you cannot use it). So you either default to 6.12 compatible or 6.10 compatible, and then loose the other compiler when your package is included one step deep (or further) in a cabal-install install plan. The solution I lean towards is to use the MIN_VERSION_TEMPLATE_HASKELL cpp macro, what Henning has last tried is setting the package flag off of the GHC version (which works because template-haskell is keyed to your GHC install). In summary - don't specify versions of template-haskell in your package description. Antoine