update exporters to export static UIDs if available

[nwesem]

Changes:

• update binary exporter, c parser, and go parser such that staticUID can be used (and is shown while travsersing)
• update csv exporter to export extended attributes
• update franca exporter to export extended attributes
• update graphql exporter to export extended attributes
• update idl exporter to export extended attributes
• update json exporter to export extended attributes
• update protobuf exporter to export extended attributes
• update yaml exporter to export extended attributes

How to verify:

First you have to create an ID file with

poetry run vspec2id ../vehicle_signal_specification/spec/VehicleSignalSpecification.vspec out_id.vspec

Now we check all exporters:

1. try binary export (there are a few more steps needed here, but should be working now)

   cd binary/
   make # this will make current version of the `binarytool.so` library used by the vspec2binary exporter
   cd ..
   poetry run vspec2binary -u ../vehicle_signal_specification/spec/units.yaml out_id.vspec vss_no_val.bin
   # now go to cparser and compile it
   cd binary/c_parser
   cc testparser.c cparserlib.c -o ctestparser
   ./ctestparser ../../vss_no_val.bin
   # now you should be able to traverse the tree and see all staticUIDs using the ctestparser
   # for go
   cd ../go_parser
   go build -o gotestparser testparser.go
   ./gotestparser ../../vss_no_val.bin

   If you want to test that it still works without staticUIDs:

cd ../../ # to vss-tools base dir
poetry run vspec2binary ../vehicle_signal_specification/spec/VehicleSignalSpecification.vspec out.bin
cd  binary/c_parser
./ctestparser ../../out.bin

2. try csv export and check results

   poetry run vspec2csv out_id.vspec out.csv -u ../vehicle_signal_specification/spec/units.yaml -e staticUID

3. try idl export

   poetry run vspec2ddsidl out_id.vspec out.idl -u ../vehicle_signal_specification/spec/units.yaml -e staticUID
   # then try parsing it with idlc
   # on this branch we still need to add cyclonedds to run idlc
   poetry add --group dev cyclonedds
   poetry run idlc -l py ./out.idl

4. try franca export

   poetry run vspec2franca out_id.vspec out.franca -u ../vehicle_signal_specification/spec/units.yaml -e staticUID

5. try graphql export

   poetry run vspec2graphql out_id.vspec out.graphql -u ../vehicle_signal_specification/spec/units.yaml -e staticUID

6. try json export

   poetry run vspec2json out_id.vspec out.json -u ../vehicle_signal_specification/spec/units.yaml --json-pretty -e staticUID

7. try protobuf export and check results

   poetry run vspec2protobuf out_id.vspec out.pb -u ../vehicle_signal_specification/spec/units.yaml -e staticUID

8. try yaml export

   poetry run vspec2yaml out_id.vspec out.yaml -u ../vehicle_signal_specification/spec/units.yaml -e staticUID

[nwesem]

Would this be valid .idl output including staticUIDs? for leaves it should be correct, but I'm currently wondering how to attach the static UIDs to branches, would it work like shown below? Sadly, I can't get the idlc parser to run it even seg faults from a file generated from master branch..

module Vehicle
{
const string staticUID ="0x35AFD7A7";
module ADAS
{
const string staticUID ="0x206A4E82";
module ABS
{
const string staticUID ="0xCE6D5634";
struct IsEnabled
{
boolean value;
const string type ="actuator";
const string description ="Indicates if ABS is enabled. True = Enabled. False = Disabled.";
const string staticUID ="0x6BAFEF4E";
};
struct IsEngaged
{
boolean value;
const string type ="sensor";
const string description ="Indicates if ABS is currently regulating brake pressure. True = Engaged. False = Not Engaged.";
const string staticUID ="0xAAF08F7B";
};
struct IsError
{
boolean value;
const string type ="sensor";
const string description ="Indicates if ABS incurred an error condition. True = Error. False = No Error.";
const string staticUID ="0x75B9DC6A";
};
};

[adobekan]

MoM: Let's have a look.. We need time to review this.

[nwesem]

hi @erikbosch, do you have any info on the (dds)idl exporter? could you take a quick look at my comment above? Maybe you have an idea how to add attributes to branches in idl files? For me there is no way to check if my implementation is correct as I can't get the idlc parser running (seems like the documentation is outdated)..

Edit: In case you are not that familiar with the (dds)idl related code maybe there is somebody else in covesa that is?

[erikbosch]

hi @erikbosch, do you have any info on the (dds)idl exporter? could you take a quick look at my comment above? Maybe you have an idea how to add attributes to branches in idl files? For me there is no way to check if my implementation is correct as I can't get the idlc parser running (seems like the documentation is outdated)..

Edit: In case you are not that familiar with the (dds)idl related code maybe there is somebody else in covesa that is?

I do not think that anyone has worked on DDSIDL lately. I do not think the structs support const, that is why they add that as comment in generator

struct Minor
{
unsigned long value;
//const string type ="attribute";
//const string description="Supported Version of VSS - Minor version.";
};

I created a simple test case in #379 to update instructions, they seemed to be mashed up. Also a simple test case to verify that output is accepted. I honestly do not know if the ddsidl generator is useful as of today, or if it rather should be deprecated.

[erikbosch]

Conflicts! Also added @UlfBj as reviewer as it concerns the "binary" tool quite a lot. Ulf - could you check how much implications this would have for VISSR. As it is for a major VSS(tools) release I guess that some required changes in VISSR is acceptable.

[nwesem]

Conflicts!

Yes I already rebased once will do it again later today

[erikbosch]

@nwesem - still conflicts

[erikbosch]

MoM:

• To be reworked when the other PR is done