Adding System.FilePath

Jeffrey Yasskin jyasskin at
Sat Mar 17 22:32:21 EDT 2007

On 3/16/07, Bulat Ziganshin <bulat.ziganshin at> wrote:
> Hello ArtemGr,
> Friday, March 16, 2007, 1:52:24 PM, you wrote:
> >> yes, it is possible but have no any practical meaning because base
> >> library anyway shipped together with ghc and there are no alternative
> >> versions. if someone will make such versions, these versions may be
> >> installed in ghc (may be by hand because Cabal itself uses base :)
> > Base is shipped with GHC, so what? I can fetch the fresh base with darcs and
> > build it.
> base isn't compatible between major ghc versions (6.6/6.8). so you may
> use only base 2.0 with 6.6 or base 3.0 with 6.8.

This seems wrong to me (though I'm quite new at this, so there could
be something obvious I'm missing). I understand that ghc-6.6 expects
certain types and functions to be defined at particular places within
base, but most names aren't like that. One could declare that base-2.x
defines all the magic names in the places ghc-6.6 expects them, but
other names can be moved around between 2.x and 2.(x+1). Then ghc-6.8
would expect the names where base-3.x places them, and so on.

I just got Cabal to build ghc's base, and the only significant
problems I ran into were and an apparent
expectation that GHC/Prim.hs is found in exactly base-2.0, rather than
just base-*. The following patch seems to work:

[Convince Cabal to build the base library
Jeffrey Yasskin <jyasskin at>**20070318013640

 Neither runghc nor ghc can build Setup.hs with files like Prelude.hs and
 System/IO.hs present, but if you build it outside of this tree, you can run it
 here (after running `make boot` to generate GHC/Prim.hs) and things will work.
] {
hunk ./Makefile 71
+EXCLUDED_SRCS = GHC/Prim.hs Setup.hs
addfile ./Setup.hs
hunk ./Setup.hs 1
+-- #!/usr/bin/runhaskell
+import Distribution.Simple
+main = defaultMain
hunk ./base.cabal 2
-version:       2.1
+version:       2.0
hunk ./base.cabal 143
+ghc-options:    -fglasgow-exts -funbox-strict-fields

So, to solve the immediate problem you're complaining about, it might
be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into
something like ghc-prim for ghc-6.8 rather than to prevent new modules
from being added to the top. Then base can be refactored at a more
leisurely pace.

> situation is
> different for other libraries - you can keep to use fps 0.7 with any
> ghc version because your program developed against it, or you can
> upgrade to new version if you need new features

Jeffrey Yasskin

More information about the Libraries mailing list