haddock-2.3.0 literate comments discarded from .lhs input
claus.reinke at talk21.com
Thu May 28 09:12:36 EDT 2009
> 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
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
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:
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
My preference would be separated, with ghc-pkg filling in the prefix
variables' current values when asked to do so.
More information about the Glasgow-haskell-users