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