On Thu, 2009-05-21 at 21:30 -0500, John Goerzen wrote:
Duncan Coutts wrote:
On Thu, 2009-05-21 at 15:22 -0700, Alexander Dunlap wrote:
Since those types come out of the time library, and that library's version *has* been bumped (I assume), couldn't you use Cabal to condition on the version of the time library to determine whether or not to have CPP set a -DTYPEABLE_IN_TIME flag, and then #ifdef out your versions of the instances?
I was about to suggest this:
#if MIN_VERSION_time(1,1,2) ... #endif
That would be slick. I'll give that a whirl. What version of Cabal does GHC 6.8 come from,
1.2.x
and where can I read about the above feature?
The user guide, section "Creating a package", subsection "Conditional compilation": http://haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#c...
I imagine I may have to wrap the above in a __GLASGOW_HASKELL__ test for GHC 6.8 or something.
Again, there's no direct relationship between the version of ghc and the version of Cabal (though there is some correlation).
Though if *cabal* and not GHC generates it, isn't that a bit hurting to my portability? (Can't just ghc --make with it, or ghci on it directly anymore, etc.)
True. People have been asking for a way to get cabal to invoke ghci with all the right flags, which is a reasonable idea.
because Cabal 1.6+ generates these cpp macros for you. Note that relying on the value of __GLASGOW_HASKELL__ would be wrong because the version of the time library is not directly related to the version of ghc.
Yeah, but when you've got nothing else to go on, it sometimes works in a pinch.
Aye, it's ok for the people you don't upgrade things separately, and those people are less likely to be able to work out how to fix things.
I guess my larger point is just a plea to the community: please be really careful about what you do to GHC in point releases. This is not the first issue that has screwed me in the GHC 6.10.x point releases.
GHC (and the community) used to be really good about this. Is there something causing a regression here, or is it my imagination?
Yes, we're loosening the connection between ghc and the non-core packages, so that package maintainers make releases rather than the ghc maintainers doing so. What we're currently missing is a PVP checker: a tool to compare APIs of package versions and check that it is following the PVP. Ideally, we will have packages opt-in to follow the PVP for those packages that do opt-in we have the PVP enforced on hackage using the checker tool. Since the HP is almost certainly going to require packages to follow the PVP then this should eliminate this class of mistakes. But it does need the tool, and nobody is working on that at the moment. Duncan