Warn when a test-suite / executable / benchmark also builds the library code?

[mgsloan]

It's not so uncommon to see test-suite / executable / benchmark stanzas which don't depend on the library, and instead compile it when they are built. This tends to happens when there isn't an hs-source-dirs on both the library and the other stanza.

Why is it good to avoid this?

• Reduces redundant compilation
• Allows the --coverage support to correctly distinguish library code and test code (see Detect when hpc report (--coverage) is giving a trivial "100%" #1009)

I was hoping that we could catch this case just by checking if the build-depends of the non-library stanza includes the library. However, it looks like it's not an error to have it both depend on the library and build all the library's source files. So, the implementation of this would need to detect when the hs-source-dirs of the auxiliary stanza overlaps with the hs-source-dirs of the library.

Maybe there are legitimate cases for having these auxiliary stanzas also build the main library code? The only one I can think of is that it might be desirable for a test or benchmark to rebuild the library code with a different set of flags.

[snoyberg]

The only one I can think of is that it might be desirable for a test or benchmark to rebuild the library code with a different set of flags.

This is especially true when using CPP to expose new identifiers for the test suite. I think this change is too invasive for stack to make, though perhaps if we add a lint option in the future, this could be part of it.

[mgsloan]

Makes sense! I've closed this in favor of the issue about the lint command, and added a comment to #1009. The message to the user will mention that this case might be the cause.

[mgsloan]

Another common case I just thought of is that when the test-suite also builds the library, it can access non exposed modules.

[soenkehahn]

Some other cases where the test suite doesn't depend on the library:

• Sometimes it's desirable to build the test-suite with -O0 (and the production code with -O1 or similar). (Which is an instance of the "different flags" scenario mentioned above.)
• Sometimes a package only consists of executables and a test suite. A library doesn't exist.

[mgsloan]

Yes, this is an unfortunate compromise. We could work around https://ghc.haskell.org/trac/ghc/ticket/1853 , but it would require a lot of hacks:

• Build each of the test components separately, so that mix files can be moved out of the way between builds
• Manually munging the tix files to know about the folders the mix files got moved to. We're already doing some tix file munging, but this'd be a bit more substantial..

My preference is to fix it for 8.0 rather than do anything complicated in stack to fix this.

[arianvp]

Another common case I just thought of is that when the test-suite also builds the library, it can access non exposed modules.

Cabal now has a notion of internal libraries in cabal files which I think could be used to circumvent this issue. Your test suite and your library can both depend on the internal library

[epoberezkin]

Could you please share some example hpack package.yaml for the package that contains an executable, a library and the test that tests this library? However I am moving things around, the stack tests --coverage still rebuilds the library and does not generate coverage... Thank you.