orbitcpp-list

[orbitcpp-list] switch to spaces

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

Hi Phil, pholks :),

i've just made up my mind. tabs indeed are evil. let's do the switch to
spaces asap [if you all agree]. when i've committed my array stuff, i'll
be out of the tree for a little while [two weeks or so] for hacking a
game with some pals. that would be a good time to do the conversion.
what do you think?

cya
andy

[orbitcpp-list] Not unions, but arrays

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

Hi folks,

I've decided I'm going to hack arrays next, not unions. Unions require
special handling for arrays, so I guess they'd better be there before we
start unions. [besides they're probably more fun to implement :-]

cya
andy

[orbitcpp-list] Updated Orbit-C++ FAQ

[Mark G. <mar...@ya...>]

All,

Here is the updated FAQ. There are still unanswered
questions left. So, if you've got any input, send it
on and I'll be sure to incorporate it.

Note, I've marked my own comments and questions within
brackets.

Thanks,
Mark

----

ORBit-C++ FAQ

0. Administrivia

0.1. Version

This is version 0.2 of the FAQ, released on [???].

0.2. Authors

This FAQ was originally written by Andrew Smith. It is
being updated by Mark Gunn. It is the distilled wisdom
of Phil Dawes, Ronald Garcia, Andreas Kloeckner [any
other names I should put here?] and other posters 
to the orb...@li... mailing
list.

1. General

1.1. What is ORBit-C++?

ORBit-C++ is a project whose goal is to provide a C++
mapping for the ORBit project's CORBA 2.2 compliant
ORB. If that doesn't make sense, then you should read
up on CORBA and ORBit. See the "Related Information"
section below.)

1.2. How does it relate to ORBit?

Currently, ORBit only provides a C CORBA mapping.
ORBit-C++ provides the C++ "bindings" to the C
mapping. In other words, ORBit-C++ generates code that
marshals CORBA C++ class functions to the ORBit
generated CORBA C functions. For C++ programmers, it
appears that they are using C++ mappings directly.
Access to CORBA objects through ORBit is done without
having to wrap them manually. Conversely, CORBA
objects can be
implemented in C++ and used by C programmers without
having to deal with C++ name mangling issues.

1.3. Is there a mailing list?

Yes, it is called orb...@li...
and is currently hosted by SourceForge. To join, check
out the web site:

http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

1.4. Is there a web site?

Yes, it is:

   http://orbitcpp.sourceforge.net/

2. Compiling & Installing

2.1. How do I get the source?

The source code is available from the SourceForge
anonymous CVS server. To check it out, use the
following commands:

   $ export
CVSROOT='-d:pserver:ano...@cv...:/cvsroot/orbitcpp'
   $ cvs login
   [There is no password, just hit return.]
   $ cvs -z3 checkout ORBit-C++

Once you have a version checked out, you can update it
by using the
following command:

   $ cvs -z3 update -dP ORBit-C++

The -z3 switch enables compression; note that the
GNOME CVS maintainers request that you don't specify a
compression level higher than 3 to keep the load on
the machine down. The -dP switches ensure that any
additional new directories are downloaded and that
obsolete ones are pruned. For more information read
the SourceForge CVS documentation: 
	http://sfdocs.sourceforge.net/sfdocs/site/cvs.php

2.2. What software do I need to compile it?

You will need the following software installed to
compile the source:

        egcs [?]
        automake [?]
        autoconf [?]
        ORBit [?]
        glib [?]
        [any others?]

The version numbers listed are the minimum known to
work. Make sure you have the development portions of
ORBit and glib as well, otherwise you will be missing
some of the required header files.

2.3. How do I compile it?

First, you need to generate all the make files. In the
top directory, run the "autogen.sh" script. Second,
still in the top directory, run the command "make". 
This is also described in the INSTALL file.

