Testing with GHC 7.0 and 7.2 AND some improvements to package-tests #3251
Conversation
ezyang
force-pushed
the
cabal-travis
branch
2 times, most recently
from
3799d34 to
7007086
Compare
|
One downside with this patch is it increases the runtime of all tests as we repeatedly run the test suites from 7.0 and 7.2 for every built version. Perhaps we should have a dedicated 7.0/7.2 test ways, which build using some picked version of GHC (latest version?) and then test against 7.0/7.2. It wouldn't be necessary to even bother building test cabal-install, in this case. |
|
That'd be nicer, I think. Hopefully that doesn't make |
|
It looks like, to do this, I'm going to have to take the |
ezyang
changed the title
|
Yes, I think it's fine. Some small parts of the build script already live under |
I recently discovered that build-tools can be used to specify dependencies on internal executables (haskell#220). This means that we can make a nice improvement to the package-tests test suite: instead of manually building a Setup.hs script ourselves, we can add one to the Cabal file for Cabal, and have the test suite have a build-tools dependency on it. Perhaps the only objection to this is that the Cabal *library* now has an executable cabal-setup. Maybe with some buildable shenanigans we can make it so that we never build this executable unless the user asks for it, or the test suite is enabled. Alternately, cabal-setup is a generally handy executable to have around. Signed-off-by: Edward Z. Yang <[email protected]>
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.
UPDATE: This patch set now also has some refactorings to try to eliminate the LBI parsing nonsense, by using
build-toolsas per #220.