On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote:
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.
But if you're registering global packages that are installed outside of the GHC tree then you wouldn't register them using relative paths. I'm not saying everything must use 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.
You seem to be assuming that everything is under a common root?
Well it is on Windows which is the main case where people want relocatable installations. If we wanted relocatable installations on Unix then it'd all have to be under one root too, eg /opt/whatever.
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.
Sure, extra packages should not be installed in the ghc tree and so those should not use paths relative to the ghc location.
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.
For some reason I really dislike the idea that we make up specific vars like $cabaltopdir for specific purposes. Perhaps that's just me. I want a general solution, not something that forces everyone to adopt conventions like installing everything in ~/.cabal/. That's just a sensible default, but the user rightly has full control over --prefix, --libdir etc etc.
In your suggestion, if I move GHC but not the packages, package.db needs updating,
No it does not. That would only be the case if you always registered things relative to ghc, but that'd be silly for things not actually installed in the ghc install tree.
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.
Are you suggesting that we need to be able to move core libs that are distributed with ghc, independently of where the ghc binary is?
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?
Not necessarily. For the things in the same tree it'd be sensible to use relative paths. For things not in the same tree it'd be sensible to use absolute paths. This scheme also allows other sets of relocatable packages, so long as ghc gets told where to find the package.conf.
And since package.conf is GHC's register, GHC would have to be in that tree as well.
For core packages shipped with ghc/hp, yes.
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.
Do you mean installing binaries in C:\Program Files\Haskell\bin by default? That decision was made by the Windows users. It's true that the GHC build system cannot work in a directory containing spaces, and that's probably too hard to fix. However using tools (eg happy, alex) that are in a dir containing spaces should not be nearly so hard to fix.
Is that even possible on unix systems, with their various packaging and location traditions?
I'm not sure what you're referring to.
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.
I've never suggested they should be. Only things distributed with ghc/hp should be together in one relocatable tree. Everything else the user installs should go in the appropriate locations. Duncan