-
Edward Z. Yang authored
In the process, I refactored the test suite a bit to be more robust and handle the --with-compiler more correctly in most cases. One note: I turned off the HPC tests with the GHC and WITH_GHC parameters don't match. In principle this should work but there is some sort of bug. I don't plan on fixing the bug. Signed-off-by:Edward Z. Yang <ezyang@cs.stanford.edu>
Edward Z. Yang authoredIn the process, I refactored the test suite a bit to be more robust and handle the --with-compiler more correctly in most cases. One note: I turned off the HPC tests with the GHC and WITH_GHC parameters don't match. In principle this should work but there is some sort of bug. I don't plan on fixing the bug. Signed-off-by:
Writing package tests
The tests under the PackageTests directory define and build packages that exercise various components of Cabal. Each test case is an HUnit test. The entry point for the test suite, where all the test cases are listed, is PackageTests.hs. There are utilities for calling the stages of Cabal's build process in PackageTests/PackageTester.hs; have a look at an existing test case to see how they are used.
In order to run the tests, PackageTests needs to know where the inplace
copy of Cabal being tested is, as well as some information which was
used to configure it. By default, PackageTests tries to look at the
LocalBuildInfo, but if the format of LocalBuildInfo has changed
between the version of Cabal which ran the configure step, and the
version of Cabal we are testing against, this may fail. In that
case, you can manually specify the information we need using
the following environment variables:
-
CABAL_PACKAGETESTS_GHCis the path to the GHC you compiled Cabal with -
CABAL_PACKAGETESTS_WITH_GHCis the path for the GHC you want to have Cabal use when running tests; i.e., you can change this to a different version of GHC to see how Cabal handles that version. If omitted, it defaults toCABAL_PACKAGETESTS_GHC. -
CABAL_PACKAGETESTS_DB_STACKis a PATH-style list of package database paths,clear,globalanduser. Each component of the list is interpreted the same way as Cabal's-package-dbflag. This list must contain the copy of Cabal you are planning to test against (as well as its transitive dependencies). By default, we guess that it is just the global and user database. However, if some of Cabal's dependencies were installed in a sandbox or other non-standard location, you will need to add it. Most commonly, if you are are using 'new-build' you'll need to add dist-newstyle/packagedb/ghc-VERSION to your database stack. (In most situations, the actual inplace database Cabal was registered into is automatically detected.)
There are a few extra options to toggle (e.g. CABAL_PACKAGETESTS_GHC_PKG
lets you explicitly set ghc-pkg in case Cabal can't autodetect it) but
the three above.
If you can successfully run the test suite, we'll print out examples of all of these values for you under "Environment".