On 3/16/07, Bulat Ziganshin <bulat.ziganshin@gmail.com> 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 <jyasskin@gmail.com>**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