取决于工作台的测试 [英] Depend on test from bench

查看:73
本文介绍了取决于工作台的测试的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个测试项目

test-suite spec
  ...

benchmark bench
  build-depends:
    library-test-spec

。 ..我如何依靠基准测试套件代码?上面的方法不起作用,因为名称为 library-test-spec 的软件包不存在。

... how do I depend on the test-suite code from benchmark? The above doesn't work, because the package with name library-test-spec doesn't exist.

推荐答案

从Cabal 2.0开始,您可以将通用代码放在一个名为内部库的内部,测试套件和基准测试都可以依赖该内部库。根据文档

From Cabal 2.0 onwards, you can put the common code in a named "internal library" on which both the test suite and the benchmark can depend. According to the documentation:


Cabal 2.0和更高版本支持内部库,这是额外的
命名库(与通常的未命名库部分相对)。以
为例,假设您的测试套件需要访问库中的某些内部
模块,否则您不希望将其导出。
您可以将这些模块放在内部库中,主要的
库和测试套件的构建依赖于此内部库。

Cabal 2.0 and later support "internal libraries", which are extra named libraries (as opposed to the usual unnamed library section). For example, suppose that your test suite needs access to some internal modules in your library, which you do not otherwise want to export. You could put these modules in an internal library, which the main library and the test suite build-depends upon.

一个方便的内部库如下:

A convenience internal library looks like this:

library foo-internal
    exposed-modules: Foo.Internal
    build-depends: base

取决于它,您不需要放置版本约束,因为相同软件包的依赖关系隐式引用了相同的软件包实例。

When depending on it, you don't need to put version constraints because same-package dependencies implicitly refer to the same package instance.

使用内部库,您可以避免两次双重编译(如两次包含相同的源代码)并占用您的主库(就像您在其中放置通用代码一样)。

With internal libraries you can avoid both double compilation (as when you include the same sources twice) and encumbering your main library (as when you put the common code there).

请记住要包括 cabal-version:> = 2 .cabal 文件中。

Remember to include cabal-version: >=2 in your .cabal file.

这篇关于取决于工作台的测试的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