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.
Attachment | Size |
---|---|
rtiddsgen_copy-declaration_test.zip | 19.61 KB |
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:
Regards,
Fernando
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
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
Note that this was fixed in RTI Connext DDS version 5.1.0 released in February 2014.
Gerardo
@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