haddock-2.3.0 literate comments discarded from .lhs input

[Claus Reinke]

>> If you don't want to move from absolute paths for non-core packages,
>> the current system should just work, right?
> 
> Yes.

The current system being the $topdir one.

> Though it also allows for the possibility of relocatable sets of
> packages that are not installed relative to the compiler. But more
> importantly it's more general and simpler than the current '$topdir'
> that ghc uses.

'it' now being the new system evolving in this thread, or have I missed
anything?
 
>> (a) making ghc-pkg (optionally) instantiate any variables in its
>> database in (all of) its command-line output and 
> 
> Yes, though I'm only asking for two vars (previously one), not an ad-hoc
> set of vars.
> 
>> (b) allowing non-core packages to be relocated without having to
>> update ghc-pkg's database.
> 
> In my suggested system this is possible if that set of packages use
> their own package db (containing relative paths).

That is news to me - was that specified before this thread moved
to ghc-users?
 
> In your system it's possible by updating some var in a central registry
> and having that set of packages use paths relative to that var.

So, essentially, your system would have to keep a file listing the
various package.conf locations (currently, GHC only knows about
two: system/user, everything else would have to be passed on the
commandline..). While my system would have to keep a file listing
the variable bindings, so that tools processing the package db can
instantiate the variables.

I could see both approaches being useful, even together.
 
> So ghc's current system uses two vars, $topdir and $httptopdir. 

This is GHC's view of its database. It should be useable independently,
via ghc-pkg and ghc api clients (such as GHC, GHCi, Haddock, ..) -
all of which should be able to resolve the variable bindings, in the
same way. Btw, it would really be nice if the package handling code 
was shared rather than duplicated.

> I'm proposing to replace those with a standardised ${pkgroot} and
> ${pkgrooturl} vars which are usable by all compilers and in more
> situations.

Now you are talking about Cabal's view of its database. It doesn't
have to expose the underlying implementation's view, especially since
the other implementations organise their package handling differently.

And why just two variables? Is $pkgroot about .hi files, .a/.so./.dll
files, or about include files, or haddock indices, or ..? In windows,
these tend to end in a common sub-hierarchy, but you're aiming for
something general, right?
 
> You're proposing a central registry of vars and to have ghc-pkg
> (optionally) expand these vars which could be used anywhere in the
> installed package descriptions. Presumably you're also suggesting some
> mechanism to query and update this registry of variables.
> 
> Is that a fair summary?

I think so. And you're proposing several separate registries (hasn't
that been a Cabal problem in the past, even with just user and system
to choose from?). Presumably you're also suggesting some mechanism
to query and update the meta-registry of package database locations.
 
Claus