GitLab

It was sorted by version number so far.

I also added a sort to the normal output (without --simple-output)
since the source it comes from does not guarantee sortedness.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

I was seeing many "WARNING: cache is out of date" errors during validation
claiming that my package cache was out of date. This patch eliminates those
errors by ensuring that when we rebuild the package cache, the modification time
of the directory containing the package database is set to be the same as the
modification time of the cache.

It was marked as "backwards compatibility" in 2006, so I think
can be removed now. It allowed using old field names when looking
at fields with ghc-pkg.

It used to just ignore the --simple-output flag

In particular, this fixes it if we are using dynamic libraries by
default and don't build the vanilla way.

We used to say

    $ ghc-pkg list blargle
    /usr/local/lib/ghc-7.4.1/package.conf.d

which may imply that blargle was found in
/usr/local/lib/ghc-7.4.1/package.conf.d

Really we ought to support all the old flags, but warn that they
are deprecated.

Rename package database flags in both GHC and ghc-pkg so that they are
consistent with Cabal nomenclature.

Add a version check to the build system so that the correct set of
package db flags are used when the bootstrapping GHC has version < 7.5.

It was only working when followed by something, e.g. "$topdir/base".

I'd naively assumed that the haddock-html field would only use the
$httptopdir variable. Hopefully this will fix the windows build.

Tools handling installed packages need to be able to interpret the
paths which are relative to the ${pkgroot} which means they need to
know the value of ${pkgroot}. With ghc-pkg this is not always obvious
since ghc-pkg does not currently have any way machine interface for
reporting the location of its package dbs (global, user). The solution
we have arrived at is simply to emit the pkgroot as an extra field
when it is needed.

There are two cases:
 * --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
   ${pkgroot} var, so it will appear literally in the output and the
   pkgroot field will be generated so that tools know what value to
   use for the ${pkgroot}.
 * --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
   and ${pkgrooturl} vars and will not generate the pkgroot field.

The defaults are:
 * ghc-pkg dump/describe --no-expand-pkgroot
 * ghc-pkg field --expand-pkgroot

The haddock-html and haddock-interface fields are now checked
as well. Had to fix up ghc-cabal as it used relative paths for
the inplace package's haddock-html. It turns out that these
were never used so it could simply be omitted.

Historically ghc implemented relocatable packages by allowing
"$topdir" in the package registration info and having ghc expand
this with its notion of $topdir. The topdir refers to where ghc
itself is installed (specifically the libdir).

The ${pkgroot} spec takes this idea and makes it portable.
(http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
Instead of paths relative to where ghc is installed, they can be
relative to the package database itself. Thus it is no longer a
ghc-specific idea and can work for package collections other than
the global package db.

It was never a universal solution. It only worked with the GNU linker.
It has not been used by Cabal for ages. GHCi can now load .a files so
it will not be needed in future.

For shell-based build systems the feature is still available as:
  ghc-pkg register --expand-env-vars

Historically, ghc-pkg allowed environment variables to appear in the
input files for ghc-pkg register. They are not stored in the package
database but are expanded upon registration. This feature helped for
build systems based on makefiles and shell scripts. These days the
vast majority of such files are generated by Cabal and we don't want
any ${name} strings (e.g. perhaps in a package description) getting
accidentally interpreted as an environment variable.

GHCi libs are no longer necessary, as we can use the .a or .so versions
instead.