something seemed to have changed in cabal (compiling hsql-1.7 with ghc version 6.8.0.20070921) HSQL/MySQL$ runhaskell Setup.lhs configure -p -O Setup.lhs:8:33: Module `Distribution.Simple.Utils' does not export `rawSystemVerbose' (same: http://hackage.haskell.org/packages/archive/hsql-mysql/1.7/log ) is there a workaround? -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
In message <46F7AA98.9020402@imn.htwk-leipzig.de> Johannes Waldmann
something seemed to have changed in cabal (compiling hsql-1.7 with ghc version 6.8.0.20070921)
HSQL/MySQL$ runhaskell Setup.lhs configure -p -O
Setup.lhs:8:33: Module `Distribution.Simple.Utils' does not export `rawSystemVerbose'
(same: http://hackage.haskell.org/packages/archive/hsql-mysql/1.7/log )
is there a workaround?
The api that the Setup.lhs is using has changed, it's not just rawSystemVerbose. The return types are now IO () not IO ExitCode and verbosity is now a proper Verbosity type, not an Int. The Setup.lhs can be considerably simplified by using configurations and other new features. So basically it needs updating for the newer cabal. It may also need to be updated for the fact that many modules from the base package have been split off. I've attached an example updated Setup.lhs and hsql-mysql.cabal files. 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 certainly a good idea. By trying a range of packages it should also tell us if there are any minor cabal changes that we could do to make the transition smoother (eg adding back rawSystemVerbose with a deprecation warning). Duncan
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? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, 2007-09-25 at 19:23 +0400, Bulat Ziganshin wrote:
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?
FWIW, Cabal is independent of GHC, they are just distributed together. As such, updating packages adds a dependency on Cabal 1.2, not on GHC. Cabal intentionally uses only Haskell98 features in order to be as portable as possible. Having build environments require the latest version of the build tool is rather common, too. This is not necessarily good in any case[*], but we try to make it as little hassle as possible. / Thomas [*] .. I'd personally like to avoid these problems as well, but many seem to consider them as transitional, and I agree that, ATM, hackage is small enough to fix problems in a decent amount of time.
In message <1759568487.20070925192337@gmail.com> Bulat Ziganshin
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
Duncan Coutts wrote:
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.
sounds great - how does it work? (what to do instead of "runhaskell Setup.hs configure" then?) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
In message <46FA3EFF.3020106@imn.htwk-leipzig.de> Johannes Waldmann
Duncan Coutts wrote:
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.
sounds great - how does it work? (what to do instead of "runhaskell Setup.hs configure" then?)
cabal-setup configure cabal-setup build cabal-setup install etc. The command line interface is exactly the same. cabal-setup is a wrapper program that manages compiling the Setup.hs script if necessary or if the package is using the 'Simple' build type (and the version of Cabal required by the package is compatible with the one cabal-setup was built with) then it calls into the Cabal lib directly. This is a bit quicker and is useful for simplicity and security. For example the VisualStudio plugin has never supported running Setup.hs scripts so it has effectively only ever used the 'Simple' build type. Many people are nervous about the security implications of running Setup scripts since they can perform arbitrary IO actions. Calling the Cabal lib directly is a little better. You can grab cabal-setup now from: http://darcs.haskell.org/cabal-setup/ and I hope it will also be included in the 'extralibs' tarball that will be released at the same time as ghc-6.8.1. Duncan
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
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
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 :) 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)... btw, the same applies to other libs bundled with ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
In message <794435043.20070926214104@gmail.com> Bulat Ziganshin
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
participants (4)
-
Bulat Ziganshin -
Duncan Coutts -
Johannes Waldmann -
Thomas Schilling