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

[<dahaverk rockwellcollins com>]

  We've been hand editing the IDL output to "fix" it.

   What a pain.

-Dave





Dan Kegel <dank@kegel.com> on 12/06/2002 09:34:34 AM

To:    dahaverk@rockwellcollins.com
cc:    michael@ximian.com, ml@knorke.in-berlin.de, orbit-list@gnome.org

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


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  ...