AW: [omniORB] omniidl bug

[Serguei Kolos]

Hi Barthel

I believe this is not an issue. I don't know why it has been working before,
but normally one has to specify with the -I option all the directories 
for the
included files. For example C++ compiler does not include files from the
current directory unless you provide it with the "-I." option in the 
command line.
The same option should solve the problem you described, i.e. try:
 > omniidl -bcxx -I.

Cheers,
Sergei

>Hi Sergei
>
>  
>
>>As a result the original (short) file name appears in the preprocessor output.
>>I believe the omniidl itself does not try to open the included files and everything 
>>works as I desired. I believe this would not have any negative implications to the
>>IDL compiler. What do you think ?
>>    
>>
>
>I reported this bug also and was very interested in the fix/hack.
>
>I tried it yesterday and it had some minor/major problem:
>
>the directory where the root preprocessed file is opened is nomore added automatically to the search path.
>
>
>Example:
>
>/firstdir/one.idl     (does #include "../secondir/two.idl")
>/seconddir/two.idl    (does #include "three.idl")
>/seconddir/three.idl
>
>
>now in two.idl the include three.idl cannot be found.
>
>I assume the current "local directory path" is generated from the whole filepath to two.idl by stripping of the filename two.idl. Your fix may break this.
>
>The current fix may also break make-runs for some people when using omniorb 4.0.4 in the future
>
>Except for the shown problem it works fine.
>
>-marco
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040414/bfa30291/attachment-0001.htm