Hi Thomas.
Actually, since we won't be running test suites automatically (until the next release of Cabal), they should probably be disabled, too.
I'm still not sure if I understand this. If you enable tests and benchmarks, shouldn't they then at least be installed? Whereas if you pull in the dependencies, but then don't build them, what did you pull in the dependencies for?
The dependencies are pulled in for the case where you do 'cabal install --enable-benchmarks --only-dependencies' to quickly pull in all the deps for a project you are developing.
Yes, I was under the mistaken assumption that tests and benchmarks are installed, too.
I'm working on the patch for Cabal that we need in order to run tests automatically. Hopefully, I'll send it to the list this afternoon. Then, after the cabal-install release, we can turn automatic tests back on.
Got it. Is it actually wise to run tests automatically and fail the installation if tests fail? Don't you think there might be users who'd like to have the test suites installed, be able to run them in their own time, and look closely at the results, even if some of them might fail?
Now I understand what you mean. However: tests and benchmarks never get installed. They never live outside the build directory, so if they don't get run before install takes place, they'll be deleted with the build directory. This is why I don't know what we'd do with benchmarks if we built them: we could run them, but what would we do with the results?
So, let me ask whether it's really the right decision that tests and benchmarks are never installed? I agree that they're *mainly* useful for development, but aren't there cases where one might want to have tests and benchmarks be run on a client machines, as part of debugging a problem? Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com