On Thu, Oct 9, 2008 at 8:55 PM, Duncan Coutts wrote:

* ForSyDe-3.0

Uses the copyDest field from CopyFlags. These record types now use an equivalent of Maybe so they can be empty rather than always containing a default value. It's useful, but also kind of annoying in places. It's an easy fix.

If possible at all, what would be the best way to make it compatible with both versions of CopyFlags? Thanks

On Thu, 2008-10-09 at 11:55 -0700, Duncan Coutts wrote:

All,

I'm trying to do a Cabal-1.6 release, in time for ghc-6.10.

Here's an interim update.

There are 7 packages on hackage where the latest version has a Setup.hs script that works with Cabal-1.4 but does not compile with Cabal-1.6.

Actually it's 8. For some reason I missed lhs2tex. Cabal-1.4 had several compat hacks added to enable lhs2tex to be made to work. Those hacks are gone in Cabal-1.6.

That's actually not too bad. It's been a lot worse in the past, and we have many more packages now.

Further details. I tried to build 685 packages from hackage with ghc-6.8 using Cabal-1.4.0.2 and Cabal-1.6.0.0. Here are the numbers: * Cabal-1.4.0.2: 547 built ok * Cabal-1.6.0.0: 541 built ok So there are (at least) 6 packages that worked with Cabal-1.4.0.2 and now fail with Cabal-1.6. I say "at least" because some failed for me with Cabal-1.4 but only because I'm missing C libs. I don't have an accurate count of that subset. But I don't think it's that large. If we assume it's about 12 newly failing packages then that's under 2%. If I remember correctly we had 8-10% breakage due to Cabal from the 1.1.6 to 1.2 transition with ghc-6.6 to 6.8. So it's rather better this time. This set of course overlaps with the 8 for which the Setup.hs fails to compile. The reason it's not simply an addition to the earlier 7 is because some of those failed to configure with Cabal-1.4 even though the Setup.hs compiled. In a couple cases that was due to C libs. So here's a breakdown of the 6 that are new failures and a couple that definitely fail with Cabal-1.6 and probably would have worked with Cabal-1.4 if I'd had the C libs installed. Failed due to Setup.hs not compiling: * ForSyDe-3.0 * MissingPy-0.10.0 * Takusen-0.8.3 * alex-2.2 * happy-1.17 * lhs2tex-1.13 These two also have Setup.hs scripts that no longer compile * hsql-odbc-1.7 * HDBC-postgresql-1.1.4.0 hsql-odbc never built anyway because hsql does not compile with ghc-6.8. HDBC-postgresql probably would have built for me with Cabal-1.4 if I'd had the postegresql C libs installed. So it's part of the "at least" category which failed with 1.4 only because I didn't have the C libs. Other failures: * HsPerl5 HsPerl5 fails with: Reading parameters from ./HsPerl5.buildinfo setup: HsPerl5.buildinfo:4: Parse of field 'ld-options' failed. The problem here is parsing "-Wl,-E". It is a Cabal parsing bug. It worked in old versions of Cabal but only because they incorrectly interpreted "," as a separator. By luck this worked. Apparently passing -Wl -E to gcc rather than -Wl,-E was not enough to cause visible breakage. The current cabal parser for ld-options only looks for spaces as separators but currently does not allow ',' inside tokens. I'll fix this before the release. Duncan

Duncan Coutts wrote:

* alex-2.2 * happy-1.17

Imports buildVerbose from Distribution.Simple.Setup ( BuildFlags(..) ) however the flag has been renamed to buildVerbosity and with a different type. I would export a compat function but it would not help here since the Setup script expects it to be a record selector from BuildFlags. Cabal-1.4 contained a dodgy hack to make this continue to work, but I'm not doing that again.

If I added a compat function then we could at least make it work with both ghc/cabal versions with a single implementation. So I might do that and do point releases of these packages, if Simon thinks that's ok.

Really of course both packages should stop calling an external perl and other similar madness.

I can stop calling Perl, but I still need to run CPP, so I still need the runProgram stuff, which means I still need buildVerbose/buildVerbosity. As far as I can see, you could export a compatibility shim called buildVerbose without any difficulty, all I have to do is remove the explicit import list. Or is there a better fix you had in mind? Cheers, Simon