orbitcpp-list

[orbitcpp-list] Understanding orbit-c++

[Dave S. <da...@ja...>]

Greetings again...

Well, I managed to get CVS ORBit & CVS ORBit-cpp working in a "safe" directory. IDL compiler seems to work
and everything is happy. I can run the tests, tho the tests/everything-typedef doesn't want to build for
some reason. At any rate, most of the stuff appears to work.

Now I'm starting to wonder how this binding/wrapper works...are there any documents explaining your approach
and/or theories?

I'm a C++ person and would prefer to _not_ try and write bonobo components in C (unlike certain other parties
on GNOME) :) My next question is this: what are the dependencies of ORBit and how hard will it be to setup
once bonobo starts getting widespread use? I want to make my code as easy as possible to build, if people
wish to do so.

I guess that's all the questions I can think of for now. :) 

D.

Re: [orbitcpp-list] Understanding orbit-c++

[Andreas K. <ak...@ix...>]

On Tue, Jul 25, 2000 at 08:22:58PM -0500, Dave Smith wrote:
> 
> Greetings again...
> 
> Well, I managed to get CVS ORBit & CVS ORBit-cpp working in a "safe" directory. IDL compiler seems to work
> and everything is happy. I can run the tests, tho the tests/everything-typedef doesn't want to build for
> some reason. At any rate, most of the stuff appears to work.

Yup, everything-typedef fails for some reason for me, too. I'll look into
this when the next exams are over (Aug 3). 

Important: Did you also install glib into your safe directory (would be 
good), and does ORBit-C++ use -I/your/gnome/directory when compiling 
(would be bad)?

> 
> Now I'm starting to wonder how this binding/wrapper works...are there any documents explaining your approach
> and/or theories?

see the HACKING file.

> I'm a C++ person and would prefer to _not_ try and write bonobo components in C (unlike certain other parties
> on GNOME) :) My next question is this: what are the dependencies of ORBit and how hard will it be to setup
> once bonobo starts getting widespread use? I want to make my code as easy as possible to build, if people
> wish to do so.

ORBit only depends on glib. ORBit-C++ does not add any dependency.
A working STL is only necessary for building the IDL compiler.
ORBit-C++ should not, in its final state, be any harder to set up
than ORBit itself.

> why do I have to run the compiler twice?

because by doing 

orbit-idl -lc++ blah.idl

you generate classes that wrap the stuff you generate by doing

orbit-idl -lc blah.idl.

bye
andy

-- 
Don't innovate, intimidate.

Re: [orbitcpp-list] Understanding orbit-c++

[Adam Y. <ay...@fo...>]

Well, I'm still stuck in the config stage, although I am learning a
hellofalot about how CVS, autogen, and gnome development are organized.  

So to try to summarize:

pre) in ~/.bashrc

export CERTIFIED_GNOMIE="Getting There"


1) Log in to Gnome CVS.
2) checkout (or update) glib and ORbit
3) autogen, make and install glib into development directory (I chose
/usr/local/devel/  side question does a trailing slash have any effect
on autogen/ configure)
cd glib
./autogen.sh -prefix /usr/local/devel/
make
make install

4)autogen, make and install ORBit into development directory  

cd ../ORBit
./autogen.sh -prefix /usr/local/devel/
make
make install

5)Get orbitt cpp from CVS

6)and finally for orbitcpp

cd ../orbitcpp
./autogen.sh -prefix /usr/local/devel/
make

This is the step thaht fails for me.  I get a build error in
orbitcpp_tools looking MemHow.  I know this is in 
PREFIX/include/orb/allocators.h

But I don't see a -I/usr/local/devel/include in the compile command.

Note that I also tried it with 
--with-orbit-prefix=/usr/local/devel


Possily related question:

IN the configure output I found this snippet:
*** Your copy of orbit-idl doesn't support --backenddir
*** This means that you will have to install the C++ idl compiler
back-end
*** (with 'make install') before you can build the tests.

Is this indicitave of it not finding the right ORBit code?

THanks to all of you for your patience.

Adam


> Important: Did you also install glib into your safe directory (would be
> good), and does ORBit-C++ use -I/your/gnome/directory when compiling
> (would be bad)?

Re: [orbitcpp-list] Understanding orbit-c++

[Phil D. <ph...@us...>]

Adam Young wrote:
> 

[snip...]

> 3) autogen, make and install glib into development directory (I chose
> /usr/local/devel/  side question does a trailing slash have any effect
> on autogen/ configure)

I don't think so. 


[snip...]

> 6)and finally for orbitcpp
> 
> cd ../orbitcpp
> ./autogen.sh -prefix /usr/local/devel/
> make
> 
> This is the step thaht fails for me.  I get a build error in
> orbitcpp_tools looking MemHow.  I know this is in
> PREFIX/include/orb/allocators.h
> 
> But I don't see a -I/usr/local/devel/include in the compile command.
> 

Could you mail the compile command? - cheers.


