In fact it'll come with the Haskell Platform, and that's feasible because
I don't think we're planning to make relocatable binary distributions of
the HP.
Not having relocatable binary distributions would be sad indeed,
especially as a regression from what we used to have. Being able
to use ghc from an external drive, or over network connections
with randomly assigned drive letters, was rather useful for presentations,
and I believe was also used by lecturers in theatres with fixed PCs.
Having to rebuild and inplace-install a small HP-paths package
after relocation (or after the drive letter of the day is known) would
be a small price to pay for that flexibility (but I guess that won't work).
Yes you need to re-install Haddock if you re-install GHC, but that's just
like any other library (think of Haddock as a library). I think it's
unlikely that anyone will want to have multiple Haddock installations, but
if they do then they'll just have to manually rename the Haddock binary
after installing it.
Isn't that just the problem we're talking about? It is not about wanting
to have multiple Haddock installations. After the switch to Haddock 2,
there will _have to be_ one Haddock installation per GHC installation.
About the only thing one can do in that situation is to install haddock
over ghc, so that switching PATH always switches both haddock and
ghc. But that won't work if one calls ghc with explicit absolute paths..
This is going to be very much like the issues with finding the right
runhaskell/ghc-pkg/.. for the currently used ghc, issues we just got
rid off.
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
