Coexist fastcdr v1 and v2 #254
Conversation
richiware
force-pushed
the
future/v2.12.1
branch
from
6ad37f5 to
87a05ca
Compare
Signed-off-by: Ricardo González Moreno <ricardo@richiware.dev>
richiware
force-pushed
the
future/v2.12.1
branch
from
87a05ca to
175f924
Compare
| #if FASTCDR_VERSION_MAJOR == 1 | ||
| payload.length = (uint32_t)ser.getSerializedDataLength(); //Get the serialized length | ||
| #else | ||
| payload.length = (uint32_t)ser.get_serialized_data_length(); //Get the serialized length | ||
| #endif // FASTCDR_VERSION_MAJOR == 1 |
There was a problem hiding this comment.
I think I liked it better defining the macro substituting one API call from the other as you did in Fast DDS. But it can be kept as it is.
|
|
||
| $if(struct.allIdentifiedMembers)$ | ||
| #if FASTCDR_VERSION_MAJOR == 1 |
There was a problem hiding this comment.
Who is setting the build option? Fast DDS-Gen can be used without any Fast CDR in the workspace. Fast CDR is required to run the test suite and to build the generated code. Consequently, in case that a user is generating code and Fast CDR is not found in the workspace, which is the default value with which Fast DDS-Gen is going to generate the code?
Also, the scope of this task is to support Fast CDR v1 with Fast DDS v2.12. Even though types are only updated with minor releases, Fast DDS types would need to be regenerated in order to support Fast CDR v1. However, any user might want to upgrade its types using the latest Fast DDS-Gen version and it could be that annotations that were previously ignored are applied. Consequently, I think that if this PR is considered for merging, we should ensure that the CI is working (that is, that the annotations that were ignored previously are ignored if Fast CDR v1 is detected in the workspace). I suppose, the questions that need to be answered are:
- Vulcanexus Iron and Humble are going to be released with Fast DDS v2.12.1 and Fast CDR v1.1.x, but which Fast DDS-Gen version is going to be included?
- A user upgrades locally to Fast DDS v2.12.1 and keeps using Fast CDR v1.1.x but he upgrades to Fast DDS-Gen v3. Do we have to issue an incompatibility message as it is done if Fast DDS-Gen v2 is used with Fast CDR v2? If not, then the CI should pass with the older version of Fast CDR v1.
| @@ -435,3 +731,183 @@ string_type(ctx, string) ::= <<>> | |||
| wide_string_type(ctx, wstring) ::= <<>> | |||
|
|
|||
| array_declarator(ctx, array, array_type) ::= <<>> | |||
|
|
|||
| // FASTCDR_VERSION_MAJOR Remove | |||
There was a problem hiding this comment.
I think this note was to remind you of something, but I do not think it is intended to be merged.
| $elseif(map_entry_member.value.typecode.contentTypeCode.isAliasType)$ | ||
| $if(map_entry_member.value.typecode.contentTypeCode.contentTypeCode.isEnumType)$ |
There was a problem hiding this comment.
This should be recursive
|
Close in favor of #256 |
No description provided.