haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

On Wed, 2009-05-27 at 19:47 +0100, Claus Reinke wrote:

> > We need a clear spec on what variables tools are expected to handle and
> > how they are to be interpreted. 
> 
> Currently, there seem to be $topdir and $httptopdir.

And I can't see a justification for there being two.

> Given the split between GHC and HP, it might be useful to have an
> additional $hptopdir, or just a general mechanism for variables in
> ghc-pkg's database (I recall being disappointed when what looked like
> environment variables were unaffected by environment settings..).

I'd rather not create ad-hoc vars which everyone needs to know about for
things like the platform.

> > Supporting relocatable sets of packages is a good idea. We should aim to
> > have something that is usable by each compiler, not just ghc, so
> > interpreting paths relative to ghc's libdir doesn't seem ideal. 
> 
> GHC makes no reference to libdir, it simply talks about a $topdir
> (where it would like to store things it needs) and $httptopdir (where
> haddocks might be found).

Yes ok, on windows the topdir is the parent of dir containing ghc.exe.

> > How about this: a way to specify paths in the package registration info that
> > are relative to the location of the package db they are in. 
> 
> ahem. That sounds like a backwards step, being dependent on two
> locations instead of one.

I don't follow this. Which two?

> Before the HP, windows GHCs could be relocated without needing to
> update the ghc-pkg database, even if some packages were installed
> outside GHCs $topdir.

I don't see how this is related to what the Windows installer for the HP
is doing. Sure, since it's installing packages relative to ghc and we'd
like the whole thing to be relocatable then it should use relative
paths. I don't think anyone disputes that, the question is how to
implement relative paths.

> With your variant, just about any change would need updating.

I must be missing something. If you move package.conf and the packages
in one go, then nothing needs changing as far as I can see.

> Assuming that  the parts are independently located by whatever the OS
> packaging  conventions say, and can be independently relocated
> otherwise, it  seems simpler to continue with the variable scheme, but
> with improved support and documentation for it.

My suggestion seems very simple! I'm clearly missing some problem which
you can see.

To be clear, here's what I'm imagining:

blah/package.conf
blah/lib/foo-1.0/libfoo-1.0.a

and package.conf would contain foo-1.0 with paths looking like
"$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name
we agree on) as being "blah/" because that's the dir containing the db.

So crucially, it doesn't really matter where ghc.exe is. Assuming ghc
can find the package conf then it can find all the files. So it'd let
you create multiple relocatable package collections. If the primary
package db is kept relative to ghc (eg in ghc's topdir) then the whole
ghc installation including libs is relocatable

Duncan