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).
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
