Use of //@copy-declaration in IDL files that are included by other IDL files

6 posts / 0 new
Last post
Offline
Last seen: 10 years 3 months ago
Joined: 12/08/2011
Posts: 10
Use of //@copy-declaration in IDL files that are included by other IDL files

Hello everybody

I am seeing some odd behavior when I use the @copy-declaration directive in IDL files which are included in other IDL files. Here is an example:
Let's say I have the file  base.idl with the following content:

module IDL {
//@copy-declaration // A Data
struct A {
  double i;
};
}; // end module IDL

//@copy-declaration #include <QtCore/QMetaType>
//@copy-declaration Q_DECLARE_METATYPE(IDL::A);

and a file  extended.idl with this content:

#include "base.idl"

module IDL {
struct Container {
  A a;
};
}; // end module IDL

Simply running  rtiddsgen -language C++ -namespace base.idl, followed by rtiddsgen -language C++ -namespace extended.idl results in code that cannot be compiled as the @copy-declaration directive results having the respective fragments not only copied into "base.h, but also into the top part of extended.h, which starts like this (again, this is only the top part of the file):

/*
  WARNING: THIS FILE IS AUTO-GENERATED. DO NOT MODIFY.

  This file was generated from extended.idl using "rtiddsgen".
  The rtiddsgen tool is part of the RTI Connext distribution.
  For more information, type 'rtiddsgen -help' at a command shell
  or consult the RTI Connext manual.
*/

#ifndef extended_53651664_h
#define extended_53651664_h

#ifndef NDDS_STANDALONE_TYPE
    #ifdef __cplusplus
        #ifndef ndds_cpp_h
            #include "ndds/ndds_cpp.h"
        #endif
    #else
        #ifndef ndds_c_h
            #include "ndds/ndds_c.h"
        #endif
    #endif
#else
    #include "ndds_standalone_type.h"
#endif


#include <QtCore/QMetaType>

Q_DECLARE_METATYPE(IDL::A);

#include "base.h"


namespace IDL{

        
extern const char *ContainerTYPENAME;
        
// ...
}

As you can see, it appears that #include base.idl not only results in a  #include base.h, but it also somewho seems to trigger the inclusion of the code marked with @copy-declaration (well, I gess since extended.h is a header file, it technically is a declaration).


Could anybody tell me whether this is simply user error on my side and how to only get code copied into "base.h" ?


Thanks for your efforts.


Claus


PS: I pasted the full base.h at http://pastebin.com/rKZzRGdq and the full extended.h at http://pastebin.com/mGkVexXN. Furthermore, the two IDL files and the resulting code is also in the attached ZIP archive.

AttachmentSize
Package icon rtiddsgen_copy-declaration_test.zip19.61 KB
fercs77's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 01/15/2011
Posts: 30

Hi Claus, 

You are running into bug CODEGEN-507. A possible workaround for the problem consists on guarding the type Q_DECLARE_METATYPE as follows:

//@copy-declaration #ifndef TYPEDEF_IDL_A 
//@copy-declaration #include <QtCore/QMetaType>
//@copy-declaration Q_DECLARE_METATYPE(IDL::A);
//@copy-declaration #define TYPEDEF_IDL_A
//@copy-declaration #endif
 
Once the bug is fixed, its reference (CODEGEN-507) will appear in the release notes of the GAR containing the fix.
 

Regards,

    Fernando

Offline
Last seen: 6 years 6 months ago
Joined: 01/17/2013
Posts: 23

Hi Claus,

Another workaround you could use, if you don't need to use the preprocessor (because you don't have any preprocessor directive in your extended.idl as in the example) would be to generate separately the code for the base and the extended file disabling the preprocesor. i.e.,

rtiddsgen -language C++ -namespace -ppDisable extended.idl

This way you only will have the  #include "base.h" in your  extended.h file but you won't have any information about the base.idl file in the extended one. As you have already generated code for the base.idl you shouldn't have a problem to compile the code.

Regards,

Aída

 

 

 

Offline
Last seen: 10 years 3 months ago
Joined: 12/08/2011
Posts: 10

Thanks for the proposed workarounds fercs77 and aida.

As I call rtidesgen in a custom build step in my cmake setup, adding the  -ppDisable command would have been a little tricky. For now I am using the include guards.

Thanks again,

Claus

Gerardo Pardo's picture
Offline
Last seen: 1 week 5 days ago
Joined: 06/02/2010
Posts: 602

Note that this was fixed in RTI Connext DDS version 5.1.0 released in February 2014.

Gerardo

Offline
Last seen: 6 years 6 months ago
Joined: 02/24/2015
Posts: 7

@hcc23,

I appologize for bringing up an old thread, but I can't find a way to send a direct message to you through these forums.  You mention using a cmake custom build step to call rtiddsgen.

I'm looking for a cmake find_package and automated method to call rtiddsgen on IDL files within my cmake build.  Is it possible to send me some of your cmake files to expedit my port of our existing code that uses RTI DDS to a cmake build system?

Thanks,

-Ryan