GHC has been changed to guarantee producing valid object files for
signatures (they will usually be empty).

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

There's no chrome here, but some of the guts for Cabal supporting compiling
signatures.  The key UI is a new --instantiate-with flag for ./Setup (no support
cabal-install side!) which properly modifies the package key, calculates extra
hole dependencies for a package, and ensures an appropriately
translated -sig-of is passed to GHC.  The UI here is supremely user-unfriendly:
the intent is that users will use cabal-install to calculate these parameters
for them.

ToDo: Cabal's inconsistency check in ./Setup needs to be adjusted to be
less zealous.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

the datadir location for the inplace InstallDirs was pointing to the top directory
of the package instead of the directory containing the data. this has been fixed.
since templates have already been expanded at this point, datasubdir raises an
exception an cannot be used in generalInstalledPackageInfo. therefore the
full path is stored in datadir.

A note first: this patch does NOT modify the user-facing experience in Cabal
files; it only changes how we register information in the installed package
database.

This patch takes the exposed-modules and reexported-modules fields in
the InstalledPackageInfo structure and consolidates them into just the
exposed module fields, which now has a Maybe flag indicating if a
module is reexported and, if it is, what the original module was.  I've
also added in a field for signatures although it is currently unused.

The big benefit of this change is that it will make processing at the GHC level
much more uniform when we add signatures: signatures can also be reexported
and the new representation means we can share the code.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes #2130.

The initial support for module re-exports relied on ghc-pkg to resolve
user-specified re-exports to references to specific installed packages.
This resolution is something that can fail so it's better for Cabal to
do it during the package configure phase.

In addition, it is inconvenient in ghc-pkg to be doing this resolution,
and it just seems fishy as a design. Also, the same ModuleExport type
was being used both for user-specified source re-exports and also for
the specific re-exports in the package db.

This patch splits the type into two: one for source level, and one for
resolved ones for use in the package db. The configure phase resolves
one to the other.

One minor change: it is now possible to re-export a module defined in
the same package that is not itself exported (ie it's in other-modules,
rather than exposed-modules). Previously for modules definied in the
same package they had to be themselves exported. Of course for
re-exports from other packages they have to be exposed.

Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
would only be one instance of it in the installed packages database.  This
posed problems for situations where you want a package compiled twice against
different sets of dependencies: they could not both exist in the package
database.

Package keys are a hash of the package ID and package
dependencies, which identify a package more uniquely than a package ID, but less
uniquely than an installed package ID. Unlike installed package IDs, these can
be computed immediately after dependency resolution, rather than after
compilation.  Package keys require support from the compiler.  At the moment,
only GHC 7.10 supports package keys (the reason is that old versions of GHC
do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
package database matches with the -package-name embedded in an hi file; so
the format is fixed.) We fallback to package keys == package IDs for old
versions.

Note: the ./Setup configure fallback script does not try particularly hard to
pick consistent sets of dependencies.  If your package database is too difficult
for it to resolve, manually provide installed package IDs or use cabal-install's
dependency solver.

Note: This patch *suspends* the reinstall check unless it would result in
a different package, so cabal-install will now happily reinstall foo-0.1
compiled against bar-0.2 if foo-0.1 already exists.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Re-exported modules allow packages to reexport modules from their
dependencies without having to create stub files.  Reexports of the same
original module don't count as ambiguous imports when module finding
occurs.  The syntax is:

    "orig-pkg" OrigName as NewName

You can omit 'as NewName', in which case it is reexported as the same
name.  Self referential aliases work too; however, they're only visible
to packages which depend on this package.

Left to future work: just provide a module name 'OrigName', where ghc-pkg
figures out what the source package is.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

It's just noise that duplicates information in the 'LICENSE' file.

See #1200 (for which this is a partial fix).

Restores old behaviour broken by @igfoo in
8395c5db. Fixes #1241.

Cabal doesn't know how to build them, but it does know how to install
and register them. In particular, this means that GHC's build system
can use Cabal to install them.

Plus add functions for finding all the deps of one or more
components, in dependency order. This will be useful for
building individual targets, e.g. cabal build foo.

Creates an empty package DB at the specified location.

It can be non-obvious why a package is registered more than once.

Makes things a little simpler in GHC's build system if libraries are in
the same directory as their name.

At the top level we now have cabal/ and cabal-install/

The description is already included. The one-line synopsis should be
there too. Note that this is an API change that will affect compilers.

It is a rather silly feature and is not guaranteed to work. Having
configured and built using one set of dbs, there's no guarantee you
can register into another set. We should probably just remove it.

Important for the case of registering inplace when we're using a
specific package db, e.g. when doing isolated builds.

As is the output from ghc-pkg dump.

Do it in the pretty-printing rather than just before writing the file.

In the LocalBuildInfo, for each component, for the list of component
dependencies, keep both the InstalledPackageId and the PackageId.
That way we don't need to keep converting the InstalledPackageId
to the PackageId, via the package index (which is just horrible).

Previously, we just added a -inplace suffix, but this will cause
problems when developing multiple packages inplace, and then
installing them.

Also, there was a round of refactoring: registerPackage now takes the
InstalledPackageId as an argument, and generateRegistrationInfo is
exposed for constructing it.  This means that callers of
registerPackage get to munge the InstalledPackageInfo before it is
registered.

Most TODOs related to the new InstalledPackageId stuff.