haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

On Thu, 2009-05-28 at 14:12 +0100, Claus Reinke wrote:
> > 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?

Yes.

Though it also allows for the possibility of relocatable sets of
packages that are not installed relative to the compiler. But more
importantly it's more general and simpler than the current '$topdir'
that ghc uses.

> 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 

Yes, though I'm only asking for two vars (previously one), not an ad-hoc
set of vars.

> (b) allowing non-core packages to be relocated without having to
> update ghc-pkg's database.

In my suggested system this is possible if that set of packages use
their own package db (containing relative paths).

In your system it's possible by updating some var in a central registry
and having that set of packages use paths relative to that var.

> > 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.

So ghc's current system uses two vars, $topdir and $httptopdir. 

I'm proposing to replace those with a standardised ${pkgroot} and
${pkgrooturl} vars which are usable by all compilers and in more
situations.

You're proposing a central registry of vars and to have ghc-pkg
(optionally) expand these vars which could be used anywhere in the
installed package descriptions. Presumably you're also suggesting some
mechanism to query and update this registry of variables.

Is that a fair summary?

> 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?

Ok, so you want to construct a set of relocatable packages. This needs
to be decided from the beginning when you compile said packages because
otherwise packages can have paths baked into them. There are some
restrictions on making relocatable packages, eg you can't set --libdir
to an absolute path, it has to be relative to the --prefix.

In addition to making the package relocatable, we would have to register
the package into a package db that lives relative to the packages in
question. This db would contain relative paths (using ${pkgroot}).

Once this is done then the whole lot would be relocatable onto a USB
drive or whatever. To use this set of packages you would need to specify
--package-conf= to ghc, or --package-db= to cabal.

> 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; 

Aye, so if you want to be able to move then then it's better if they're
relative.

> 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).

So that's the bit in your suggestion that corresponds to using
--package-conf= in my suggestion. And it assumes that you don't need to
set $cabaltopdir to two values simultaniously, eg if the machine you've
moved it to on the USB stick also has cabal packages that it needs to
use.

> > 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.

Spaces in paths in general is indeed hard. The case where the build tree
is in a path with no spaces but some of the external tools are is much
easier. Simon was talking about the more general, harder case.

> >> 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).

It's not especially common after installation. The advantage of a
prefix-independent binary install is that it makes installation easy,
just a copy.

Duncan