support test library

[PierreVDL]

Only one library can be defined in a single Cabal file.
According to #2716 it is a fundamental design decision.

As a developer, I want to expose additional functionality for test purposes only.
For example, I want to expose generators of test data defined in a package
such that it can be used by packages that use that test data (e.g. for QuickCheck).

One way to deal with this cabal limitation, is the usage of flags: See e.g.
PackageStructure.zip
This has however some unwanted side effects.
Among others, understanding the packages' builds becomes more complicated,
one gets discussions whether the program that is shipped is the program that is tested,
and the generators are also included in the coverage reports.

Could support for an additional test library be added?

[ezyang]

Does #4206 encompass this? If so, please pipe in on that thread supporting the feature!

[23Skidoo]

Don't internal libraries available in current master (1.25+) solve your problems? See http://cabal.readthedocs.io/en/latest/developing-packages.html#library

[PierreVDL]

#4206 does encompass this.
Yet #4206 encompasses more than strictly needed by me.

[PierreVDL]

internal libraries don't solve my problem: I want to use the test-library in the test code of other packages.

[ezyang]

@PierreVDL Is there a substantially simpler version of #4206 that solves your problem? #4206 is unlikely to get solved in the near future.

[PierreVDL]

A simpler solution could be: introduce a keyword like test-library or library test.
For me, the constraint that this keyword might only be used when a library is present is acceptable.

When a test library is not declared, exactly the same behaviour as currently is implemented will be obtained. In particular, when I include the package / *.cabal file in another package to build a test
the normal library will be used.

However, when a package / *.cabal file declares such a test library besides the normal library, then
when I include the package / *.cabal file in another package to build a library, benchmark, or executable I get the normal library.
Yet, when I include the package / *.cabal file in another package to build a test, I get the test library.
In this way additional test functionality related to a package can be shared with packages that use that package.

This proposal makes building and testing explicitly two different activities for which different libraries might be needed.

[PierreVDL]

I realized that another choice is possible:
so we have the normal functionality and the test functionality we would like to expose.

We can make two libraries:
one that contains the normal functionality and
another that contains both the normal and the test functionality.

However, we can also make two libraries as follows:
one that contains the normal functionality and
another that contains only the test functionality (and depends on the other library).

In the latter case, we can make the inclusion of the test library in other packages explicit, instead implicitly based on the test / library / benchmark / executable context.

[ezyang]

Based on your previous comments, possibly the most expedient thing to do from an implementation perspective is to add a condition (maybe a special flag?) which is true when the top level goal is a test. But there have been philosophical objections to letting the APIs of packages change this way (which is why, for example, you can't demand a dependency have a flag set a certain way).

[23Skidoo]

Closing as a duplicate of #4206. For now, a workaround is to use a separate package.