bardur.arantsson authored 9 years ago and Oleg Grenrus committed 9 years ago

Fixes #2797

Squashed commits:
- Use ., not source

bardur.arantsson authored 9 years ago and Oleg Grenrus committed 9 years ago

This is required for the reworking of integration tests
to use shell scripts.

Use configured compiler for cabal sandbox hc-pkg

Fix #2804: Text Platform roundtrip (with tests)

The GHC[JS]_PACKAGE_PATH and CABAL_SANDBOX_PACKAGE_PATH environment
variables contain colon-separated lists of package DBs, so it doesn't
make sense to call doesDirectoryExist on the colon-separated list.
Instead, this just checks for the existence of the sandbox package DB.

Conflicts:
	cabal-install/Distribution/Client/Config.hs
	cabal-install/tests/UnitTests/Distribution/Client/UserConfig.hs

For most commands (e.g. `cabal install`), the `package-db` field in
`cabal.sandbox.config` is ignored, and the path is reconstructed
from the `prefix` and current compiler instead.  This is arguably
the right behaviour, because the right package DB depends on the
arch/compiler, so it doesn't make sense to specify only one.  This
commit makes `cabal sandbox hc-pkg` behave similarly, to avoid
invoking ghc-pkg on an incompatible package DB (fixes #1935).

Moreover, the compiler version to use is now picked up from the
most recently configured compiler, if any.  Otherwise, the global
default compiler is used, as before.

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

Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.

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

Use a common sandbox for building Cabal and cabal-install.

[ci skip]

Always use new hackage URI

This commit fixes the handling of repo URIs that have a non-null uriPath.
Previously, the code would just override the uriPath if the repo had one.
For example, "http://hackage.haskell.org/foo" as repo would lead to the upload URI
"http://hackage.haskell.org/upload".

Even using `parseRelativeReference "upload"` (instead of "/upload") doesn't work, since
that will replace the last path component of the URI path (i.e. "/foo/bar" would generate
the URI "/foo/upload", but we want "/foo/bar/upload").

Previously, when uriPath was "", then the generated URI would be wrong. For example,
if we have a remote repo with the URI http://hackage.haskell.org (without a trailing slash),
then the previous code will generate http://hackage.haskell.orgupload for the upload URL.
We now use the relativeTo function from Network.URI, which does the right thing.

Additionaly, we now always rely on the new hackage URL layout. cabal now automatically
upgrades the old URI to the new URI when parsing the config file, so manually checking
for that is no longer needed.

Carry package dbs into testsuite

Don't bootstrap Cabal, fixing #2845.

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

This is necessary because otherwise doing a secure update will result in errors
such as

Unexpected response (4,0,4)for http://hackage.haskell.orgpackages/archive/root.json

Alternative we could set up redirections for these in Hackage, but what's the
point?

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

Prior to this patch, the testsuite used your global package db, and
sometimes, the inplace package db, which led to errors if you didn't
have old-time installed globally. They looked like this:

BuildDeps/SameDepsAllRound:          Cabal result was Result {successful = False, success = Failure, outputText = "\"/home/enolan/cabal/Cabal/tests/Setup configure --user -w  /home/enolan/.nix-profile/bin/ghc\" in PackageTests/BuildDeps/SameDepsAllRound\nConfiguring SameDepsAllRound-0.1...\nSetup: At least the following dependencies are missing:\nold-time -any\n"}

Use extra-prog-path in running build-type configure

Add warning about testing Cabal on Windows

Prevent detailed-0.9 test suites from freezing on Windows (fixes #2762)

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

For a while now, we lift out dependencies from conditionals.  If a
package is dependended on regardless of the outcome of a test, the
dependency is lifted out. This has the advantage that we can choose an
instance for the package prior to choosing the value of the flag. Often,
this is the desired behaviour for flags, i.e., to have the flag choice
implied by the possible package choices, rather than the other way
around.

Prior to this change, lifting was simply adding an unconstrained
dependency to such a package at a higher level, which would then of
course still be refined after making the flag choice. We are now making
this more precise by actually computing the union of the ranges in both
branches of the conditional. So we will not choose an instance on the
top level that will later be rejected by both branches.