Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

cabal-install 0.14: generated Paths_*.hs assumes extensible exceptions #994

Closed
geekosaur opened this Issue · 11 comments

5 participants

@geekosaur

This was just reported in #xmonad: a user on Gentoo with the default Haskell mask (hence getting GHC 6.12.2) was unable to build xmonad because the Cabal-generated Paths_xmonad.hs was generated with what appears to be an assumption of extensible exceptions (or, maybe it's going back too far, given the "Exception." qualifier, and using some ancient H98 exception code?).

[ 8 of 10] Compiling Paths_xmonad     ( dist/build/autogen/Paths_xmonad.hs, dist/build/xmonad/xmonad-tmp/Paths_xmonad.o )

dist/build/autogen/Paths_xmonad.hs:11:10:
    Couldn't match expected type `Exception.IOException'
           against inferred type `Exception.Exception'
      Expected type: Exception.IOException -> IO a
      Inferred type: Exception.Exception -> IO a
    In the expression: Exception.catch
    In the definition of `catchIO': catchIO = Exception.catch
@bmillwood

GHC 6.12.2 does have extensible exceptions, by the way: just make sure you're compiling with base >= 4 instead of base 3.

The difficulty here is I guess we want the Paths_ module to be compiled on all the compilers that Cabal supports using, not just the ones Cabal supports being built with. I'm not sure what that list is, but it rules out importing any utilities from the Cabal library.

@bmillwood

Easy workaround: use System.Environment.getEnvironment and Data.List.lookup instead of getEnv.

@tibbe
Owner

I suggest threading carefully when changing the generated paths module. We've already had one bad cabal release due to changes to this module. Note that the contents of this module differs depending on a number of parameters (e.g. platform).

@ttuegel
Collaborator

Does this issue affect GHC >= 7.2?

@ttuegel ttuegel added this to the Cabal-1.24 milestone
@23Skidoo
Collaborator

I tried to reproduce this with GHC 6.12.1 and the module actually compiled. I guess it was picking base-3 for some reason.

@23Skidoo
Collaborator

Heh, yes:

~/bin/ghc-6.12.1/bin/ghc -package base-3.0.3.2 -c Paths_Cabal.hs

Paths_Cabal.hs:13:10:
    Couldn't match expected type `Exception.IOException'
           against inferred type `Exception.Exception'
      Expected type: Exception.IOException -> IO a
      Inferred type: Exception.Exception -> IO a
    In the expression: Exception.catch
    In the definition of `catchIO': catchIO = Exception.catch
@23Skidoo 23Skidoo referenced this issue from a commit in 23Skidoo/cabal
@23Skidoo 23Skidoo Paths_ module: don't require base >= 4.
Fixes #994.
41b3c7b
@23Skidoo
Collaborator

So it looks like we can use CPP in the Paths_ file. The fix is therefore simple: #2552.

@ttuegel It doesn't, but it'd be nice if cabal-installs compiled with new GHC would continue to work with older GHCs.

@ttuegel
Collaborator

@23Skidoo I agree, I would like us to maintain compatibility with older GHC versions. Because of concerns about breaking the Paths_ module, do we want to consider (instead of using CPP), writing just different modules depending on the GHC version?

@23Skidoo
Collaborator

@ttuegel Well, the problem is that 6.12 comes with both base-3 and base-4, so we're forced to use CPP if we want to continue supporting it.

@23Skidoo
Collaborator

Re: breaking the Paths_ file - I believe that my change is safe. It even supports the case when cabal_macros.h is not #included for some reason:

#if defined(VERSION_base)

#if MIN_VERSION_base(4,0,0)
catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a
#else
catchIO :: IO a -> (Exception.Exception -> IO a) -> IO a
#endif

#else
catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a
#endif
@ttuegel
Collaborator

I think that's fine, then!

@23Skidoo 23Skidoo closed this in #2552
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.