Re: TC_Bonobo_Unknown and --imodule

[Michael Meeks <michael ximian com>]

Hi Murray,

On Mon, 2002-02-25 at 16:32, Murray Cumming wrote:
> --imodule seems to generate a 'type library' instead of stubs/skels, so
> this seem to be as you intend it.

	Yes - quite. And this is intende to provide 'compiled idl' for
scripting bindings, including the Typecode data - which is _also_
available through dynamic linkage inside the libbonobo library.

> > 	Libbonobo contains within itself the stubs/skels for the C code 
> 
> But it doesn't install the headers for them, right?

	Yes it does. libbonobo/bonobo/Bonobo.h is installed.

> Given that it's the 'type library' that's installed, not the
> stubs/skels,

	Both are installed, the stubs/skels are linked into libbonobo-2.0.so

> what is the logic in making new stubs/skels include the
> 'type library' instead of any stubs/skels (whether previously generated
> or not).

	Well there are various differences, I forget the precice details, a lot
of extra 'statics' I think to make linkage more easy. We could do this
with a load of #defines though.

	Essentially for C++ the --imodule concept is redundant, we have no need
of C++ imodules, since we need only a single representation of the
interface data for scripting bindings, which doesn't incidentally use
-stubs or -skels, the imodule only includes the common module.

> Maybe I can get to the heart of this with a simpler question: How would
> a C coder, using libbonoboui, get a TC_Bonobo_Unknown?. It seems that
> he'd have to generate his own stubs/skels for Bonobo_Unknown.idl.

	using libbonoboui it's in libbonobo-2.so ( the TC, and skels and
stubs), and he should include bonobo/Bonobo.h to get the definition. He
should include Bonobo.idl in his IDL to get it, but no code will be
generated from that - only definitions.

	I hope that's clear.

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot