Re: ORBit2 "embedded", e.g. on Zaurus/IPAQ?

[Michael Meeks <michael ximian com>]

Hi David,

On Fri, 2002-12-06 at 15:18, dahaverk@rockwellcollins.com wrote:
> How about a configure switch to turn off glib dependancy and use some of
> the system provided functions (i.e. malloc) etc. directly.?

	Better to provide a wrapper, or to savage glib so that other people can
use that; we use some fairly chunky bits of glib - it's mainloop,
list/hash/allocator stuff, but then we don't use other biggish bits of
it I suppose.

> Just a thought because the dependancy on "glib" was a really big "pain"
> when I built ORBit2 for my target.

	Yes - it'd be nice to cut it down / include a stripped version in
'linc' perhaps.

> Another thing that we've discovered is that it would be great if the IDL
> compiler build could be turned off.  Part of the problem with the ORBit IDL
> that is generated is that it is uP Architecture specific.   The IDL that is
> generated should NOT be specific to a platform.

	You want to turn off building the IDL compiler ? or you want to turn
off building some IDL ? we shouldn't be shipping generated IDL files in
the ORBit2 package - if we are we should fix that.

>   Look at OMNI ORB as an
> example.  It can generate IDL on any platform that can be compiled by a
> cross compiler or directly on the host.

	The platform specific stuff is in the type libraries for performance -
types that have knowable size / alignment can have that information
cached, instead of doing (potentially) very costly runtime recursions to
calculate that.

	So - we need that data in there; currently we calculate it rather
trivially at idl-compile time. See orbit_find_c_alignment. Of course -
we could quite easily make this output a C string for the pre-processor
to munge; such as:

	'ORBIT_ALIGNOF_CORBA_SHORT' instead of '2' (or whatever),

	The problem is of course, is that things like unions need:

		for (; l; l = IDL_LIST (l).next) {
			IDL_tree member = IDL_MEMBER (IDL_LIST 
				(l).data).type_spec;

			c_align = MAX (c_align, orbit_find_c_align 
					(member));
		}

	So we'd need a (potentially massive) 'MAX' statement - which might blow
the (small) minds of many types of C pre-processor.

	Either way - it's trivial to do if you're interesed; we should prolly
add a flag to generate either the numeric or the string output, so we
have cross-compilable source.

	How does that sound ? [ looking forward to seeing the patch ;-].

	Regards,

		Michael.

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