[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();
mf.close()
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)
paths.append(found.group(2))
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?
Kendall
baileyk@schneider.co
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.
Kendall
----- 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
dir1/a/a.idl
dir2/b/b.idl
dir3/c/c.idl
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
dir3/c/c.idl)
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.
Kendall
_______________________________________________
omniORB-list mailing list
omniORB-list@realvnc.com
http://www.realvnc.com/mailman/listinfo/omniorb-list