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.
Please don't move your windmills while I'm fighting them!-) If you don't want to move from absolute paths for non-core packages, the current system should just work, right? I thought we were talking about (a) making ghc-pkg (optionally) instantiate any variables in its database in (all of) its command-line output and (b) allowing non-core packages to be relocated without having to update ghc-pkg's database.
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.
Personally, I only dislike the idea of hardcoding specific variable names in ghc-pkg, which is why I suggested a name-independent approach (I also dislike the current duplication of code in ghc-pkg/ghc api/..). $cabaltopdir would just improve the handling of the default cabal install locations, without dictating where users say those default locations should be - and if users move specific packages/package parts to different absolute locations, those absolute locations would still have to appear in the package database, but I'd expect that to be an exception. If common prefixes are abstracted out via variables, it would simply be easier to see that the majority of package parts are not randomly distributed over the available file systems, but related to the chosen default settings of the tool that installed them (that might involve communication between GHC and Cabal: GHC knows about its own dir, but would have to ask Cabal about its locations - or, better, Cabal could tell GHC about its locations once, when the user changes them). I'm mostly seeing the windows perspective at the moment, btw, but even on unix, one might want to abstract out common prefixes, in case one decides to move packages from $HOME/ to system-wide prefixes, or from one system-wide prefix to another. Perhaps the difference doesn't matter much, apart from readability: Let's say I wanted to move a GHC/Cabal/HP installation to a USB drive: moving GHC/corelibs is straightforward (it doesn't care under what drive name the USB drive gets mounted on the lecture theatre computer), but how would I move Cabal-installed non-core packages (not to mention Cabal itself?)? Is that use case documented in some faq? If the extra package paths are absolute, it would involve something like search&replace on the concrete representation of the supposedly abstract package database, but as long as that representation is a simple text file, that might not be too troublesome; if the extra package paths are relative to a $cabaltopdir, it would involve telling GHC about the new location prefix whenever calling it directly (or telling Cabal about its new location, and Cabal passing that on when calling GHC).
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.
s/the/some/ ;-) It is a reasonable default to expect, but if Cabal had ever asked me before starting to install things there, I'd have changed that default immediately. I was thinking more about things that would appear in package.conf: C:\Program Files\Haskell\<package>\<ghc-version> C:\Program Files\Haskell\doc\<package> but it is the same difference: there are now two locations to consider even on windows (GHC/corelibs + Cabal/other packages), and that is probably how it should be.
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.
Maybe so, but last time (end of January) I asked about the GHC build (in a space-free path) using tools where cabal installs them by default (with spaces in path), Simon M answered: "It's not practical in general to cope with spaces in paths in the build system. IIRC we tried to get this right once and gave up.". So if there is a tool path specific subset of the problem that could be solved more easily, it doesn't seem to help.
Is that even possible on unix systems, with their various packaging and location traditions? I'm not sure what you're referring to.
Some unix branches seem to distinguish themselves merely by different package management/location. But apart from Mac frameworks, I'm not aware of any unix that would not expect libraries/binaries/docs to be installed in different locations (instead of common, language-specific roots, the common roots are purpose-specific). Relocation might not be as typical there, though (don't know how mounting external drives affects paths there, or whether users might want to relocate packages between different prefixes like /opt, /etc, /usr, .., or just from user-local to system-wide locations).
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.
Ok, then the question is just how to communicate those locations to GHC: monolithically, as absolute paths, or separated into common prefixes and relative paths (usually, only the prefixes would change on relocations). My preference would be separated, with ghc-pkg filling in the prefix variables' current values when asked to do so. Claus