building a shadow test lib with all symbols? (was: Adding cppunit test to ucb.ucp.webdav)
bjoern.michaelsen at canonical.com
Tue Jan 19 14:46:21 PST 2016
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", 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:
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
$(eval $(call gb_CppunitTest_use_test_libraries, sw_uwriter, sw))
which would link against ./workdir/LinkTarget/libswlo_tests.so (which exports
+ remove the need for duplicating all the build parameters in a bitrotting and
+ remove the need for re-linking the same objects is loads of unittests 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
- 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.
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.
 Admittedly that likely glorified past and a lame excuse.
 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).
More information about the LibreOffice