[What is the difference between running the configure
command and executing the autogen.sh script file?
Also, I've noticed that the *.tar.gz file does not
usually contain an autogen.sh script file. 

2.4. It's compiled, now what?

You need to install it. To do this, in the top
directory run the command "make install". [Correct me
if I'm wrong, but you need root priveledges to
install.] This will allow you to use the orbit-idl
command to generate the C and C++ bindings on IDL
files.

2.6 What is the name of the Orbit-C++ idl compiler?

It is orbit-idl.

2.7 Is this the same as the Orbit idl compiler?

Yes. However, the Orbit-C++ idl compiler acts as a
backend compiler to the Orbit idl compiler.

3. Using

3.1. How do I compile my IDL file?

Once you have compiled and installed the code, issue
the following
commands: 

	orbit-idl -l c test.idl
        orbit-idl -l c++ test.idl

This will generate the c++ code, which will wrap the
generated c code.

3.2. Why won't my IDL file compile?

Work on the idl-compiler is still in progress. [I'm
not sure what is and isn't done; so, I removed what
was here. Perhaps we could be vague here and reference
the hacking file for features not implemented here. Or
suggest they query the list. Suggestions?] 

3.3. Why do the .cc files have "-cpp-" in the name?

ORBit-C++ generated files must be compiled with ORBit
generated files. The "-cpp-" is added to prevent the
object files from clashing. For instance:

        foo-stubs.c  -> foo-stubs.o
        foo-stubs.cc -> foo-stubs.o

This is rectified by:

        foo-stubs.c      -> foo-stubs.o
        foo-cpp-stubs.cc -> foo-cpp-stubs.o

4. Development

4.1. How can I help?

First, subscribe to the mailing list and read up on
what work is currently being done. Secondly, check out
the code and see if you can compile it. If this works,
try some of the test cases. Whatever happens, let the
mailing list know how you got on.

If you want to contribute code, look at the HACKING
file to see what needs doing. Also, check with the
mailing list as well. Writing test cases would also be
useful. Of course, there is always more need for
documentation.

4.5. How do I submit code?

If you have write access to the SOURCEFORGE CVS
archive, then just use the following command:

        $ cvs commit

If you have not got write access, then the best thing
to do is create a unified diff patch against the CVS
archive. You can do this with the following command:

        $ cvs -z3 diff -RNu ORBit-C++ > patchfile

This will pick up all of the changes you have made,
including files that have been created or deleted. It
is helpful if you put the date in the patch file name,
something like "orbitcpp-19990814.patch" is good. Mail
the patch file to the list and one of the core
developers will apply it to the CVS archive. If you
find yourself submitting a lot of patches,
then it is time to get a write access account for the
SOURCEFORGE CVS archive. Mail the list for details,
although you will probably be spotted by one of the
core developers first if it comes to this.

[There's a lot of good information information in
HACKING file. Should we merge some of that information
into here? Or keep it separate and just reference it
from here?]

5. Testing

5.1 How do I test it?

Each directory under the test directory contains code
for a simple test case. The README file explains what
functionality is being tested and what to do.
Generally, all you need to do is run make in the
directory. If it builds, try the following commands:

        ./server > iorfile &
        ./client `cat iorfile`

The output should give some indication of success or
otherwise.

6. Related Information

The CORBA 2.2 specification is available at:

        http://www.omg.org/corba/corbaiiop.html

[I'm not sure if this url is still valid. I tried
checking it, but I couldn't get to the OMG site. So,
I'll check it later.]

It is provided in PostScript and PDF formats, but
there is no  (official) online version.

The ORBit homepage is at:

        http://www.labs.redhat.com/orbit/

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[orbitcpp-list] Compile Error

[Mark G. <mar...@ya...>]

All,

I downloaded the new Orbitcpp release, but I am unable
to compile it. I suspect that I didn't install the
patched Orbit correctly. Do I need to uninstall/remove
the previous version of Orbit? If so, how do I go
about doing this? 

I'm assuming that Orbitcpp looks uses certain files
from Orbit. How do I ensure that it is looking in the
right place?

The error I get is:

In file included from orbitcpp_poa.cc:30:
../orb/orbitcpp_poa.hh:49: template-id `operator
new<>' for
`::_orbitcpp::::_orbitcpp::SequenceTmpl<unsigned
char,::_orbitcpp::c::PortableServer_sequence_octet>::operator
new<>(ULong)' does not match any template declaration
../orb/orbitcpp_poa.hh:49: confused by earlier errors,
bailing out
make: *** [orbitcpp_poa.lo] Error 1

Thanks,
Mark

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[orbitcpp-list] orbitcpp-0.27 released!

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

Hi folks,

ORBit-C++ version 0.27 is out and ready for your consumption. 
Check out the web page:
http://orbitcpp.sourceforge.net/

BTW, don't forget to read the release notes before downloading.

Cheers,

Phil.

[orbitcpp-list] going to release 0.27 at 5.00 GMT

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

Hi Andreas, all,

I'm going to do the 0.27 release at ~5.00 GMT tonight. If there's
anything anybody wants in the release then commit it before then or
forever hold your peace. (well at least for the next week or so until
0.28 comes out :-)

Cheers,

Phil.

[orbitcpp-list] ORBit-0.5.1 patched for orbitcpp

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

Hi Folks,


I've patched up a copy of ORBit-0.5.1 with all the relevant patches for
cvs ORBit-C++.

(i.e. the --backenddir one, the sequence fix and the lexer fix)

Check out:
ftp://orbitcpp.sourceforge.net/pub/orbitcpp/

Cheers,

Phil.

[orbitcpp-list] idl parser fix

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

Hi everyone,

current libIDL (as of ORBit 0.5.1) barfs on "const long u = 1-1;", which
is caused by the lexer gobbling up the minus to result in "1" "-1" both
parsed as integer constants. removing the "-" form the lexer defs fixes
this, as done in the enclosed patch.

cya
andy

[orbitcpp-list] Re: [orbitcpp-commits] orbitcpp inducer

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

Hi folks,

sorry, I just can't remember where my brain was yesterday. :(

> 
> CVSROOT:        /cvsroot/orbitcpp
> Module name:    orbitcpp
> Changes by:     inducer 00/04/13 13:25:45
> 
> Modified files:
>         compiler       : base.cc base.hh types.cc types.hh
>         orb            : orbitcpp_sequence.hh
> Added files:
>         orb            : orbitcpp_exceptionlist.hh
> 
> Log message:
> * moved getCast to base.hh/base.cc, renamed to idlGetCast.


> * added SequenceBase::_orbitcpp_assume for speedier exception packing.

Forget about this one, I kicked it out again. Instead, insert

* added orbitcpp_exceptionlist.hh

:)

> * renamed "cstruct" for struct packers to "_cstruct" to
> avoid name clashing

Re: [orbitcpp-list] problem with the type_container approach...

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

Andreas Kloeckner wrote:
> 
> Why not send the type_container to hell then and have an
> _orbitcpp::stubs namespace instead?
> 
> what do you think?
> 
> cya andy
> 

what i was trying to say was: yes, good idea, let's not have a
type_container namespace, but an _orbitcpp::stubs namespace. sorry.

cya

Re: [orbitcpp-list] coding standards - again

[Petter R. <pe...@hu...>]

> To be honest I don't really mind. I'll try and conform to 1 since
> you have an opinion, but I might slip up occasionally. (I'm sure we
> could globally fix that with a quick perl hack!)

Or run astyle to fix it.  :-)

