On Monday 16 of April 2012, Markus Mohrhard wrote:
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 :-)
...
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.
Sorry, but I assumed that was the practice, only recently broken by gbuild,
as sc exports many more than just 5 to 10 symbols. Why else are they
exported?
--
Lubos Lunak
l.lunak@suse.cz
Context
- Re: Automatic using ::rtl::OUString etc. (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.