Keep comments (/**/) from IDL file through "rtiddsgen" to Java code

Hi Dan,

Can you supply an example idl file, that shows how you are inheriting?   Is this what you mean:

struct Inner {
    int foo;
};
struct Outer : Inner {
    int bar;
};

or this

struct Inner2 {
    int foo;
};
struct Outer2 {
    Inner2 inner;
    int bar;
};

and which field/variable will you be trying to comment out?

and can you give an example class idl, and hand-generated class mock-up, that shows what you are trying to do?

thanks,

The behavior of //@copy-java <comment>, when the directive is inside an "algorithmically processed" section, is to add <comment> whenever that section is processed. 

So when the copy-java is inside the struct definition, whenever the fields of the struct are processed, the <comment> will appear.  This is why it appears all over the place in the generated code.

The other thing to remember is that rtiddsgen treats //@copy directives (which are, from the standpoint of the IDL processing engine, comments), the same way that an XML stream parser treats a comment:  It is not clear to the parser (it is impossible to make it clear to the parser) whether that comment is a comment about what just happened in the stream, what is about to happen in the stream, or even has nothing at all to do with the stream. When the copy directive is seen in the stream, it is copied verbatim.

So, for

struct StartFrame {
   /**comment of dummy **/    
    octet dummy;
};

This is why it appears everywhere throughout the generated code (when it is inside the struct), or will appear in specific places inside a file, because those places show where the struct was reprocessed.

This will be the case with rtiddsgen, as well as rtiddsgen2 (supplied as experimental with 5.1.0). 

(note: I started this day before yesterday, got sidetracked... thought I'd lost it.  Sorry about the delay!)

Later versions of rtiddsgen2 may include an ability to supply user-defined behavior for user-defined directives (//@[text]).  With the current version, unknown user-defined directives are not processed at all (that is to say, in the current version, only support for //@ directives is supplied, for those that are supported).

This will be the case for both questions 1 and 2.  I will look at question 3 now.

rip

Question 3 is interesting and may reflect a bug in the rtiddsgen2 experimental shipped with 5.1.0 -- I don't get that line when I use rtiddsgen.

The conditions to reproduce are to have both an attempt at //@copy-java /**comment **/ inside the struct, and use of rtiddsgen2.  If I change either of those conditions, the odd line does not appear (that's a line in the templates, ie the syntax is not Java -- it's the velocity template engine syntax for a local method that should be processed, rather than copied into the output files.  My guess is that the inclusion of the comment in the IDL is causing the template parsing to get out of sync with the template.

Actually, let me restate -- that is a bug in the templates.  I've just spent an hour digging through the templates.   If it turns out to be an unknown bug, I'll file it.  The problem is in resource/rtiddsgen/templates/java/TypeSupportMacros.vm -- at the point that line is emitted, the macro could check to see if it is a directive (//@) but doesn't.  The $member is a directive at that point, but the macro treats it as a data field.

Thank you!

It could be possible to alter the templates to prevent the comments from ending up everywhere.  But that would be unsupported because it would be for your installation only, and I don't know how much work it would be in any case.

I would start by defining a custom directive

//@copy-java-type-only and then you could use "  #if ($member.directive=="copy-java-type-only")  "  and "  ${member.value}  " where appropriate, to enable/prevent the output as needed

but first, you would have to learn the template language :)

Rip