On Wed, Apr 18, 2012 at 09:33:51PM +0200, Lubos Lunak wrote: > This: > > On Monday 16 of April 2012, Markus Mohrhard wrote: > > 2012/4/16 Lubos Lunak <l.lu...@suse.cz>: > > > On Monday 16 of April 2012, Michael Meeks wrote: > > >> Oh - and finally (Lubos) I pushed an item to the ESC agenda to > > >> discuss whether we should be exposing tons of classes and their symbols > > >> in the product, just to make unit tests work :-) > > > > > > I assume this is about 69d46dd7a6adfffd71da055bb65108c80d27395f . > ... > > I was really annoyed by the fact that is was changed without at least > > asking and noticing the people who are affected by this change. There > > were good reasons to have the old behaviour and I spend some ours > > searching for a bug because I had to export a method for ucalc. IMHO > > such basic things should not be changed without noticing and > > discussing with the people who are directly working in that area.
If I got Markus right, his problem was not that he had to export a method, but that somebody changed unittests from static linking the library it tests to dynamic linking. I wholeheartly agree: A unittest should be allowed to see the internals of what it tests -- esp. as the "unit" is something way smaller that one of our (huge) libraries. If you care about the size of the build output(*), make the "unit" that the test tests able to be standalone, so that only that subset needs to be statically linked into the unittest. Thats a big harder, but something that would benefit the codebase as a whole (decoupling FTW etc.). Best, Bjoern (*) And those who are doing unconditioned debug build are just asking for huge build dirs -- nobody forces you to do so. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice