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