GitLab

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

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

I've rewritten the test suite to be more concise and "correct by
construction".  The primary method that this is achieved by
is introducing the 'TestM' monad, which carries around the
important state for the tests so that (1) we don't have to
pass it as an argument all around, and (2) we can automatically
make the correct decisions about how to do things.  This new
method emphasises "configuration by convention": we assume
that a test-case named "Foo" has its test packages in the
directory "tests/PackageTests/Foo".

A secondary change is that all command functions automatically fail if
they have a non-zero exit code (unless you use the 'shouldFail'
combinator which inverts the sense.)  This saves a lot of typing
on test-cases.  (In fact, I've reorganized all of the commands
related here.)

In the process, I've tightened up the logic for how to find the
LocalBuildInfo of the Cabal we've testing, so we should now
reliably be testing the inplace Cabal library, and not the
system library (as was often the case.)

Because things are a lot shorter, there is no good reason to
make Check modules except for the biggest test cases.  Most
test-cases have been folded into PackageTests.Tests; if you
have a small test-case you should just put it there.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This gives newcomers like me a better chance to understand how the Cabal
test suite is constructed.

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>

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"}

Fixes #2489. The detailed-0.9 test suite runner would deadlock because
the IO manager was not draining the output pipe of the child
process. Thanks to @r0ml for the patch.

Add functionality to allow preprocessors like hsc2hs and C2HS to inform
Cabal of extra C sources that they create that need to be compiled and
linked.  Includes hsc2hs-based test case.

Some package tests run multiple tests on the same package, causing the
build directory to be overwritten. For debugging, it is important to
keep the build directory contents, so in this case we run each test
with a different build directory.

Also runs the HPC tests regardless of the detected version.

getConfigStateFile now throws meaningful exceptions which are caught by
tryGetConfigStateFile and friends, which are allowed to propagate,
rather than just calling 'die'. If the LocalBuildInfo was generated by
an older version of Cabal, an exception is still generated, but the
LocalBuildInfo is included if it is recoverable. This feature is used to
reduce code duplication between the library and the test suite.

PackageTests has its own version of getPersistBuildConfig which does not
check which version of Cabal created dist/setup-config. Now that the
LocalBuildInfo is written with Binary, this version needed to be
updated, too.

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>

This is a workaround to enable streaming test logs in Cabal's test
suites.

This means that the package tests will pick up whatever GHC was passed
on the

    cabal configure --enable-tests -w some-ghc

command line.

Fixes #676.

Detect bug #1287.

This allows specifying the main-is field as a C file.

This is closely based on patches by Edward Z. Yang, who in turn credits
and earlier set of patches by Irene Knapp. The slight difference in
this version of the patch is that it is adjusted to work with the new
approach where we have separate hs compile; c compile; and link phases.