<URL:http://astyle.sourceforge.net/>
-- 
##>  Petter Reinholdtsen <##    | pe...@td...
 O-  <SCRIPT Language="Javascript">window.close()</SCRIPT>
http://www.hungry.com/~pere/    | Go Mozilla, go! Go!

Re: [orbitcpp-list] errors when running autogen.sh

[Mark G. <mar...@ya...>]

Phil & Andy,

Thanks for both of your replies. I got it to work. The
ORBit.m4 was only located in /usr/local/share/aclocal.
So, I copied it to /usr/share/aclocal and was able to
run autogen.sh and build orbitcpp via cvs!  

Between these two directories, which one is the
correct place? (Even though I got it to work, I'd like
to make sure I've got files in the correct place. :-)

I'm (slowly) making progress on getting familiar with
all the code. I hope to have a first cut of the FAQ
out by this weekend. Once I'm done, I'll post it the
list for your guys comments/input.

I mentioned to Phil earlier about what I could cut my
teeth on and he had mentioned enum and constants.
However, I think since then that those tasks have
already been accomplished. So, is there something that
is rather trival that needs implementing. As I've
mentioned, I don't have much CORBA experience. So, in
other words, if there's some really mundane task
that's really easy to do and you've been putting off
because it's so simple, let me know and I'll do it.
(It won't be mundane for me! :-)

Also, do either of you guys have any suggestions on
where I could learn more about ORB development (i.e.,
books, website, etc.)? I have Hennings' and Vinoski's
book, but it seems to be geared towards using an ORB
verses developing an ORB.

Thanks,
Mark



__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [orbitcpp-list] Re: [orbitcpp-commits] orbitcpp inducer

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

> I prefer to stick to glib types, because we already require glib and we
> know it's portable (it even implements some functions if they dont exist
> on systems). I don't think I can be sure to say the same for unsigned
> int and assert. You may have more knowledge on this than me, but I take
> the working assumption that if glib doesn't port properly then we can
> fix it.

Those unsigned int's are gone already, now they're CORBA::ULong's, which
I think is best. concerning the assert, I dunno. I think we should
minimize or at least encapsulate glib dependencies because <illusion>
maybe someone else also has a c orb he needs wrapped to be a c++ orb.
</illusion> 

> 
> > * added FAQ (wanna know what i was doing lately? look here. :((()
> > * fixed some tests to remedy problem from FAQ question 1
> > * added exceptionlist mechanism
> > * removed check for glib from configure.in:
> > is necessarily included with ORBit
> > * fixed bad bug in smartptr.hh _retn methods
> > * fixed bug with empty exceptions
> > * reimplemented PortableServer::ObjectId in terms of sequences
> > * removed code duplication from sequence template impl, implemented
> > missing copy and assignment, made implementation out-of-memory-aware,
> > implemented the specified allocbuf/freebuf functions, made the
> > sequence template roll its own CPP struct...
> >
> > ah well, call it a reimplementation of orbitcpp_sequence. :)
> 
> Cool! Can't wait to see what you've done!

not too much new code, actually. hardest were those darn segfaults i've
been hunting. :(((

cya
andy

Re: [orbitcpp-list] problem with the type_container approach...

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

Why not send the type_container to hell then and have an
_orbitcpp::stubs namespace instead? 

what do you think?

cya andy


Phil Dawes wrote:
> 
> Hi Andreas, Hi all,
> 
> Not really a problem, just an oversight which means the servant may be
> forced to link with the stubs.
> 
> With the current approach, any types declared in the idl interface:
> 
> e.g.
> 
> interface foo {
>     exception bah {
>     };
> };
> 
> go in the type_container class, i.e.:
> 
> foo-cpp-common.hh
> -----------------
> namespace _orbitcpp { namespace type_container {
> class Foo {
>     class bahException : public UserException {
>         ...
>     };
>     ...
> };
> }}
> 
> foo-cpp-stubs.hh
> ----------------
> class Foo : public CORBA::Object,
>             public _orbitcpp::type_container::Foo {
> }
> 
> This means that the poa servant cannot reference the exception using the
> fully qualified ::Foo::BahException  without linking with the stubs,
> since otherwise the compiler doesn't know that Foo inherits from
> _orbitcpp::type_container::Foo. If I understand the spec correctly, the
> servant doesn't have to inherit from the interface class, and so
> referenceing the exception using its fully-qualified name is the only
> way to portably reference it.
> 
> Instead I propose that we do the following to fix the above problem:
> 
> foo-cpp-common.hh
> -----------------
> class Foo {
>     class BahException : public UserException {
>         ...
>     };
>     ...
> };
> 
> and in foo-cpp-stubs.hh
> -----------------------
> class Foo_stub : public CORBA::Object,
>                  public Foo {
> }
> 
> i.e. the type_container class becomes the named corba interface class,
> and a seperate stub class is used for the stub.
> 
> I wrote the code to do this on the train back from London today, but
> I'll need to merge it with your checked in code (and get the inheritance
> stuff working with the new scheme). I thought I'd wait and see if you
> have any thoughts before checking it in.
> 
> Sorry if the above is a little hard to follow - I wrote this in a hurry,
> 
> Cheers,
> 
> Phil.
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

[orbitcpp-list] Re: [orbitcpp-commits] orbitcpp inducer

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

Hey Andreas,

Big kudos to you for getting all of this stuff fixed/done :-)

Andreas Kloeckner wrote:
> 
>
> g_error --> _orbitcpp::error
> g_assert --> assert (from cassert)
> guint --> unsigned int
> 
> this ok phil?

I prefer to stick to glib types, because we already require glib and we
know it's portable (it even implements some functions if they dont exist
on systems). I don't think I can be sure to say the same for unsigned
int and assert. You may have more knowledge on this than me, but I take
the working assumption that if glib doesn't port properly then we can
fix it.

> * added FAQ (wanna know what i was doing lately? look here. :((()
> * fixed some tests to remedy problem from FAQ question 1
> * added exceptionlist mechanism
> * removed check for glib from configure.in:
> is necessarily included with ORBit
> * fixed bad bug in smartptr.hh _retn methods
> * fixed bug with empty exceptions
> * reimplemented PortableServer::ObjectId in terms of sequences
> * removed code duplication from sequence template impl, implemented
> missing copy and assignment, made implementation out-of-memory-aware,
> implemented the specified allocbuf/freebuf functions, made the
> sequence template roll its own CPP struct...
> 
> ah well, call it a reimplementation of orbitcpp_sequence. :)

Cool! Can't wait to see what you've done!


> oh boy. i am so happy i've got the tests running alright, so I can finally
> commit this funky bunch... have fun!
> 

And you,

Cheers,

Phil.

Re: [orbitcpp-list] coding standards - again

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

Andreas Kloeckner wrote:
> 
> Hi Phil and all,
> 
> is it
> 
> 1. if (blah) { blurch(); } // my favourite
> 
> or
> 
> 2. if(blah) { blurch(); } // you like this one, right?
> 

Err.. just habit I suppose.

> most of the compiler is coded with number 1. i'd like to stick with
> that. what's your opinion?
> 

To be honest I don't really mind. I'll try and conform to 1 since you
have an opinion, but I might slip up occasionally. (I'm sure we could
globally fix that with a quick perl hack!)

Cheers,

Phil.

[orbitcpp-list] problem with the type_container approach...

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

Hi Andreas, Hi all,


Not really a problem, just an oversight which means the servant may be
forced to link with the stubs.

With the current approach, any types declared in the idl interface:

e.g.

interface foo {
    exception bah {
    };
};

go in the type_container class, i.e.:


foo-cpp-common.hh
-----------------
namespace _orbitcpp { namespace type_container {  
class Foo {
    class bahException : public UserException {
        ...
    };
    ...
};
}}


foo-cpp-stubs.hh
----------------
class Foo : public CORBA::Object, 
            public _orbitcpp::type_container::Foo {
}


This means that the poa servant cannot reference the exception using the
fully qualified ::Foo::BahException  without linking with the stubs,
since otherwise the compiler doesn't know that Foo inherits from
_orbitcpp::type_container::Foo. If I understand the spec correctly, the
servant doesn't have to inherit from the interface class, and so
referenceing the exception using its fully-qualified name is the only
way to portably reference it.



Instead I propose that we do the following to fix the above problem:


foo-cpp-common.hh
-----------------  
class Foo {
    class BahException : public UserException {
        ...
    };
    ...
};


and in foo-cpp-stubs.hh
-----------------------
class Foo_stub : public CORBA::Object, 
                 public Foo {
}



i.e. the type_container class becomes the named corba interface class, 
and a seperate stub class is used for the stub.


I wrote the code to do this on the train back from London today, but
I'll need to merge it with your checked in code (and get the inheritance
stuff working with the new scheme). I thought I'd wait and see if you
have any thoughts before checking it in.

Sorry if the above is a little hard to follow - I wrote this in a hurry,


Cheers,

Phil.

Re: [orbitcpp-list] the whoppin' funky bunch

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

Phil Dawes wrote:
> 
> Andreas Kloeckner wrote:
> >
> > Hi Phil & all,
> >
> > tonight I've dumped a load of code and fixes back to cvs. (now that
> > finally all tests work <phew>). to enjoy the new version to the fullest
> > 8-)))) you need to apply a patch to ORBit (about sequence handling), it
> > is located in the patches/ subdir of the repository. (new)
> >
> > for the last three days i've been mainly busy hunting down spurious
> > segfaults, if you want to know more about them, look in the new
> > "mini-FAQ".
> >
> > furthermore, i guess the code is quite ready for 0.27. [i've still got
> > two little improvements in mind that i want to have in that version, so
> > please don't release before about tomorrow afternoon] btw, in features
> > we're almost level with the old Python ORBit-C++, while my old o2cpp
> > 'basic' test is also working. our current state probably isn't all too
> > bad B-)))))
> >
> > for your schedule, i'll be hacking unions and constants tomorrow.
> >
> > cya
> > andy
> >
> 
> Hi Andreas,
> 
> Good work my friend! However, I'm missing orb/orbitcpp_exceptionlist -
> any chance of cvs-adding it? ;-)

