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

[Dan Kegel <dank kegel com>]

I'm starting to think glib is a monster that needs to be
broken up into parts to make it easier to avoid bloat.

I agree, IDL compiler output should be portable, but
it doesn't seem like a showstopper unless people want
to hand-edit its output.
- Dan

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.?
> 
> Just a thought because the dependancy on "glib" was a really big "pain"
> when I built ORBit2 for my target.
> 
> 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.   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.
> 
> -Dave
> 
> 
> Michael Meeks <michael@ximian.com>@gnome.org on 10/02/2002 wrote:> 
> 
> Hi Dan,
> 
> On Tue, 2002-10-01 at 17:27, Dan Kegel wrote:
> 
>>I tried.  Cross-compiling was a pain; we contributed changes
>>to glib2 to help that.
> 
> 
>  Did they get folded in in the end ?
> 
> 
>>  Memory footprint was significantly
>>larger in glib2 than glib1, too.
> 
> 
>  Strange; of course - we use a fairly small sub-set of what glib can do;
> so there's possibly lots of room for improvement there. Perhaps it would
> be possible to have a configure switch to make a suitably small glib for
> you  ...