Personal tools

Upgrading packages/Updating to GHC 6.10

From HaskellWiki

< Upgrading packages(Difference between revisions)
Jump to: navigation, search
m (Correct usage of the -package flag)
Line 27: Line 27:
 
Force use of package base-3 when using --make,
 
Force use of package base-3 when using --make,
   
ghc --make --package base-3.0.3.0
+
ghc --make -package base-3.0.3.0
   
 
===runhaskell ===
 
===runhaskell ===

Revision as of 18:00, 11 October 2008

A list of things that need updating when porting packages to newer library/cabal versions.

If you maintain a Haskell package this is for you. For older versions of this document:

Updating to GHC 6.10 and Cabal 1.6

When upgrading to GHC 6.10, any of your packages that worked against the base-3 library will continue to work. GHC 6.10 provides both the old base-3 library and the new base-4.

To ensure your old code continues to work, you can have the code compile and link against base-3, and then, over time, migrate code to the base-4 series.

Contents

1 Adding base-3 constraints

How to do this depends on how you build your Haskell code. We'll start with the most simplistic build mechanisms. cabal-install, the most sophisticated tool, will sort this all out for you anyway, so things should change.

1.1 ghc --make

Force use of package base-3 when using --make,

   ghc --make -package base-3.0.3.0

1.2 runhaskell

If you build your packages with the 'runhaskell Setup.hs configure' method, then you can force the use of base-3,

   --constraint="base<4"

1.3 cabal-install

It is worth upgrading cabal-install immediately (maybe before installing GHC). This way you can use the smart dependency solver to work out what to install for you.

* install HTTP from hackage
* install zlib from hackage

Then build cabal-install.

You can also override the dependencies when using the 'cabal' binary, with

   --constraint="base<4"

2 Typical breakages with GHC 6.10

54 new packages break with the current GHC 6.10 release candidate.

The primary reasons are:

  • Changes to Arrow class definition
  • Changes to Map monadic types
  • Cabal changes
  • Changes to ghc-api
  • Changes to when 'forall' is parsed
  • GHC.Prim was moved,
  • Changes to -fvia-C and headers?
  • GADT changes,
  • pragma warnings tightened
  • Integer constructors have moved
  • New warnings and used -Werror
  • Exception handling: catch, finally, throwIO don't work anymore

Each of these has a standard way to solve the problem. Techniques should be attached here.

2.1 Changes to Arrow class definition

The relevant change is essentially that Arrow became a superclass of Category. To be exact:

  • (>>>) was removed from Arrow, instead we have (.) in Category
  • id is a new function, in Category

What this means for code is that you need to declare an instance of Category as well as Arrow. A brute-force fix which should work:

  • Add the following imports:
   import Control.Category
   import Prelude hiding (id,(.)) -- conflicts with Category otherwise
  • Add instance Category [your type] where for any Arrows
  • Move your (>>>) definition into Category, and change f >>> g = ... into g . f = ...
  • Define id in Category. (Actually, I'm not 100% sure if this is strictly necessary for code that used to work in 6.8, but it's safest.)

And you're done.

2.2 Exception handling changes

The exception system was generalised in GHC 6.10, but GHC 6.10 still provides base-3, so all your applications can continue to work.

Follow the steps for compiling against base-3 at the top of the page, baesd on your build system.

Note that if you use cabal-install, it is smart enough to work this out for you.

3 Backwards compatibility

The new, suggested Cabal version range syntax,

  build-depends: base-3.*

is not backwards compatible with older versions of Cabal. Users will need to upgrade to the newer Cabal to build packages that start using this syntax.