Currently, there seem to be $topdir and $httptopdir. And I can't see a justification for there being two.
Each variable provides an indirection that decouples the installation from one source of _independent_ relocations (btw, I've always imagined that it is called 'http' instead of 'html' to allow for references to haskell.org when no local docs are installed, but it doesn't seem to work that way).
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?
package db + package path: in the current system, you only have to update the package db if you move a package that isn't installed under the GHC tree; in your suggestion, you also have to update it if you move the package db/GHC itself while having non-core packages installed outside the GHC tree.
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.
I was just disambiguating which GHC installers I was referring to, since there are now two possibilities, with different properties.
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.
You seem to be assuming that everything is under a common root? That isn't the case for most unixes (different locations for bin/ doc/ lib/ .., docs installed or not), and even on windows, it stopped being the case with cabal insisting on 'Program Files/Haskell/...' as the default install. Since ghc traditionally installs into 'c:/ghc/ghc-<version>' (on my system, at least, but I think that no-spaces-location was suggested by one of the GHC installers originally, and spaces in tool paths still confuse the GHC build system), I have two locations. If I move GHC, nothing needs changing. If I move packages that didn't come with GHC, package.db needs updating. If the packages had been registered wrt to a $cabaltopdir, no changes would be needed in either case. In your suggestion, if I move GHC but not the packages, package.db needs updating, if I move the packages but not GHC, package.dg needs updating, only if I move both, and by the same relative path, no update is needed.
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
That is everything under one tree, right? And since package.conf is GHC's register, GHC would have to be in that tree as well.
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
That is what GHC did on windows before cabal changed the package locations away to a path that neither GHC nor its build tools can use. Is that even possible on unix systems, with their various packaging and location traditions? And if Simon ever makes that breakthrough of binary compatibility at least between minor GHC versions, we can't have the libraries in the GHC directories, as they'd be shared between several GHCs. Claus