I've been thinking about haddock 2 and GHC, and it's not clear to me
what the best way forwards is.
Haddock uses ghc-paths to work out where the GHC libdir is. This should
work fine for running haddock in the tree, but it won't work for
installing haddock as our builds are relocatable and ghc-paths bakes the
paths in.
There was some discussion about this a while back, eg, one could store
the paths in ghc-paths' datadir, then rebuilding ghc-paths (using the same
place for its datadir) would regenerate the data and already linked clients
of ghc-paths (such as Haddock) would pick up the new paths, or one
could dynamically link ghc-paths (Simon's preference, iirc).
Since dynamic linking is on the table for 6.10 anyway, wouldn't that work?
Alternatively, we could build haddock and haddock the libraries, but not
ship haddock with GHC. I think that some people prefer this anyway.
However, if we do that, people need to make sure that they install a
version of haddock that is compatible with their .haddock files.
Isn't it even worse? One needs a version of haddock that was built
against the same ghc version, because of haddock reading ghc .hi
file (via ghc api), right? Unless we find a solution for this ghc api
client issue, all ghc api clients will be ghc-version specific (no
compatibility in any direction).
There's also a problem where, at the point we are configuring the
libraries, we can't tell Cabal where haddock is because we haven't built
it yet. I think that the best way around this is to add a
--with-haddock=PATH flag to "Setup haddock".
Wasn't the latest workaround plan to build ghc without haddocking,
then build haddock with that ghc, then do the haddocking? In which
case, either there is no haddocking, or there is a haddock.
So currently I'm thinking that the best way is:
* Build the ghc-paths library when building GHC, but don't install it
* Build haddock when building GHC, but don't install it
If you build these anyway, why not install them, for a local build at
least? No other version of haddock will do with that ghc.
You can't easily package them into binary distributions/installers,
because the paths won't match on the target machines. Which brings
us back to ghc-paths, and how to make pre-compiled clients aware
of new paths resulting from re-installation of ghc-paths. If that had a
solution (would dynamic linking of ghc-paths do the trick?), you could
even package haddock with ghc, and just make installing ghc-paths
part of the installation process on the target machine.
Any comments?
Instead of working around them in each individual case, I'd really like
to see general solutions to the two issues of
1 updating ghc-paths and notifying existing clients
2 making (some) ghc api clients less dependent on a single ghc
version
Most suggestions about this have been shot down in the past, iirc,
the closest to being possible were dynamic linking for 1 and some
cross-ghc-version reading of .hi-files for 2 (at the risk of losing
information, because the .hi-format itself would still change; so this
would work only for some ghc api clients, and only for a limited
range of ghc versions, but haddock ought to be among those clients).
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
