On 12/23/2013 06:44 PM, Matúš Kukan wrote:
On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:
* assume all LO-internal C++ implementations are ComponentContext-based
(i.e., use cppu::createSingleComponentFactory or
cppu::createOneInstanceComponentFactory rather than legacy
ServiceManager-based cppu::createSingleFactory or
cppu::createOneInstanceFactory); reaching this state is effectively an
easy hack
Yep, but maybe we don't need special easy hack for this.
So far, I was able to just remove the variables as unused.
I think it's easy to do as part of creating constructor function for
implementation.
Not sure what you mean here with "remove the variables as unused."
* implementations of non-single-instance services can be rewritten using
the new .component XML <implementation constructor="..." feature, cf.
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae3a0c8da50b36db395984637f5ad74d3b4887bc>
"Add .component <implementation constructor='...' feature"; this is
effectively an easy hack (note that service manager's
createInstanceWithArguments[andContext] no longer uses the
css.lang.XInitialization protocol on those implementations)
Hm, what does it mean, it no longer uses css.lang.XInitialization
protocol?
What to do about implementations inheriting from XInitialization?
I tried to convert such class in
https://gerrit.libreoffice.org/#/c/7186/
Yes, using the XInitialization protocol inside the constructor function
is a possibility here.
* idea is to set aside for every UNO service/singleton S two macros
LO_URE_CTOR_ENV_<S'> and LO_URE_CTOR_FUN_<S'>, and a macro
LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as
#if defined LO_URE_CURRENT_ENV && defined LO_URE_CTOR_ENV_<S'> \
&& defined LO_URE_CTOR_FUN<S'> && LO_URE_CURRENT_ENV ==
LO_URE_CTOR_ENV_<S'>
extern "C" cppu::ConstructorFunction_type LO_URE_CTOR_FUN<S'>;
Is not LO_URE_CTOR_ENV_<S'> redundant ?
We can just check for defined LO_URE_CTOR_FUN<S'> ?
Not in general.
** when compiling .cxx files for which it is known that the constructor
function for some S will be visible (which could e.g. be ~always the
case when compiling for a single big executable on Android/iOS), define
the LO_URE_CTOR_ENV_<S'> and LO_URE_CTOR_FUN_<S'> macros, either via -D
or via some strategically included header
Yes, so this needs some thought.
If I see correctly, there are already some typos in
15abebbde560e17413f17b16b8b2e9c1f31f01a5
like LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_xml_dot_sax_dot_FastParser
vs.
LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_comp_dot_extensions_dot_xml_dot_sax_dot_FastParser
Ach, sure, that quick-n-dirty include/osl/detail/component-defines.h is
just nonsense; it erroneously uses implementation names instead of
service names for those LO_URE_CTOR_{ENV,FUN}_<S'> macros.
Unfortunately I can't see how to avoid these macros, so I'll try to
generate include/osl/detail/component-defines.h early in build process.
Do you have another idea ?
Introducing include/osl/detail/component-defines.h was just a quick and
dirty hack to get this bootstrapped. Ultimately, we likely will not
want to have those
#if defined ANDROID || defined IOS //TODO
#include <osl/detail/component-defines.h>
#endif
lines in the generated .hpp files anyway, but I do not have any more
concrete ideas yet than that hand-waving "either via -D or via some
strategically included header" (same for the "the encoding of
environments (which are normally strings) in LO_URE_CURRENT_ENV and
LO_URE_CTOR_ENV_<S'> macros must be such that they can be used in the
preprocessor == expression above" issue).
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
