I like this. One area that would be helpful is the ability to run the tests when different compile flags are used. E.g., the HUnit tests have different behaviors when compiled with and without optimization; it would be very handy if I could automate the testing of both cases.

I don't believe that testing of multiple compile flags should be done inside Cabal. Instead, the arguments that are passed to `cabal configure' should also be used to build the test programs. This would allow a simple script, or a more complex build system, to handle the testing of both cases.

Richard

On 10-04-28 9:19 AM, Duncan Coutts wrote:
I have previously advocated a library interface as a detailed
testsuite interface (in addition to a lowest common denominator
interface of stdio+exitcode). That is a test stanza in a package
.cabal file would specify a module containing an entry point of the
right type (like main but using a more interesting type).

That way, cabal or any other tool could run the testsuite and produce
results in whatever format it likes.

I appreciate the elegance of this method, but it seems to me that it
requires dynamic loading, which is currently in a sorry state.

Actually it doesn't require dynamic loading. It just requires compiling
a stub program that imports the user's library and some test-runner
code. Cabal is good at doing that kind of thing already (eg Setup.hs
scripts).

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to