[Libreoffice] [GSoC] library merging
Caolán McNamara
caolanm at redhat.com
Fri Jun 24 08:08:01 PDT 2011
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.
More information about the LibreOffice
mailing list