Just to comment on your "have to declare every dependency and version twice" point. You don't need to have the version information listed in the test section, since you've already defined your constraints in the library section. You can also list your package as a dependency for the test suite, which can remove a lot of repeated dependencies (although that depends very-much on what sort of interface your library exposes).

So you can get away with

name: bob

Library

Build-Depends:

base >= 3, conduit < 0.99, pipes > 47.2, text == 0.1.2.3
...

Test-Suite test-bob1

Build-Depends:

base, bob, text, tasty, tasty-hunit == 0.9.*
...

Test-Suite test-bob2

Build-Depends:

base, bob, text, conduit
...

Or at least that's my understanding/how I use it - e.g. https://bitbucket.org/doug_burke/swish/src/28b828bc806d8c1e66a06c3dceb92ae165bfe543/swish.cabal?at=default

HTH,

Doug

On Sat, Sep 27, 2014 at 5:54 PM, Mike Craig <mkscrg@gmail.com> wrote:

Hey all, I'm trying to setup an executable cabal project, the options for cabal-based testing seem poor. I poked around for discussions of this but didn't find much. My apologies if I'm beating a dead horse.

The current options, as I understand them, are

1. Split code into library, executable, and test-suite. This gets you single compilation but you have to list every source file in the library's exposed/other-modules sections.
2. Split code into executable and test-suite. You don't have to list the source files, but you get double compilation and you have to declare every dependency (and version!) twice.

Am I missing a third (better) option, or is this the state of things?

--
Mike Craig

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe