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. Thanks Ian _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
