I have an IDL file with multiple structs/types. When I generate the type support files with rtiddsgen, only the last type in the IDL file is generated in the FooSupport.h and FooSuport.cxx files. Is there a way to tell rtiddsgen to generate all the types in the IDL file or do I have to place each type in a seperate IDL file and generate each individually which would be very tedious.
Hi,
Yes there is.
You need to use the
//@top-level
directive to mark each type for which you want top level type support (DDS DataWriter, DataReader and TypeSupport) to be generated. Otherwise it defaults to only generating these for the last type in the file as you noted.For example:
Gerardo
Hi Gerardo,
Thank you for your response. I was able to get the desired result using //@top-level true but the behavior that I observed was inconsistent with the manual and may be a bug in the parser.
I was already using //@top-level false which in retrospect, was the source of the problem. But based on the manual which says that by default rtiddsgen will generate type-specific methods for all structs in an IDL file (section 3.3.8.4), I assumed that each struct would default to //@top-level true if not specified explicitly which is not the case. Here is a sample of what I had and was only getting the last type:
It seems that rtiddsgen treats the top-level flag as a global toggle and once it's set to true or false, it remains that way for all types following that point until it's explicitly toggled by another //@top-level directive. The only exception I found is that if it does not find any top-level structs by the time it reaches the last struct in the IDL file, then regardless of whether or not there is a //@top-level false directive on that last type, it will always generate it, probably because it has to have at least one type to create the file. An easy workaround obviously is to specify the //@top-level true/false directive on every type so that there is no ambiguity.
pj
Oh I see. Thank you for tracking this down!! I have filed a bug aganist the
rtiddsgen
parser (issue number is CODEGEN-628) to correct this behavior.Thank you
Gerardo
I also encountered this problem and reported it in January, 2013. The bug at that time was recorded under CODEGEN-544.
I've been working around it by explicitly setting //@top-level for each and every type.
-Todd