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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
