[omniORB] Using #include in IDL files

[James M. Moe]

Hello,
    Before you say anything, Yes, I did search the archives about this. The suggestion 
I use is the one with the preprocssor.
    It is not an ideal solution, though it is workable.
    What we are doing is using a common header between IDL and c/c++ files for 
enumerations. In this way changes in the enumerations propogate through all the code. 
Also the files are not actual code, only the parts that reside inside of enums:

IDL:
    enum enumT {
#include "foo-bar.h"
     };

C++:
    typedef enum _enumT {
#include "foo-bar.h"
     } enum_t;


    There are 3 annoying aspects to the way omliidl2 works regarding #includes:

1. Without preprocessing the #include'd text is processed (correctly inserted in to the 
stream) by the IDL compiler, and then also #include'd in the output .hh file with a 
".hh" extension instead of ".h". Sheesh!

2. If the header file uses hyphens in the name, eg: foo-bar.h, a (seemingly incorrect) 
inclusion guard is generated like this: #ifndef foo-bar_HH_other_stuff. The main 
compiler then barfs on the #ifndef since it seems to think there is a defective 
arithmetic operation.

3. The generated code is different between using CPP and not, if there are actual IDL 
files also being included. Without CPP the included IDL is used as material to resolve 
missing or ambiguous references. No code is generated for the included files except of 
the #include <stuff.hh> sort.
    When the file is run through CPP, the IDL compiler gets a file with the full text 
of the included IDL files so generates code for those also. No #include <> statements 
are needed since the whole wad is there.


    Is this behavior defined by the CORBA spec? If not, are there plans to smarten 
omniild2 so it can better deal with these exotic styles?



Jim Moe