hsql-1.7 with ghc-6.8

[Duncan Coutts]

In message <1759568487.20070925192337 at gmail.com> Bulat Ziganshin
<Bulat.Ziganshin at gmail.com> writes:
> Hello Duncan,
> 
> Tuesday, September 25, 2007, 4:46:09 PM, you wrote:
> 
> > Don was suggesting we start a wiki page with advice to package maintainers on
> > what updates are common for the transition to ghc-6.8 and cabal-1.2. This is a
> 
> i think that generally requirement to update libraries to meet 6.8
> reqirements isn't a good idea. can we provide full support of old
> packages in 6.8, for example by inclusion both new and old Cabal
> versions in default installation?

That would not help a great deal. One of the main reasons many existing package
will not build with ghc-6.8 is due to the split up of the base library. The new
features in Cabal-1.2 help with this to enable a package to build with both old
and new versions of ghc.

It would be possible to update the Cabal-1.1.6 branch to build with ghc-6.8
(though it could then not build with ghc-6.6 precisely because the older version
of Cabal does not include the new configurations feature which enables such
flexability.) I would also not make anything work automatically since how does
one tell which version of the Cabal library to use? We currently do not have the
information or infrastructure to track this, though I agree that it's something
we should think about carefully for future transitions.

We currently can specify a Cabal version range in a .cabal file that the package
can work with. That's ok for specifying minimum versions but not for maximum
ones since package authors do not know when the Cabal API changes. That needs
proper API versioning. With that inplace it's easy for cabal-setup to do the
right thing, just as it does currently if a .cabal file specifies a Cabal
version range - it compiles the Setup.hs with the right version of the Cabal lib
(if it's installed).

Something we should encourage in this transition which will make things less
disruptive in future is to get people to use "build-type: Simple" in their
.cabal files and not use Setup.hs files at all. The Cabal library api is a good
deal less stable that the .cabal file format and this is the weak point since
currently we require the Setup.hs script to be able to do anything. And when it
does not compile there is no friendly error message like there is when we
deprecate old fields in the .cabal file format.

Duncan