Re: namespace / typing thrash ...

2012/4/16 Lubos Lunak <l.lunak@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 .
>
>  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.

But not for ucalc, uimpress and swdoc_test. These three allowed to
write test without exporting symbols which is a good idea. If one
needs a method in one of the other tests he needs to export them but I
think in calc we only exported 5 to 10 in one year for the other test
but we will need to export a lot more for ucalc.

> 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.

As mentionend above this is only for one test in sc, sw and sd.

> 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.

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.