Re: Re[6]: Adding System.FilePath

17 Mar 2007

      On 3/16/07, Bulat Ziganshin  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
http://hackage.haskell.org/trac/ghc/ticket/1206 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 **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
+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
-- 
Namasté,
Jeffrey Yasskin