Haddock version during build
david.waern at gmail.com
Tue Jun 3 10:42:51 EDT 2008
2008/6/3 Ian Lynagh <igloo at earth.li>:
> On Tue, Jun 03, 2008 at 03:43:55PM +0200, David Waern wrote:
>> 2008/6/3 Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
>> > As I understand it the issues is that since haddock 2.x is using the ghc
>> > api and loads .hi files and then the .hi versions need to match up.
>> > Perhaps Simon or David can comment in more detail and about how we might
>> > relax the restriction.
>> The background is that Haddock needs the path to a GHC library
>> directory, to be able to initialize the GHC API. The path must belong
>> to an installed GHC of the same version that Haddock was built with.
>> In Cabal, we get the path from the configured GHC version.
> Do you mean that whenever you run haddock you need to tell it which ghc
> libdir to use?
Yes. However there's a TODO item for automatically searching for a
compatible GHC version, if none is specified.
> Can't haddock instead use the path for the compiler that it was built
> with? With my Debian maintainer hat on at least, this is what I'd want.
Hmm, I thought about this when I did the SoC project, but considered
it to be a bad idea since it won't work if you want to distribute a
binary version of Haddock.
>> I usually install the documentation by first installing GHC without
>> docs, then installing Haddock with this GHC version, and then running
>> the docs installation.
> This is impractical for systems like Debian. If we want to move to
> haddock2 then, as things stand, I think we'd need to ship haddock as
> part of GHC.
Yes, I understand that this is problematic for packaging systems. I
wonder if there's a better solution.
More information about the Cvs-libraries