whoops. should be in in about half an hour.

:)

Re: [orbitcpp-list] errors when running autogen.sh

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

all this really looks like ORBit.m4 is not in /usr/share/aclocal (or
whatever you have configured as autoconf repository, ymmv) furthermore,
it looks like your autoconf doesn't honor acinclude.m4. what version do
you run? try and install a new version, try adding ORBit.m4 to the rep.

cya
andy


Mark Gunn wrote:
> 
> Hello all,
> 
> I am trying to build everything from cvs, but I get
> the following errors when running autogen.sh. (Note I
> was able to build everything from *.tar.gz file. From
> the looks of the error messages, I'm assuming I need
> to specify some values, but I'm not sure what or
> where.
> 
> Is there something else I need to do before I run
> autogen.sh?
> 
> Any help would be greatly appreciated.
> Thanks,
> Mark
> 
> Error output:
> 
> I am going to run ./configure with no arguments - if
> you wish
> to pass any to it, please specify them on the
> ./autogen.sh command line.
> processing .
> You should add the contents of
> `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
> aclocal: configure.in: 82: macro `AM_PATH_ORBIT' not
> found in library
> Makefile.am:5: HAVE_ORBIT_IDL_BACKENDDIR does not
> appear in AM_CONDITIONAL
> configure.in: 96: required file
> `orb/orbitcpp_config.hh.in' not found
> orb/Makefile.am:31: variable `ORBIT_LIBS' not defined
> test/idl-torture/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> test/basic/Makefile.am:4: variable `ORBIT_LIBS' not
> defined
> test/basic/Makefile.am:4: variable `ORBIT_LIBS' not
> defined
> test/basic/generated/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> test/string/Makefile.am:6: variable `ORBIT_LIBS' not
> defined
> test/string/Makefile.am:6: variable `ORBIT_LIBS' not
> defined
> test/string/generated/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not
> defined
> test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not
> defined
> test/boolean/generated/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> test/everything/Makefile.am:6: variable `ORBIT_LIBS'
> not defined
> test/everything/Makefile.am:6: variable `ORBIT_LIBS'
> not defined
> test/everything/generated/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> test/everything-typedef/Makefile.am:6: variable
> `ORBIT_LIBS' not defined
> test/everything-typedef/Makefile.am:6: variable
> `ORBIT_LIBS' not defined
> test/everything-typedef/generated/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> Running ./configure --enable-maintainer-mode
> loading cache ./config.cache
> ./configure: line 552: syntax error near unexpected
> token `AM_INIT_AUTOMAKE($PACKAGE,'
> ./configure: line 552: `AM_INIT_AUTOMAKE($PACKAGE,
> $VERSION, no-define)'
> 
> Now type 'make' to compile ORBit-C++.
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

[orbitcpp-list] coding standards - again

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

Hi Phil and all,

is it

1. if (blah) { blurch(); } // my favourite

or

2. if(blah) { blurch(); } // you like this one, right?

most of the compiler is coded with number 1. i'd like to stick with
that. what's your opinion?

cya
andy

Re: [orbitcpp-list] the whoppin' funky bunch

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

Andreas Kloeckner wrote:
> 
> Hi Phil & all,
> 
> tonight I've dumped a load of code and fixes back to cvs. (now that
> finally all tests work <phew>). to enjoy the new version to the fullest
> 8-)))) you need to apply a patch to ORBit (about sequence handling), it
> is located in the patches/ subdir of the repository. (new)
> 
> for the last three days i've been mainly busy hunting down spurious
> segfaults, if you want to know more about them, look in the new
> "mini-FAQ".
> 
> furthermore, i guess the code is quite ready for 0.27. [i've still got
> two little improvements in mind that i want to have in that version, so
> please don't release before about tomorrow afternoon] btw, in features
> we're almost level with the old Python ORBit-C++, while my old o2cpp
> 'basic' test is also working. our current state probably isn't all too
> bad B-)))))
> 
> for your schedule, i'll be hacking unions and constants tomorrow.
> 
> cya
> andy
> 

