patch: --enable-tests and --only-dependencies
andres at well-typed.com
Fri Feb 17 08:42:45 CET 2012
> On Sun, Feb 12, 2012 at 5:55 AM, Andres Löh <andres at well-typed.com> wrote:
>> Modular solver support for optional stanzas is done. Regarding your
>> patches, there's one aspect I don't understand:
>> In Distribution/Client/Install.hs:
>> configBenchmarks = toFlag False,
>> configTests = toFlag (TestStanzas `elem` stanzas)
>> You first had configBenchmarks analogous to configTests, then changed
>> it back. I don't fully understand why the two should be handled
>> differently. Could you please explain?
> These lines control whether a package is actually built with its tests
> and benchmarks. Although the resolver pulls in benchmark dependencies
> now, I didn't enable actually building the benchmarks because we
> wouldn't do anything with the results anyway.
> 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?
> I'm getting this warning in the modular solver:
>> Warning: Pattern match(es) are non-exhaustive
>> In an equation for `showFR':
>> Patterns not matched: _ (MalformedStanzaChoice _)
> It seems innocuous, but you would know better than I. Otherwise,
> everything looks good.
It's an internal error that shouldn't occur, but nevertheless a case I
missed. Thanks for spotting it. Now fixed.
> 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
Andres Löh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
More information about the cabal-devel