Haddock version during build

[Ian Lynagh]

On Mon, Jun 16, 2008 at 10:21:12AM +0100, Simon Marlow wrote:
> Manuel M T Chakravarty wrote:
> 
> >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.
> 
> It wouldn't be a disaster if we had to ship Haddock with GHC, but it's not 
> ideal.  I really want Haddock to be a separate entity, as far as possible - 
> just a client of the GHC API.  This is a problem that will crop up with 
> other clients of the GHC API too: they all need to know the default 
> package.conf location.

The reason that Manuel and I are proposing shipping haddock with GHC
isn't due to the problem of finding the libdir (although it
coincidentally solves that too), but because it's needed both during the
build and after GHC is installed.

Of course, you could argue that it should be separately upgradable, but
even then the .haddock format is fixed, and you can't rehaddock the
bootlibs with the upgraded haddock anyway (unless you bundle the
sources, in which case you wouldn't need haddock during the build).

> Perhaps we should have a general solution to this? 
>  I'm open to suggestions.  Here's one: when installing a GHC distribution 
> we create a tiny library called libghc-defaults.a that exports a single 
> symbol
> 
>   char *ghc_default_libdir="/usr/lib/ghc-6.10/or/whatever"
> 
> and we always add libghc-defaults.a when linking the GHC package.

We could instead have Cabal generate

    ghcLibdir :: Maybe FilePath -- Nothing if compiler /= GHC
    ghcLibDir = Just "<what $GHC --print-libdir says>"

in Paths_$package.


Thanks
Ian