<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
Hi Barthel<br>
<br>
I believe this is not an issue. I don't know why it has been working
before,<br>
but normally one has to specify with the -I option all the directories
for the <br>
included files. For example C++ compiler does not include files from the<br>
current directory unless you provide it with the "-I." option in the
command line.<br>
The same option should solve the problem you described, i.e. try:<br>
> omniidl -bcxx -I. <br>
<br>
Cheers,<br>
Sergei<br>
<blockquote type="cite"
cite="mid69103452FC96584F92B7F7CB33A974EA07F4CD@tndest-ws00020.tenovis.corp.lan">
<pre wrap="">Hi Sergei
</pre>
<blockquote type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>