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