Hi Andreas,

Good work my friend! However, I'm missing orb/orbitcpp_exceptionlist -
any chance of cvs-adding it? ;-)

Cheers,

Phil.

Re: [orbitcpp-list] errors when running autogen.sh

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

Mark Gunn wrote:
> 
> Hello all,
> 
> I am trying to build everything from cvs, but I get
> the following errors when running autogen.sh. (Note I
> was able to build everything from *.tar.gz file. From
> the looks of the error messages, I'm assuming I need
> to specify some values, but I'm not sure what or
> where.
> 
> Is there something else I need to do before I run
> autogen.sh?
> 
> Any help would be greatly appreciated.
> Thanks,
> Mark
> 

Hey Mark,

I think the problem might be an ORBit version mismatch. You need ORBit
0.5.1 to be able to run orbitcpp from CVS. I don't believe the
AM_PATH_ORBIT macro existed in previous versions of ORBit. If you've
already got 0.5.1 installed then it might be picking up the wrong
version of ORBit.m4. Have a hunt around your system to see if there's
more than one (try /usr/share/aclocal/ and usr/local/share/aclocal/)

Hope this helps,

Phil.

Re: [orbitcpp-list] IDL Compiler

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

Mark Gunn wrote:
> 
> Hi all,
> 
> I spoke to Phil about updating the old FAQ for the
> project. So, I'm currently working my through it. One
> question that I've got is how the idl compiler for
> Orbit-C++ works in conjunction with the Orbit idl
> compiler.
> 
> I noticed in the old faq that the Oribit-C++ idl
> compiler was called orbit-idl2cpp. I only see the use
> of orbit-idl; so, is it correct to say that this has
> been obsoleted?
> 
> If so, then is orbit-idl the Orbit idl compiler and
> the Orbit-C++ idl compiler? Or is there another layer
> that I'm missing?

have a look at the HACKING file. our compiler acts as a backend to
orbit-idl. so, in order to get full stub and skel code, you do

orbit-idl -l c test.idl
orbit-idl -l c++ test.idl

the generated c++ code then plugs in on top of the c code.

> [Andreas, I noticed that you created a FAQ in cvs.
> Perhaps once I get the old FAQ updated, we could merge
> the FAQs.]

this is nothing like a FAQ, it's some info on bugs and common mistakes
that I ran into, so I decided it was worth putting in a file. Gobble it
up any way you like :)

