>However, haddock would still have to support ghc-paths for standalone
>builds. Also, I think that in a GHC tree we'd still have to pointlessly
>link against ghc-paths, as I can't see a simple way to avoid it.
Can't this be a conditional dependency?
If you have
Flag ghcPaths
if flag(ghcPaths)
Build-Depends: ghc-paths
then there's no reason for that flag ever to be turned on. I'm not sure
what cabal-install does, but if you try and build it manually with Cabal
and don't have ghc-paths installed then Cabal will happily build it for
you without ghc-paths.
Cabal configurations allow you to set the default value for flags,
so you could have it True by default, and set it to False if you
want to use another hack (you'd also need to set some
flag-dependent CPP, or the build will fail to find Ghc.Paths).
But isn't that the wrong way round? ghc-paths was meant to get
rid of tool-specific hacks as far as possible, by abstracting out
common trickery, sharing it between tools. So instead of bypassing
ghc-paths, shouldn't it be extended to cover missing cases?
In the future, having ghc-paths as a shared library is going to
allow updating clients by updating ghc-paths (or so I'm told;-).
If shared libs are going to be delayed, one could temporarily
use the old workaround (generate paths in ghc-path's datadir,
and read them from there at runtime), to get the same effect.
On windows, there is a standard default location for Cabal
package datadirs, but if ghc-paths is forced to have its datadir
in a non-standard place, one could set the 'ghc-paths_datadir'
environment variable to point there, afaiu.
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
