This is basically about the fact that GHC-as-a-library as a dependency on the Cabal library, which causes all kinds of grief for tools using the GHC API (can't upgrade Cabal).
The ticket has a nice dependency diagram, thanks to lemao.
So I tried to see what could work. This is what I've done so far:
- created a new distribution-base library (the name avoids any reference to Cabal, don't know if it's wise)
- build that library instead of Cabal in stage0 and stage1
- reference that library instead of Cabal in ghc.cabal, pkg-pkg.cabal, Cabal.Cabal
- add the dependency when building ghc-cabal and ghc-tags, both need the full Cabal anyway.
The distribution-base library contains the following modules:
- Distribution.Compat.ParseUtils: the bits of Cabal's Distribution.ParseUtils we need
- Distribution.Compat.ReadP: Cabal's ReadP
- Distribution.InstalledPackageInfo: Cabal's Distribution.InstalledPackageInfo
- Distribution.License: Cabal's Distribution.License
- Distribution.ModuleName: Cabal's Distribution.ModuleName
- Distribution.Package: Cabal's Distribution.Package minus the Dependency type and related functions (unused in GHC)
- Distribution.PackageIndex: the bits of Cabal's Distribution.Simple.PackageIndex we need
- Distribution.Text: Cabal's Distribution.Text
- Distribution.Utils: the bits of Cabal's Distribution.Simple.Utils we need
Note that Distribution.Version is not needed by GHC, even though it used to import it, it only used the datatype from base, and the Data instance I've moved to Distribution.Package.
I've created a new Cabal module called Distribution.Dependency since the Dependency type is not needed, in the Cabal source code it's mainly imports that need to change.
All seems to build on my machine. It doesn't really help the build itself since Cabal is still needed for ghc-cabal, but at least the GHC API does not require the Cabal library any more.
What do you think? Is it a step in the right direction?
Thanks
JP
--
JP Moresmau
http://jpmoresmau.blogspot.com/