You always have to list the other modules AFAIK, otherwise cabal sdist won't copy them! (Or at least I can't imagine why that wouldn't be the case when writing an application. ) On Sep 27, 2014 5:54 PM, "Mike Craig" 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

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/28b828bc806d8c1e66a06c3dceb92ae16... HTH, Doug On Sat, Sep 27, 2014 at 5:54 PM, Mike Craig 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