如何减少.cabal文件的构建依赖字段中的重复？ [英] How to reduce duplication in the build-depends fields of a .cabal file?

问题描述

这是一个.cabal文件：

 名称：myprogram 
版本：0.1 
  -  blah blah blah 
 Cabal-version：> = 1.9.2 
 
可执行程序myprogram 
 HS-source-dirs：src 
 Main-is：Main.hs 
 Build-depends：attoparsec == 0.10。*，
 base == 4.3。*，
  - 很长的软件包列表
 
测试套件测试
 HS-source-dirs：test，src 
类型：exitcode-stdio-1.0 
 Main-is：Main.hs 
 Build-depends：attoparsec == 0.10。*，
 base == 4.3。*，
  - 很长的软件包列表
 QuickCheck == 2.4。* 
  

有没有什么办法可以用测试套件的与可执行文件相同，加上QuickCheck代替构建依赖包的长列表？

编辑：版本信息。

• cabal-dev 0.9


• cabal-install 0.10.2


• Cabal库1.10.2.0
  
• GHC 7.0.4


• Haskell平台2011.4.0.0

解决方案

是否有任何方法可以替换长列表的依赖包测试套件的与可执行文件相同，加上QuickCheck？

不是我所知道的。但是，有一种方法只需将 build-depends 包列出一次，方法是将您的项目构建为三个目标：

1. 一个包含所有代码的库，并且需要很长的构建依赖列表。


2. 一个只包含一个文件的可执行文件，
   
3. 一个测试套件，它依赖于上面的库以及您正在使用的测试包。

也许这种方法是indygemma的答案提出的，但是Cabal文件提出的方案并不能完全实现，正如Norman Ramsey在评论中指出的那样。这是您在Cabal文件中需要的主要观点。有关适用于我的完整示例，您可以查看此Cabal文件。

 名称：my-program 
版本：... 
 
图书馆
 hs-source-dirs：src-lib 
 build-depends：base，containers，... 
 exposed-modules：My.Program.Main，... 
 
可执行文件my-program 
 hs-source-dirs：src -exec 
 main-is：my-program.hs 
构建依赖：base，my-program 
 
测试套件测试
类型：exitcode-stdio-1.0 
 hs-source-dirs：src-test 
 main-is：tests.hs 
 other-modules ：... 
 build-depends：base，my-program，test-framework，... 
  

要点：

• 这三个目标有三个独立的源目录。这对于在构建其他目标时停止GHC重新编译库文件是必需的。

所有应用程序代码都在库中。可执行文件只是一个包装，就像这样：



  import My.Program.Main（realMain）
 main = realMain 
  




• 该库公开了测试所需的所有模块。

>

最后一点突出显示了这种方法的缺点：您最终不得不公开内部模块。这种方法的主要优点是在Cabal文件中重复性较少，更重要的是，在构建过程中重复性较低：库代码将只构建一次，然后链接到可执行文件和测试套件。

Here's a .cabal file:

Name:                myprogram
Version:             0.1
-- blah blah blah
Cabal-version:       >=1.9.2

Executable myprogram
  HS-source-dirs:       src
  Main-is:              Main.hs
  Build-depends:        attoparsec == 0.10.*,
                        base == 4.3.*,
                        -- long long list of packages

Test-Suite test
  HS-source-dirs:       test, src
  Type:                 exitcode-stdio-1.0
  Main-is:              Main.hs
  Build-depends:        attoparsec == 0.10.*,
                        base == 4.3.*,
                        -- long long list of packages
                        QuickCheck == 2.4.*

Is there any way I can replace the long list of build-depends packages for the test suite with "same as for the executable, plus QuickCheck"?

Edit: version information.

• cabal-dev 0.9
• cabal-install 0.10.2
• Cabal library 1.10.2.0
• GHC 7.0.4
• Haskell Platform 2011.4.0.0

解决方案

Is there any way I can replace the long list of build-depends packages for the test suite with "same as for the executable, plus QuickCheck"?

Not that I know of. However, there is a way to only mention the list of build-depends packages once, by structuring your project into three targets:

1. a library that contains all your code, and needs the long build-depends list.
2. an executable that consists of only one file, and depends on base and the library from above.
3. a test-suite that depends on the library from above, and the testing packages you are using.

Maybe this approach is what indygemma's answer proposes, but the Cabal file proposed there will not quite achieve it, as Norman Ramsey points out in a comment. Here's the main points of what you need in a Cabal file. For a full example that works for me, you can look at this Cabal file.

name: my-program
version: ...

library
  hs-source-dirs: src-lib
  build-depends: base, containers, ...
  exposed-modules: My.Program.Main, ...

executable my-program
  hs-source-dirs: src-exec
  main-is: my-program.hs
  Build-depends: base, my-program

test-suite tests
  type: exitcode-stdio-1.0
  hs-source-dirs: src-test
  main-is: tests.hs
  other-modules: ...
  build-depends: base, my-program, test-framework, ...

Important points:

• There are three separate source directories for the three targets. This is necessary to stop GHC from recompiling library files when building the other targets.

• All of the application code is in the library. The executable is just a wrapper, like this:

  import My.Program.Main (realMain)
  main = realMain
  

• The library exposes all modules that are necessary for testing.

The last point highlights the drawback of this approach: You end up having to expose internal modules. The main benefit of this approach is that you have less duplication in the Cabal file, and maybe more importantly, less duplication in the build process: The library code will be built only once, and then linked into both the executable and the test-suite.

这篇关于如何减少.cabal文件的构建依赖字段中的重复？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！