Re: [Libreoffice-commits] .: Initial experiments with static linking of (some) components / services

> Why not rather leverage the existing .component file prefix
> attribute, combining all the component_getFactory functions into the one
> single executable (disambiguating them via prefixes), and tell the UNO
> shared library loader to not bother with multiple libs, but just call the
> relevant <prefix>_component_getFactory in the one single executable?

Looking it up with dlsym()? Yeah, that's an obvious idea, and I have
considered it. I just wanted first to try to see how intrusive the
changes to the call sites might get if one uses some preprocessor
macro magic to turn the various kinds of createInstance*() call sites
into direct calls. (And indeed, the result ends up a bit ugly. I
certainly don't want to make the code any harder to read by
introducing complex preprocessor macros.)

What would be really cool would be to write a clang plugin that would
automagically turn createInstance*() calls into the relevant static
linkage using code... I.e. something like "when you notice that the
createInstance*() method of an object of type X is called, and
parameter N is an OUString constructor with a string literal argument,
instead generate code as follows..."

Code transformations like this is one intended use of clang's plug-in
mechanism, isn't it? But clang plug-in writing doesn't really seem to
be documented or for end-(user-)developers yet I guess...

>  Sounds simpler to me.

Yeah... It would be a bit slower, but just a tiny bit. Also, then we
will have to make sure that all these *_component_getFactory()
functions that will be dynamically looked up get linked into the
executable. And only those that are actually used... Ideally one would
want to use the -dead_strip option to include only code actually used
(or marked with the "used" attribute) in the executable, too, and how
all this interacts needs to be experimented with...

Alternatively one could use a hash table from service names to
foo_component_getFactory() function pointers. That would take care of
the problem how to make sure just what's potentially needed at
run-time is linked in. Enumerating which services are used by some app
providing a certain functionality shouldn't be too hard.

> Turn all UNO service definitions into new-style ones, change all call sites
> to use constructors ([...]), and in the DISABLE_DYNLOADING case let cppumaker
> emit constructors that somehow directly call the implementation class (which
> would require some sort of mapping, so that cppumaker could know the name of
> the C++ implementation class to call).

That sounds promising, too.

--tml