building a shadow test lib with all symbols? (was: Adding cppunit test to ucb.ucp.webdav)

Hi,

On Tue, Jan 19, 2016 at 03:38:32PM +0100, Stephan Bergmann wrote:
> There's two approaches to this ugly problem.  One is as above, with the
> downside of increasing the number of global symbols.  The other is to link a
> Library's objects directly into a CppunitTest library via
> gb_CppunitTest_use_library_objects.  The downside there is that you need
> typically duplicate all the Library_*.mk's gb_Library_set/use/whatever...
> calls as gb_CppunitTest_... calls in the CppunitTest_*.mk.
>
> Both approaches suck.

True. It was "Good Enough"(tm) for the time being "Back Then"[1], but we have
much more tests now. I wonder if we should consider something like creating a
second "shadow" library that exports all symbols, but doesnt get build by
default. Thus e.g. the stuff in sw/Library_sw.mk would create _two_ targets:

 ./instdir/program/libswlo.so
 ./workdir/LinkTarget/libswlo_tests.so

Only the first is made a depended upon by the module (and thus is build
unconditionally). This is the one we build now already, in a "production"
style. The second one is not build by default, until a CppunitTest doesnt
something like:

$(eval $(call gb_CppunitTest_use_test_libraries, sw_uwriter, sw))

which would link against ./workdir/LinkTarget/libswlo_tests.so (which exports
all symbols).

This would:

+ remove the need for duplicating all the build parameters in a bitrotting and
  error-prone fashion
+ remove the need for re-linking the same objects is loads of unittests again
  and again
+ remove the need to export symbols in production just for tests
+ remove the need to think about which set of object files I need to link in a
  unittest
- likely require us to build the targeted libs twice

The last point is a huge disadvantage -- but I wonder if it might be workable
these days, esp. since the static relinking of huge amounts of the same objects
in some 10-20 test libs as we are doing today does not come for free either[2].

Most importantly, once done the incremental cost in adding a new test both in
manpower, build time and discspace is lowered a lot with this.

Opinions?

Best,

Bjoern

[1] Admittedly that likely glorified past and a lame excuse.
[2] As a bonus, one _might_ consider things like building the _tests.so lib with
    DEBUG=T or somesuch by default. I am not entirely sure that would be a good
    idea though (as it would be testing code that is too different from what we
    ship, while not testing the code that we ship).