Hi Hector,
Since the InterfaceInfoManager is a private detail of the Mozilla implementation, you really have no other option than to build your component along side the Mozilla source. The XPCOM reflection API is not frozen, and therefore it may change in the future. This means that your component may only work with the version of Mozilla that you compile it against.
If you only use frozen interfaces, as found in the Gecko SDK, then your component will be compatible with future versions of Mozilla.
You're not alone in needing to use unfrozen interfaces. We still have much work to do to provide a more complete SDK.
-Darin
Hector Rivas Gandara wrote:
Hi,
I'm a newbie with XPCOM. I'm developting a XPCOM binding for Erlang, so I will have a lot of questions for this list :)
The firsts ones are about the mozilla source code and component compiling:
I want to isolate my code from the mozilla source, defining some paths that pointto mozilla and xpcom headers and libraries in a Makefile, so the user only needs the headers and the compiled library (libxpcom.so). I don't want to deploy my code into the mozilla source tree, like plXPCOM or PyXPCOM do.
Actually, to build a XPCOM binding (that uses the XPCOM internals like InterfaceInfoManager), I need a lot of c++ headers from public xpidl (p.e. mozilla/xpcom/reflect/xptinfo/public/nsIInterfaceInfoManager.idl), that are not included in the Gecko SDK, so I have to configure and compile ALL the mozilla source code (and, consequently GLib, GTK, libIDL, etc, etc, etc...).
Is there any way to get just the headers that I need? Something like an Extended Gecko SDK.
Thank you very much. --
Saudos H�ctor
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
