haddock-2.3.0 literate comments discarded from .lhs input

[Claus Reinke]

> 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