Haddock version during build

[Simon Marlow]

Claus Reinke wrote:
>> 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.  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.
>>
>> The downside is that this means running a C compiler at install time, 
>> but only if the GHC binary dist is supposed to be position-independent 
>> - many are not.
> 
> Why not make that a proper package, exposing a Haskell module
> GHC.SettingsAndPaths? There are other paths that have similar
> issues, I assume (docdir, manpage, ghc-pkg database, ..)?
> Are there differences in who is trying to find those paths (GHC vs 
> GHC-compiled GHC API client vs GHC-based commandline
> tools vs ..), or could one solution fit all? GHC can't currently find
> it docdir, so I suggested registering these paths with ghc-pkg, which 
> GHC can find, but perhaps using runghc on a one-liner
> that imports GHC.SettingsAndPaths would work just as well?
> 
> And if one does relocate (parts of) GHC, how is the relinking (of GHC, 
> GHCi, Haddock, ToolX, ..) supposed to be done,
> to get the uptodate locations? If the paths themselves are
> registered with ghc-pkg, updating is easy, but if a package
> with path info is registered with ghc-pkg, one either needs
> to relink, or link dynamically?
> 
> Btw, could any results from this discussion, and any other GHC API
> issues, please be linked from the GhcApiStatus page? I added the libdir 
> issue and the generic AST traversal issue a while ago, but I can't tell 
> from that page what is going on, and I haven't seen others using this 
> page, nor have I seen answers/opinions about the issues raised (has that 
> Haskell-cafe question "How to get the typechecked AST" even received an 
> answer?). Has this GSoC project started yet, and is there (going to be) 
> a blog for it? It is just that I'm really interested in this, and don't 
> want to miss any developments!-)

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?

Cheers,
	Simon