quickcheck and ghci

Nick Smallbone nick.smallbone at gmail.com
Tue Apr 26 20:01:35 BST 2011


Hi all,

On 26 April 2011 14:10, Marco Túlio Gontijo e Silva <marcot at debian.org> wrote:
> Hi.
>
> Excerpts from Koen Claessen's message of Ter Abr 26 04:39:15 -0300 2011:
>> The dependency on TH was introduced when we added support for
>> "QuickCheck all properties in this module" functionality.
>>
>> So, the TH dependency is restricted to only one QuickCheck module,
>> which you do not have to use if you do not want to. I am not sure what
>> the right way is to express this dependency in cabal (or debian!), but
>> I am sure that Nick Smallbone does (CC-ed).

Indeed, the TH dependency is only in Test.QuickCheck.All, which is
supposed to be optional. However, our .cabal file always built this
module if we were using a recent GHC, which is the wrong thing if some
architectures don't have TH.

> You can include a Cabal flag for this to make it possible to disable it while
> building the Cabal package.  This would also make it easy to disable it on the
> Debian package.

This is what I've done for now. The flag is templateHaskell and exists
in QC 2.4.1.1.

> A second approach is to split this module in another package, for example,
> quickcheck-th.  The advantage is that, with the first approach, we either
> remove this module from Debian or keep the undesired dependency in TH.  With
> the second approach, the module can be kept in Debian without requiring the
> dependency in TH for the quickcheck package.

With this new flag, won't QC depend on TH only on architectures where
TH is available? Setup.lhs will set the templateHaskell flag if the
template-haskell package exists and clear the flag otherwise, and it
only issues a Build-depends: template-haskell if the flag is true, so
it'll all work out automatically, won't it?

Nick



More information about the QuickCheck mailing list