[Haskell] Re: Trying to install binary-0.4
simonmarhaskell at gmail.com
Tue Oct 16 08:44:44 EDT 2007
Simon Marlow wrote:
> Claus Reinke wrote:
>>>> - if you provide a 'base' configuration that pulls in the stuff that
>>>> used to be in base, the package will work
>>> I don't know of a way to do that. The name of the package is baked
>>> into the object files at compile time, so you can't use the same
>>> compiled module in more than one package.
>> i've been wrong about this before, so check before you believe,-) but
>> here is a hack i arrived at the last time we discussed this:
>> [using time:Data.Time as a small example; ghc-6.6.1]
>> 1. create, build, and install a package QTime, with default Setup.hs
>> 2. create, build, and install a package Time2, with default Setup.hs
>> 3. write and build a client module
> Ok, when I said above "I don't know a way to do that", I really meant
> there's no way to do it by modifying the package database alone, which I
> think is what Udo was after.
> Your scheme does work, and you have discovered how to make a package
> that re-exports modules from other packages (I made a similar discovery
> recently when looking into how to add support to Cabal for this). As
> you can see, it's rather cumbersome, in that you need an extra dummy
> package, and two stub modules for each module to be re-exported.
Ah, I should add that due to technical limitations this scheme can't be
used to make a base-2 that depends on base-3. Base is special in this
respect, GHC only allows a single package called base to be linked into any
given executable. The reason for this is that GHC can be independent of
the version of the base package, and refer to it as just "base"; in theory
it's possible to upgrade the base package independently of GHC.
So we're restricted at the moment to providing only completely independent
base-2 and base-3 in the same installation, and essentially that means
having (at least) two copies of every package, one that depends on base-2
and one that depends on base-3.
Perhaps we should revisit this decision, it would be better for GHC to
depend explicitly on base-3, but allow a separate backwards-compatible
base-2 that depends on base-3 to be installed alongside.
OTOH, this will still lead to difficulties when you try to mix base-2 and
base-3. Suppose that the Exception type changed, so that base-2 needs to
provide its own version of Exception. The base-2:Exception will be
incompatible with the base-3:Exception, and type errors will ensue if the
two are mixed.
If the base-3:Exception only added a constructor, then you could hide it in
base-2 instead of defining a new type. However, if base-3 changed the type
of a constructor, you're stuffed. Ah, I think we've discovered a use for
the renaming feature that was removed in Haskell 1.3!
More information about the cabal-devel