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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
