Haddock version during build

[Claus Reinke]

> Both GHC and ghc-pkg need to know one path: the location of package.conf. 
> Everything else is found from there.  They both work the same way: on 
> Windows they find package.conf from a known relative offset from the 
> lcoation of the binary, and on Unix both programs have a wrapper script 
> generated at install-time that passes the location of package.conf as a 
> parameter.  Having GHC invoke ghc-pkg wouldn't help, because ghc-pkg still 
> needs to find package.conf.
> 
> I'm suggesting adding another mechanism for clients of the GHC API.  This 
> wouldn't affect GHC or ghc-pkg, because they are already statically linked 
> (dynamically-linked libraries would help here, though, and might enable us 
> to share a common mechanism).
> 
> Does that make things clearer?

A little;-) But I was suggesting to build on GHC's and ghc-pkg's
common awareness of the package.conf location (which I inadequately
circumscribed as "ghc calling ghc-pkg"), and not just for libdir, but
for all the other path-related issues that keep coming up but are
never fully resolved (such as #1226, and wasn't there also the game
of Cabal and other tools trying to find the ghc-pkg matching a given 
instance of ghc?):

1. register other paths that may change with (re-)installation
    with ghc-pkg, so that both ghc ('ghc --print-docdir/--print-libdir/
    --full-help'; #1226, #1880) and users of ghc-pkg 
    ('ghc-pkg describe ghc-paths') can find them. 

    Here I was merely thinking of a package description without 
    associated code, with the paths directly encoded in the
    package description fields.

2. turn your mini-C-package-with-libdir-path suggestion into a 
    mini-Haskell-package-with-libdir-path suggestion. For libdir
    itself it might not matter whether the path is coded in the ghc 
    package or in a separate ghc-paths package, but for other
    paths the latter might give more flexibility?

    Can package ghc be made to depend on package ghc-paths
    while still permitting ghc-paths to be updated independently?
    That part probably needs dynamic linking of packages?

If the GHC API can query package.conf, (1) might suffice,
otherwise, one mini package ghc-path could have the paths
both in its package description fields (1) and in an exposed
Haskell module GHC.Paths?

3. It would also be useful if GHC and ghc-pkg could point
    to each other (they both know about a common location
    for package.conf, but how does a tool that finds either
    GHC or ghc-pkg find the matching other?).

Claus