[omniORB] idl compiler for c++ mixes up includes

[Bruce Visscher]

Martin,

Martin Haaß wrote:

>  The Problem we encounter is this: file a.h includes a corba stub from
>  another directory
>
>  a.h looks like this: #include "directory_b/corba1.hh"
>
>  The corba1.hh gets stubbed from an idl file which includes another
>  idl from the same directory, corba2.idl. So the generated include in
>  corba1.hh looks like this:
>
>  directory_b/corba1.hh: #include <corba2.hh>
>
>  regardless whether i write #include <corba2.idl> or #include
>  "corba2.idl" in corba1.idl, the stubbed corba1.hh always looks like
>  above. But then the corba2.hh is only found if i add an extra include
>  path, which i don't want to.
>
>  I know of the -Wbuse-quotes option, but then all includes are
>  generated with quotes. This does not look like a wise decision to me
>  as it destroys the concept of user-includes and system-includes
>  which, in the end, is the difference between #include "" and #include
>  <>
>
>  Could this be a bug in the idl-compiler? Or is it considered a
>  feature I don't understand? Would it be possible to conserve the
>  character that is used in the include statement inside the idl?
>

IMHO, it isn't clear what it is you expect omniidl to do.

One possibility would be to have a feature that would translate #include 
directives
in the idl files that are of the form:

#include <dir/file.idl>

into:

#include <dir/file.hh>

Would that capability address the issue you are having?

In fact, omniidl's predecessor, omniidl2 used to do this.  But only if 
it ran on the
windows platform.  In fact, this was actually a bug but some of us found 
this to be a
useful idea so from time to time I see this suggestion come up on this list.

In fact, the current version of omniidl (or more precisely, the C++ back 
end) now has a
(-Wbkeep_inc_path) that retains the directory information in the 
generated #include
directives.  However, since the back end doesn't see the source code 
until after
preprocessing, it still isn't quite the same as the omniidl2 Windows 
version (mis?)feature.

After thinking about this recently, I came to the concusion that it 
would be useful to have
yet another options (-Wbstrip_inc_path perhaps?) that would do what 
-Wbkeep_inc_path
does but "strips" any part of the path that is found to be part of the 
include path.

I think this would come close to providing the capability that I 
describe above.  Do others think
that this would be a useful feature?

Bruce