[omniORB] CosNaming.h and ORB portability

[Brian Neal]

We are using omniORB 4.0.6.

We are porting our code to multiple ORBs, and trying to be portable
about it. We have to deal with how each ORB handles things like the
Naming Service and Event Service. Ideally one would like to just grab
the IDL for the event and naming services off the OMG website and
compile it to your target language and you would be all set.

We would like to have our build system compile the OMG CosNaming.idl
and have our application code #include "CosNaming.h" no matter what
our target ORB is to avoid too much conditional logic in our build
files/source files. But omniORB has Naming.hh tightly coupled with
it's CORBA.h header files. So when we #include <CORBA.h> we
automatically get Naming.hh included, and then when we #include our
own CosNaming.h the compiler starts seeing multiple definitions for
all the Naming service types, etc.

We noticed this in omniORB's CORBA.h:

---snip---
// OMG COS IDLs refer to CosNaming IDL as "CosNaming.idl".
// omniORB uses the file name "Naming.idl". Any IDLs that include
// CosNaming.idl will have in their stubs #include "CosNaming.hh".
// Define the external guard for CosNaming to stop include to have
// any effect. This works because the stub generated by omniidl
// put external guards around the include.

#ifndef __CosNaming_hh_EXTERNAL_GUARD__
#define __CosNaming_hh_EXTERNAL_GUARD__
#endif
---snip---

However, our omniidl translator generates #include guards of the form:

#ifndef __CosNaming_hh__
#define __CosNaming_hh__

So it looks like omniORB tried to solve this problem for us, but the
include guards are different so it doesn't work. Did omniidl at one
time generate __CosNaming_hh_EXTERNAL_GUARD__ as the include guard
name? Or can we configure it to do so somehow?

I suppose we could add a -D__CosNaming_hh__ on our compiler command
line when building for omniORB. We were just curious what others would
recommend.

(BTW, omniORB is the best ORB of the bunch we are working with; it is
the most standards compliant and the least trouble to use. Cheers!)

Thanks.

[Duncan Grisby]

On Tuesday 6 March, "Brian Neal" wrote:

[...]

Post by Brian Neal
---snip---
// OMG COS IDLs refer to CosNaming IDL as "CosNaming.idl".
// omniORB uses the file name "Naming.idl". Any IDLs that include
// CosNaming.idl will have in their stubs #include "CosNaming.hh".
// Define the external guard for CosNaming to stop include to have
// any effect. This works because the stub generated by omniidl
// put external guards around the include.
#ifndef __CosNaming_hh_EXTERNAL_GUARD__
#define __CosNaming_hh_EXTERNAL_GUARD__
#endif
---snip---
#ifndef __CosNaming_hh__
#define __CosNaming_hh__
So it looks like omniORB tried to solve this problem for us, but the
include guards are different so it doesn't work. Did omniidl at one
time generate __CosNaming_hh_EXTERNAL_GUARD__ as the include guard
name? Or can we configure it to do so somehow?

The external guard is used when one IDL file #includes another. So if
foo.idl does #include <CosNaming.idl> then foo.hh contains:

#ifndef __CosNaming_hh_EXTERNAL_GUARD__
#define __CosNaming_hh_EXTERNAL_GUARD__
#include <CosNaming.hh>
#endif

So, the external guard stuff does serve a useful purpose, just not the
one you want.

Post by Brian Neal
I suppose we could add a -D__CosNaming_hh__ on our compiler command
line when building for omniORB. We were just curious what others would
recommend.

That seems like a sensible work-around to me. I've added a #define to
CORBA.h so it defines __CosNaming_hh__, which should avoid this problem.

Cheers,

Duncan.