namespace / typing thrash ...

[Lubos Lunak]

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 .

 My motivation for the change was limiting the size of the debug build, which 
is so huge that just writing and reading those .o files takes a noticeable 
time. It is made even worse by the fact that make+gbuild order build commands 
so that allmost all compiles go first and linking goes last, which means all 
those .o's get written, then the early .o's get evicted from caches (even on 
a 12G RAM machine), then linking starts, which first reads those early .o's 
again and evicts later .o's, which then get read again. Just this I/O shuffle 
is 20% of my full build time. So I now usually build with workdir/+solver/ in 
zram, where it fits, but it still costs me 6G RAM. But those huge unittests 
libs weren't a happy sight in general anyway (e.g. Petr has had already 
failed LO builds in the buildservice because of them being too large).

 And it's not exactly tons of symbols, and even before my change there were 
many symbols selectively made exported, so I assumed that the tests used to 
work this way already before and had gotten broken e.g. by the gbuild 
conversion. I don't think there's a perfect solution. Making the release 
build slower because of a debug build is kind of lame, but I don't think the 
number of symbols makes any noticeable difference. Including whole copies of 
sc/sd/sw libs directly into unittest libs could also make the size explode if 
we get more unittests. We could possibly build debug builds with visibility 
disabled and link, and build release builds with object inclusion, but I 
don't know if that is worth it.

-- 
 Lubos Lunak
 l.lunak at suse.cz