haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

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