I have two IDL files foo.idl and bar.idl and bar.idl is required to include structs from foo.idl however when i attempt to compile bar.idl using the below line it fails saying member type foo::a does not exist. Any idea how I get rtiddsgen2 to compile the includes from a different idl file?
rtiddsgen2 -language Java C:\bar.idl
//foo.idl
module foo{ struct a { long id }; };
//bar.idl
#include<foo.idl> module bar { struct b { foo::a id }; };
Hi,
I think the problem is being caused by the missing semicolon in the declaration of the id members within
foo::a
andbar::b
Instead of:
module foo{ struct a { long id }; };
module bar { struct b { foo::a id }; };
It should be:
module foo{ struct a { long id; }; };
module bar { struct b { foo::a id; }; };
Note the extra ";" after
id
.Unfortunately the error being printed due to the lack of the ";" is a bit misleading.
Gerardo
Thanks for the reply. I have updated the IDL's to
module foo{ struct a { long id; }; };
module bar { struct b { foo::a id; }; };
and I am still experiencing the same issue "member type 'foo::a' not found".
The IDL's are located in the same directory, is there something that needs to be added to the command line to get it compile foo.idl along with bar?
Hi,
Couuld you attach a simple IDL file that reproduces the problem? That way I can be sure to be looking at the same issue...
Gerardo
I have attached the 2 IDL's along with the exact command use which is producing the error. Note that both the foo.idl and bar.idl exist in the same directory.
Thanks
OK. I see what is happening. The problem is the way you invoke
rtiddsgen2
. It seems the behavior changed betweenrtiddsgen
andrtiddsgen2
. See note at the end.You are using:
C:\RTI\rtiddsgen2 -ppDisable -language Java C:\IDL\bar.idl
Try this instead:
C:\RTI\rtiddsgen2 -I C:\IDL -language Java C:\IDL\bar.idl
This is because if you are using the
#include
directive in the IDL file then you need to letrtiddsgen2
use the WindowsCL.exe
pre-processor. However the option-ppDisable
prevents it from running the pre-processor. In addition if you are runningrtiddsgen2
from a different directory from where the included IDL are placed, then you have to use the-I
option to tellrtiddsgen2
pre-processor where to look for these included files.The issue is that on Windows the
CL.exe
preprocessor is not included by default. You need to have Microsoft VisualStudio installed... Note that there is a Free VisualStudio Express/Community Edition you can use. Once Visual Studio is in your system you need to make sureCL.exe
(which is the command-line C/C++ preprocessor in windows) is in your path. This may happen automatically when VisualScudio is installed or if not you can run the batch file "vcvarsall.bat
" that comes with the Visual Studio installaton. This will configure the PATH appropriately. For me this file is atC:\Program Files\Microsoft Visual Studio 11.0\VC
but I haveVisual Studio 12
installed. Other versions will have it in a different place.Sorry about this confusion. As I mentioned this behavior has changed between
rtiddsgen
andrtiddsgen2
. With the oldrtiddsgen
the command would have worked as invoked.If this is too much of a hassle you could still use the old rtiddsgen if you prefer. The resulting output should be the same.
Gerardo
Perfect thanks
One more thing. I dug a bit more into it... Apparently what is happening is that
rtiddsgen
(version 1) was assuming that any "unknown type" found when declaring a member (such as the foo::a) was a structure and work OK on that narrow case, assuming it is indeed defined elsewhere. Howeverrtiddsgen2
is trying to be more robust identifying what the referred type is and generate the correct code even if it is not a structure. For this it needs to find the type thus the need to parse the included IDL.Apparently is possible to have the
rtiddsgen2
operate with the old (rtiddsgen version 1) behavior and "assume" specific "unknown types" are structures. This is accomplished with the directive//@resolve-name false
(see section 3.3.8.3 of the Core Libraries and Utilities Users Manual); which can be applied to a single member, or to a structure (so it applies to unknown members in the structure).So you can make it work with
rtiddsgen2
without using the pre-processor if you change the IDL to:Or to:
Gerardo
I have a batch file that calls "rtiddsgen.bat" with several options defined in the user manual. I am NOT using -ppDisable.
However, I get screen output text that says I am using that option:
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer C:\\testfolder\\mrap\\idl\\ModeCommand.idl line 1 the usage of the '#include' directive in combination with the 'ppDisable' command-line option may lead to compilation errors. Consider removing the '-ppDisable' command-line option.
Is there some way to eliminate the gratuitous default to -ppDisable?
My IDL files must use #include statements to include other IDL.
Hello Ken,
That is odd.
Can you copy here the full
rtiddsgen.bat
command line you are using as well as the output fromrtiddsgen.bat -version
so we can try to reproduce that here?Thanks!
Gerardo
I will attach a text file that contains content of 2 IDL files (one includes the other), the batch file contents, and the screen output (Windows) followed by some questions.
Solved.
I was using a text editor (Notepadd++) which has options for text output. The default setting was Encoding in UTF-8. I toggled over to ANSI, and the odd stuff from rtiddsgen (3 odd chars at file start) disappeared and I got no warnings.
Those extra 3 chars at the front of the IDL file are not visible to WinMerge or other "file compare" tools, but "rtiddsgen" chokes on them.