hsql-1.7 with ghc-6.8

[Duncan Coutts]

In message <794435043.20070926214104 at gmail.com> Bulat Ziganshin
<Bulat.Ziganshin at gmail.com> writes:
> Hello Duncan,
> 
> Wednesday, September 26, 2007, 3:04:18 PM, you wrote:
> 
> >> 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.
> 
> this problem also needs to be solved. there was proposals to make
> virtual base 1.0.x package which reexports everything that ghc 6.6 base
> provided

I don't think this will help with the current versions of Cabal, either 1.1.6 or
1.2. We currently look for the highest version of a library satisfying the
version requirement. So for a package that specifies just 'base' with no version
requirement Cabal will pick base-2.whatever rather than your virtual base 1.x.

> > flexability.) I would also not make anything work automatically since how does
> > one tell which version of the Cabal library to use?
> 
> if i package my lib with Cabal x.y.z, i mention this fact in the
> .cabal file. on installation cabal/ghc infrastructure should examine it and find
> the best cabal version which is appropriate for installing my lib

We already have this. You can put in your .cabal file:
cabal-version: >=1.1.6
and indeed many do that. cabal-setup has the same behavior, that it'll pick the
highest version of Cabal that satisfies the version restriction. So that does
not help since the author could not predict the future and know that their
package's Setup.hs file will actually not work with cabal-1.2. 

> > 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.
> 
> they use Setup.hs only when simple builds are impossible so you can't
> propose anything except that to implement more features in Cabal :)

Most of the non-trivial Setup.hs that I've seen can be replaced with making use
of some of the new features in Cabal-1.2.

> i think that right solution is to develop Cabal in backward-cmpatible
> way between major version changes and ship with ghc all the major
> Cabal versions, f.e. 2.1.9 (last 2.x), 3.0.11 (last 3.x)...

Shipping several versions is possible but keeping the internal cabal api
backwards compatible is essentially impossible without stopping development. The
problem is it's never been specified what is an internal api or what is
available for Setup.hs scripts to use. Also it was not clear in the earlier
development stages what the right api to expose to scripts should be. So it's
been continually improved over time and many Setup.hs scripts make use of
internal Cabal functions since the normal exposed api was insufficient.

This is clearly the weak point in the system, so my advice is avoid Setup.hs
scripts as much as possible.

Duncan