cya
andy

[orbitcpp-list] IDL Compiler

[Mark G. <mar...@ya...>]

Hi all,

I spoke to Phil about updating the old FAQ for the
project. So, I'm currently working my through it. One
question that I've got is how the idl compiler for
Orbit-C++ works in conjunction with the Orbit idl
compiler.

I noticed in the old faq that the Oribit-C++ idl
compiler was called orbit-idl2cpp. I only see the use
of orbit-idl; so, is it correct to say that this has
been obsoleted?

If so, then is orbit-idl the Orbit idl compiler and
the Orbit-C++ idl compiler? Or is there another layer
that I'm missing? 

[Andreas, I noticed that you created a FAQ in cvs.
Perhaps once I get the old FAQ updated, we could merge
the FAQs.]

Thanks in advance,
Mark

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[orbitcpp-list] errors when running autogen.sh

[Mark G. <mar...@ya...>]

Hello all,

I am trying to build everything from cvs, but I get
the following errors when running autogen.sh. (Note I
was able to build everything from *.tar.gz file. From
the looks of the error messages, I'm assuming I need
to specify some values, but I'm not sure what or
where.

Is there something else I need to do before I run
autogen.sh?

Any help would be greatly appreciated.
Thanks,
Mark

Error output:

I am going to run ./configure with no arguments - if
you wish 
to pass any to it, please specify them on the
./autogen.sh command line.
processing .
You should add the contents of
`/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
aclocal: configure.in: 82: macro `AM_PATH_ORBIT' not
found in library
Makefile.am:5: HAVE_ORBIT_IDL_BACKENDDIR does not
appear in AM_CONDITIONAL
configure.in: 96: required file
`orb/orbitcpp_config.hh.in' not found
orb/Makefile.am:31: variable `ORBIT_LIBS' not defined
test/idl-torture/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/basic/Makefile.am:4: variable `ORBIT_LIBS' not
defined
test/basic/Makefile.am:4: variable `ORBIT_LIBS' not
defined
test/basic/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/string/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/string/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/string/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/boolean/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/everything/Makefile.am:6: variable `ORBIT_LIBS'
not defined
test/everything/Makefile.am:6: variable `ORBIT_LIBS'
not defined
test/everything/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/everything-typedef/Makefile.am:6: variable
`ORBIT_LIBS' not defined
test/everything-typedef/Makefile.am:6: variable
`ORBIT_LIBS' not defined
test/everything-typedef/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
Running ./configure --enable-maintainer-mode
loading cache ./config.cache
./configure: line 552: syntax error near unexpected
token `AM_INIT_AUTOMAKE($PACKAGE,'
./configure: line 552: `AM_INIT_AUTOMAKE($PACKAGE,
$VERSION, no-define)'

Now type 'make' to compile ORBit-C++.

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com