> Note that I also tried it with
> --with-orbit-prefix=/usr/local/devel
> 
> Possily related question:
> 
> IN the configure output I found this snippet:
> *** Your copy of orbit-idl doesn't support --backenddir
> *** This means that you will have to install the C++ idl compiler
> back-end
> *** (with 'make install') before you can build the tests.
> 
> Is this indicitave of it not finding the right ORBit code?
> 

Yes! The CVS head version of ORBit definitely has --with-orbit-prefix.

Hmmm... 
<gets off his arse and attempts to build ORBit/orbitcpp from scratch>

I may have the answer: 
I've just attempted to do this on a fresh redhat 6.2 system with helix
gnome, and helix gnome comes with ORBit-0.5.2. The problem is that the
ORBit in CVS head is fixed at 0.5.1 for some god-only-knows reason. This
means that the configure script gets confused (and prints out a verbose
warning msg), but ultimately doesn't stick the correct include and lib
directives into the makefiles.

I fixed this by editing the ORBIT_MICRO_VERSION variable in ORBit
configure.in from 1 to 2, which fixed the problem.

Does this help?

> THanks to all of you for your patience.
> 

You're welcome; - thanks for your perserverance!

Cheers,

Phil.

Re: [orbitcpp-list] Understanding orbit-c++

[Adam Y. <ay...@fo...>]

THis is the compile command that fails.

c++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I/usr/local/lib/glib/include
-I/usr/local/include -I/usr/include -g -O0 -Wall
-Wp,-MD,.deps/orbitcpp_tools.pp -c orbitcpp_tools.cc  -fPIC -DPIC -o
.libs/orbitcpp_tools.lo


Is --with-orbit-prefix=/usr/local/devel required?  I'm a little unclear
through all the emails.  Are there other params to configure that are
required (for ORBit to find glib, etc)

BTW 
I'm running:
 gcc --version 
2.95.2

I get a lot of these :
configure.in:93: warning: AC_TRY_RUN called without default to allow
cross compiling


> > IN the configure output I found this snippet:
> > *** Your copy of orbit-idl doesn't support --backenddir
> > *** This means that you will have to install the C++ idl compiler
> > back-end
> > *** (with 'make install') before you can build the tests.
> >
> > Is this indicitave of it not finding the right ORBit code?
> >
> 
> Yes! The CVS head version of ORBit definitely has --with-orbit-prefix.
> 
> Hmmm...
> <gets off his arse and attempts to build ORBit/orbitcpp from scratch>
> 
> I may have the answer:
> I've just attempted to do this on a fresh redhat 6.2 system with helix
> gnome, and helix gnome comes with ORBit-0.5.2. The problem is that the
> ORBit in CVS head is fixed at 0.5.1 for some god-only-knows reason. This
> means that the configure script gets confused (and prints out a verbose
> warning msg), but ultimately doesn't stick the correct include and lib
> directives into the makefiles.
> 
> I fixed this by editing the ORBIT_MICRO_VERSION variable in ORBit
> configure.in from 1 to 2, which fixed the problem.
> 



Hmm, Well that describes my configuration.  But I tried that too and it
didn't run. (I also tried setting it to 3) SOmething is fooling
configure into not picking up the stuff from the /usr/local/devel
directory. 


I'll also try it with the latest CVS of ORBit.

Adam

Re: [orbitcpp-list] Understanding orbit-c++

[Bruce I. <nr...@us...>]

Adam Young wrote:
> (SNIP)...
>
> 6)and finally for orbitcpp
> 
> cd ../orbitcpp
> ./autogen.sh -prefix /usr/local/devel/
> make
> 
> This is the step thaht fails for me.  I get a build error in
> orbitcpp_tools looking MemHow.  I know this is in
> PREFIX/include/orb/allocators.h
> (SNIP)...

That problem went away for me when I upgraded to GCC 2.95.2. I believe
the FAQ mumbles something about it. Maybe it should mumble it a little
more loudly...

-- 
Bruce Ide                        nr...@us...
If trees screamed would we be as quick to cut them down? Possibly,
if they screamed all the time.

Re: [orbitcpp-list] Understanding orbit-c++

[Phil D. <ph...@us...>]

Andreas Kloeckner wrote:
> 
> On Tue, Jul 25, 2000 at 08:22:58PM -0500, Dave Smith wrote:
> >
> > Greetings again...
> >
> > Well, I managed to get CVS ORBit & CVS ORBit-cpp working in a "safe" directory. IDL compiler seems to work
> > and everything is happy. I can run the tests, tho the tests/everything-typedef doesn't want to build for
> > some reason. At any rate, most of the stuff appears to work.
> 
> Yup, everything-typedef fails for some reason for me, too. I'll look into
> this when the next exams are over (Aug 3).
> 


Err.. yeah, the everything-typedef test is broken at the moment.
Basically this is a test which uses all the 'everything' test
implementation files, but uses an IDL file where each item is typdefed.
Unfortunately it doesn't all work at the moment.

Sorry folks,

Phil.