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

Bjoern Michaelsen bjoern.michaelsen at
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"[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/ 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
something like:

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

which would link against ./workdir/LinkTarget/ (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
- 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.




[1] Admittedly that likely glorified past and a lame excuse.
[2] As a bonus, one _might_ consider things like building the 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 mailing list