haddock 2 and GHC
igloo at earth.li
Tue Aug 19 10:33:17 EDT 2008
On Tue, Aug 19, 2008 at 03:05:48PM +0100, Simon Marlow wrote:
> I just meant that Haddock already uses Paths_haddock to get the location of
> its own support files,
Oh, I see. Right, so as long as we give relative paths for everything
that'll work for Windows bindists, but we'll need to fix that for Unix
bindists (either passing a flag with the shell wrapper, or setting the
environment haddock_datadir variable).
This means that, on Windows at least, we'd have to jump through some
hoops with flags like --bindir from the top-level configure; we have to
mangle them so that they are relative to $prefix, and fail if we can't
(well, I guess we could prepend some ../s, but that feels very wrong).
Actually, I'm not sure those flags will work on Windows as things stand
anyway; I think GHC itself will fail to find things.
> which on Windows will be constructing a path
> relative to the binary location. If the GHC libdir is in a fixed location
> relative to Haddock's support files (in a Windows installer), it's easy.
We can probably even make them share a libdir, and use
Paths_haddock.getLibDir to find it (but only when built as part of
GHC)...which leads us back to:
> Hmm. We want a flag that isn't subject to Cabal's automatic resolution.
> Duncan, is there any way to do what we want here?
If not, then perhaps adding "manually-en/disabled-only" flags to Cabal
is the way to go. This would actually allow us to simplify building the
GHC package too, as we wouldn't need to worry about explicitly turning
off features like ghci or the NCG.
More information about the Cvs-ghc