OK to merge the fw? libraries in framework?

[Mathias Bauer]

Am 08.02.2012 18:39, schrieb Michael Stahl:

> On 08/02/12 18:10, Tor Lillqvist wrote:
>> While trying to find easy ways to lower the number of (shared)
>> libraries, which is more or less on the critical path for the Android
>> work (the stupid run-time linker on Android has a low (from our
>> perverse perspective) limit on the number of shared libraries that can
>> be used at a time in a process), I started looking at the libraries
>> built in the "framework" module (mnemonically and self-documentingly
>> named fwe, fwi, fwk, fwl and fwm).
> 
> well, yes, obviously the fwe stands for "framework exports", fwi for
> "framework imports", fwk for "framework", fwl for "framework library"
> and "fwm" for "framework module"... no actually i just made that up ;)

Well, it's close. :-)

> 
>> Is there any fundamental problem in just shoving all the objects in
>> framework into one library (for instance the "fwk" one, or one renamed
>> to the perhaps more logical name "framework")?
> 
> AFAIK this module caused huge problems when gbuild-ifying on Windows
> (specifically because of the weird DLLPUBLIC things going on there), so
> in any case please test if it works on Windows before pushing such a change.

Indeed. You should be prepared to have fun. :-)

>> My guess is that the framework code might originally have gone into
>> just one shared library, anybody know the reason why it was split up
>> into five separate ones?

First we wanted to have two libraries: one for GUI related code that
needed to link against vcl, then another one that doesn't. That's "fwk"
and "fwl" (l = "light"). I don't remember the reason for creating fwm.
"fwi" is code that is commonly used amongst these three libraries. None
of these libraries exports any symbols that other libraries link against
- the few classes we wanted to export end up in "fwe".

> oh, one thing: probably some libs are required at startup and others
> not; so merging all in one brings a startup performance penalty (but
> even then 2 libs should be enough?)

Maybe fwm is a candidate (I don't know), I assume that fwk and fwl will
both be loaded in the startup phase.

All in all I don't think that keeping the libraries separated is
necessary, perhaps it's just confusing without providing any real
benefit. OTOH changing that needs some work and bears the risk of fixing
"interesting" build problems. But maybe you are lucky. ;-)

Besides that, I think that the performance gain by merging libraries is
highly overestimated and I doubt that it is worth the penalties you pay
for it (larger build times, eroding structures). I know that you have a
different opinion about that, but IMHO the time and effort could better
be invested into more componentization and keeping unnecessary code from
being loaded at startup time.

Also besides that (as Tor mentioned the Android port), I'm pretty sure
that nobody will ever want to use LibreOffice or any application of that
kind and size on Android devices - for several reasons. I'm working on
mobile apps right now (not only but also on Android), and so I'm bold
enough to claim some knowledge and expertise. Mobile apps need to be
designed to fit the platform requirements from scratch. This is not
limited to UI (though this is an important part), but also covers
workflow, security requirements and more.

Nevertheless the Android port is a wonderful engineering success and I
admire the effort and the creativity that went into it - from a hacker's
perspective, not from a potential users perspective. Of course I hope
that you will prove me wrong. :-)

Best regards,
Mathias