[Libreoffice] [GSoC] library merging

[Caolán McNamara]

On Fri, 2011-06-24 at 15:16 +0100, Michael Meeks wrote:
> 	Hey - let me explain some more; (I had hoped Matus would be at the TSC
> to explain but ...), anyhow, for the wider benefit:
> 
> 	* having fixed symbol names like component_doFoo means we cannot
> 	  easily chop and change and move components from one library to
> 	  another.
> 		=> ergo adding a custom prefix="foo" and having
> 		   foo_component_doFoo methods means we can move code
> 		   around more easily.

Hmm, yeah, the passive uno registration stuff as it stood didn't really
help a lot here does it. That just removed the need to dlopen libs at
registration time to find out what's in it, component_getFactory was
still the required entry point to actually get at them them.

I never really bothered to look at
component_getImplementationEnvironment but I wonder if that could be
elided in 90% of cases. i.e. that all merged libraries are going to have
the same body there anyway.

So instead of a "prefix" tag that's always added to both
component_getImplementationEnvironment and component_getFactory, always
use component_getImplementationEnvironment, and just drop the duplicates
of those when libs are merged, and then instead of dlsyming "prefix" +
"component_getFactory" just, say, rename the current "prefix" thing to
be "getFactory" name which defaults to component_getFactory and dlsym
the "getFactory" name. Though I suppose that makes it a little more
difficult to undo a merge trivially.

> 	The question then is, which libraries should we be merging, which
> underlies Matus' (sadly without a .txt extension so the attachment
> cannot easily be viewed) 'libraries' list showing which of our libraries
> are loaded by all five components, and thus which could/should be merged
> into a single big firefox-style library [ at least that is the idea ].

Well, as a low-hanging fruit I suggest that all the *.uno.so in the list
that appear in the ure/lib install dir get merged together anyway. Those
are all typically very small, too small really, libraries.
libi18npaperlo.so and libi18nisolang1gcc3.so are too small too really.

I wonder though about the developer rebuild-time hit if the bigger ones
are linked into a mega-lib, sw and sc and svx are pretty big
thumb-twiddlers when linking ?

Some of these things are of course dlopened outside the uno-code path as
well, e.g. libdesktop_detectorlo IIRC

C.