[omniORB] IDL #includes -> C++ #includes

baileyk@schneider.com baileyk@schneider.com
Wed Aug 7 20:10:01 2002

Here's what I've come up with so far.  In cxx/ast.py I added a function

def toplevel_includes():
    mf = open( mainFile(), "r" )
    mftext = mf.read();
    pat = re.compile("^#\s*include\s+([\"\<])(.*)([\"\>])",re.M)
    pos = 0
    paths = []
    while pos >= 0:
       found = pat.search(mftext, pos)
       if found :
          pos = found.end(3)
       else : pos = -1
    all_includes = includes()
    # I have the top level relative include paths, now
    # take any out for which the filename does is not in the
    # full list of resolved paths
    all_filenames = [ path.basename(i) for i in all_includes ]
    paths = [ i for i in paths if path.basename(i) in all_filenames ]
    return paths

Then in cxx/header/__init__.py I check for a config value and use this in
place of ast.includes().  It seems to work, but I'm sure something so
simple will fail on some valid idl somehow.  If I can get hold of the
search path the preprocessor used I can at least do the last couple lines
of filtering based on full file paths rather than just names.

Any comments?


                    m                          To:     omniorb-list@realvnc.com                                        
                    Sent by:                   cc:                                                                     
                    omniorb-list-admin@r       Fax to:                                                                 
                    ealvnc.com                 Subject:     Re: [omniORB] IDL #includes -> C++ #includes               
                    08/07/2002 01:06 PM                                                                                

It appears that include directives are not part of the AST.  The cxx
backend just gathers a list of file names from whence the various
declarations in the AST come from.  Those that aren't from the main file
generate include directives in the output.  No wonder indirect dependencies
are generating includes.  I don't have much hope of getting the behavior I
want.  I would probably need to rescan the IDL source myself.  The file
names that come out of the preprocessor are already resolved.  The original
include directives have been lost.

I could scan the mainfile and find the file names I'm after, but it would
be hard to honor any conditional compilation directives at the same time.
Maybe if I compare both lists and remove those from the mainfile that don't
show up in the full list?  There would still be cases where it does the
wrong thing though if non-unique file names are used.


----- Forwarded by Kendall Bailey/Schneider on 08/07/2002 12:54 PM -----

                    Kendall Bailey

                                         To:     omniorb-list@realvnc.com

                    08/07/2002           cc:

                    12:22 PM             Fax to:

                                         Subject:     Re: [omniORB] IDL
#includes -> C++ #includes(Document
                                         link: Kendall Bailey)

That would probably work for a single include path.  I'm assuming you would
do something like this from within directory c when compiling c.idl:

(cd .. ; omniidl -bcxx -Wbkeep_inc_path -I. -Cc c/c.idl)

This does what I want in the simple example.  However, does it extend to
multiple include paths?  What if my a and b directories are not in the same
place?  Something like


Within dir3/c I'd like to generate c.hh with #include <b/b.hh> by using the
compile command

omniidl -bcxx -I/somepath/dir1 -I/somepath/dir2 c.idl

Using the above approch I tried

(cd ../.. ; omniidl -bcxx -Idir1 -Idir2 -Wbkeep_inc_path -Cdir3/c

but that still leaves dir1 and dir2 as part of the include directives in
c.hh.  I'd be willing to try to implement a -Wbkeep_rel_inc_path option.  I
was hoping for a pointer to the right part of the compiler.  I'll start
searching for it myself.


omniORB-list mailing list