A common situation is to setup a Cabal package with a library and a test-suite for the library, e.g. for package 'foo', one might try:
This will not do what you want: in particular, when Foo/Test.hs is compiled, it will automatically pick up the source directory of the library (which is by default '.') and compile against Foo.hs directly, rather than pick up the Foo exported by the inplace installed 'foo' library.
Now, this might not be so bad, except occasionally you'll get mysterious type errors like:
Couldn't match expected type `foo-0.1.0.0:Foo.Program'
with actual type `Foo.Program'
Ambiguous occurrence `F'
It could refer to either `Foo.F',
imported from `Foo' at Test.hs:1:1-10
(and originally defined in `Bar')
or `Bar.F', imported from `Bar' at Test.hs:2:1-10
What's going on here? One way to make the bug manifest is when you depend on any source files which need a preprocessor run to generate the actual HS file (for example, a Happy or Alex file, or an hsc or c2hs file). Because those modules are not listed as "other-modules", Cabal will not build them, and then when GHC actually tries to build the original file, it will pick up the inplace installed library. You can probably also get this bug to show up in other cases too.
The workaround is to force the test-suite to use a different source directory, so it doesn't pick up library sources; Cabal should warn about that at least. But maybe there's a way to mask out exposed-modules from the test-suite compilation so we can have both of the source directories be the same.
A sample package which displays this problem is available here: http://web.mit.edu/~ezyang/Public/libtest-0.1.0.0.tar.gz
I've fixed the preprocessor issue for test suites and benchmarks in #1087.
I believe the issue is that when we compile using --make (which we do) GHC happily picks up any dependencies it can find on its search path. I can see us going one of two ways:
Duncan and I talked about this a little, and I think Duncan claimed that (2) (tracing the dependencies manually) would be highly nontrivial and also inefficient, and it would just be better to keep asking people to explicitly specify modules in the Cabal file.
I'm fine with that. We should then try to design a mechanism that enforces that all dependencies are listed. Here's a strawman: symlink copy all the source files to a new directory before building. It would be nice to do this in such a way that we don't trigger unnecessary recompilation by GHC. A nice side-effect of this is that doing distributed compiles will be easier, as building outside the source tree will make sure that packages fully specify their dependencies (and are thus hermetic).
As it happens, I just hit this with Alex + Happy, and happily (hee), using the suggested workaround (forcing the test-suite into a different directory) solved it.
So, this would get fixed if we fix #2982 (basically, you'd have to explicitly list the duplicate modules to suppress the warning, making it obvious that the library "shows up twice"), so I'm going to close this as a dupe of that.