Haddock version during build

[Simon Marlow]

Claus Reinke wrote:
>> 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.

Yes, that could be done.  It's a bit yucky though.  Maybe we should have an 
XML configuration file like everybody else.

Remember that storing libdir in package.conf is strictly superfluous - you 
already need to know libdir in order to find package.conf in the first place.

> 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?

Right.  It's somewhat harder to make it a Haskell package, a C library is 
much simpler.

Cheers,
	Simon