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

On 03/20/2012 11:02 PM, Tor Lillqvist wrote:
> commit 25d114eec4d451acdda1ddff4c8ed9d47ba6275f
> Author: Tor Lillqvist<tml@iki.fi>
> Date:   Tue Mar 20 23:18:55 2012 +0200
>
>      Initial experiments with static linking of (some) components / services
>
>      Start with the first service needed when running sc's filters_test:
>      the UniversalContentBroker. It might not be typical as ucb uses the
>      deprecated XSingleServiceFactory.
>
>      This commit is not at all a complete solution, far from it, just an
>      initial hack. Naturally once I come up with some generic enough way to
>      do the static linking the necessary macros etc will be added to some
>      general header.
>
>      The macro XSERVICEINFO_IMPL_1 (local to ucbhelper and ucb) is amended
>      so that it in the disable-dynamic-linking case also emits a function
>      whose assembler name equal contains the service name. This function
>      returns the XSingleServiceFactory for the service. Where the service
>      is instantiated we link directly to that function.
>
>      But probably this will be reworked a couple of times... Maybe it would
>      be better to simply have the service name specific entry point be a
>      pointer to the component's component_getFactory() function? Those all
>      have the same prototype.

I wonder two things:

1  Is this the right place to make changes, at the call sites 
instantiating UNO 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>_compoenent_getFactory 
in the one single executable?  Sounds simpler to me.

2  If it /is/ the right place, maybe, ultimately, we could make use of 
the fact that the new style service constructors are generated by 
cppumaker. -- Turn all UNO service definitions into new-style ones, 
change all call sites to use constructors (cf. 
<https://bugs.freedesktop.org/show_bug.cgi?id=46808> "[Easy Hack] Adapt 
UNO services to new-style"), 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).

Stephan