Haddock version during build

Manuel M T Chakravarty chak at cse.unsw.edu.au
Wed Jun 4 21:45:52 EDT 2008


Ian Lynagh:
> On Wed, Jun 04, 2008 at 02:19:45PM +0100, Simon Marlow wrote:
>>
>> So the rough plan is this: if we need to build documentation during a
>> build, then we check out a copy of Haddock into the build tree
>
> You mean at the "darcs-all get" stage, rather than when we're about to
> make the docs, right?
>
> And we'll need it in the tarballs too.
>
>> We don't have to ship this Haddock with GHC, it's just a temporary
>> build tool.
>
> Why not ship it with GHC?

I agree with Ian.  Anything but bundling Haddock with GHC is going to  
lead to a big mess.  Here some reasons:

* If you have multiple versions of GHC installed, you likely need  
multiple versions of Haddock.  Keeping those in sync separately is a  
pain.

* Providing Haddock with a library path at install time is infeasible  
for Linux packages managers and similar.

* Automatically searching for a matching GHC is fragile and OS  
dependent.  It also often won't work; eg, when building a binary-dist  
for a compiler that you haven't installed on your system - I do that  
very often.

I think Haddock needs be bundled and installed with GHC - just like  
ghc-pkg.  So, darcs-all should have an option to pull the Haddock repo  
into the build tree.  Then,  it is built there after stage2 as  
described by Simon.  There needs to be an inplace version and an  
install version, and the install targets should handle it just like  
ghc-pkg.

Manuel



More information about the Cvs-libraries mailing list