The other day a colleague of mine stumbled upon an issue (a bug perhaps) with the include guards in a C++ header file generated using the rtiddsgen tool. I have verified that the behavior is the same with the following versions of rtiddsgen: 5.0.0, 5.1.0 and 2.2.0.0 (rtiddsgen2).
We have two files with the same name, in different directories, whose contens are identical with the exception of the module declarations. Running rtiddsgen on these files produces identical include guards, which is quite problematic for obvious reasons.
I have created a simplified example of what we are doing...
Given the file "dir_a/file.idl":
module A
{
module B
{
struct StructA
{
boolean value_a;
double value_b;
};
struct StructB
{
StructA struct_a[5];
double value_b;
};
}; // module B
}; // module A
and the file "dir_b/file.idl":
module A
{
module Z
{
struct StructA
{
boolean value_a;
double value_b;
};
struct StructB
{
StructA struct_a[5];
double value_b;
};
}; // module Z
}; // module A
Running the following commands:
/opt/rti/ndds.5.1.0/scripts/rtiddsgen2 -language C++ -namespace -ppDisable -replace -inputIdl -verbosity 2 dir_a/file.idl
/opt/rti/ndds.5.1.0/scripts/rtiddsgen2 -language C++ -namespace -ppDisable -replace -inputIdl -verbosity 2 dir_b/file.idl
It appears as though the include guard numeric value, file_736668017_h, has nothing to do with the location of the file in the directory structure, but has more to do with the contents of the file, with the exception of the module declaration. I started to dig around the scripts and source code and noticed that this number is the "$executionId". I am not quite sure what this value is or how it is calculated, but am looking to some insight on how to make my example above work without modification to the RTI DDS source or scripts.
I believe that the example above is a valid use case am asking for insight on how to resolve. Thanks as always to anyone who could shed some light on the situation.
-Chad @ Lockheed Martin
Hi Chad,
The way the executionId is calculated is the sum of the Idl_name hashCode plus the size of the file. In your case turns out that that combination is exactly the same, so if you could modify one of the files just but adding one space/comment you would get a different number.
There is a hidden option called -ttGuard that changes the executionId to be thecurrent timestamp + the size of the file. In that case you would get a number that depend on when you run rtiddsgen so it won't be deterministic. Please note that as this option is hidden is not officially supported and may disappear in future releases.
I'm going to fill a RFE to see if we can change in the future the way we calculate that executionId to support your use case.
Best,
Aida
Aida,
Thank you for the detailed explanation, that certainly explains why the include guards were identical despite the difference in namespace.
We will go ahead and proceed with using the "-ttGuard" option despite the risk of it disappearing in a future release. Since we only check in the IDL files and not the generated files to our configuration control, the non-determenistic executionId should not be a problem for us.
-Chad @ Lockheed Martin