Update analyzer to automatically build binaries using github actions

[nbanerje]

Hi! I'm a Product Manager at Saleae and we’ve made improvements to our analyzer build process. Specifically, we cleaned up the build system, and switched to cmake, so there aren't multiple project files anymore. By implementing the changes outlined here you will be able to provide the community automatic builds in addition to a simplified build system. Let us know if you think you can make the changes or if you’d like us to make the changes for you.

Additionally, if you would like to update your analyzer so that results appear in Logic 2’s data table you can follow the steps outlined here. Note that if you upgrade your analyzer to FrameV2 it will not be backward compatible with Logic 1.

We really appreciate your time and effort! Please let us know if you have any feedback or questions. Thanks!

[joca-hms]

@nbanerje,

Regarding the issue topic Update analyzer to automatically build binaries using github actions

• This repo already has github actions which build the project but currently they are only used to report the build-status for each supported platform (Windows/Linux/macOS) on README.md.
• I assume the request or point being made here is to add an additional step in the workflow which generates/publishes a release. Currently, this is a manual endeavor, but I think there is merit in updating the workflow to support this. I will investigate what the best path is for this and look at the Saleae repo for any guidance/examples.

Regarding CMAKE,
I have a cmake commit in the dev-joca branch which has been in limbo for quite some time. I believe there were one or two minor issues which I was hoping to resolve in this approach. Ultimately I need to revisit this task to refresh my memory on the specifics.

Regarding FrameV2,
I have explored the possibility of supporting V2 but I am still unsure of whether or not it would be worth it. Unfortunately, the V2 software does not support some of the behaviors that this plugin exhibits. These have been discussed numerous times on the Saleae forum so I will not drive into this topic any more here. The question comes down to whether or not there is value in using V2 over V1 that justifies (possibly) substantial changes to how the plugin works. This is something I have not decided on yet and it requires further investigation.

• With that said the idea of supporting HLAs with this plugin does sound interesting and could offer the option for our customers to define HLAs that add additional verbosity to the application-specific data that is encapsulated within the ABCC SPI protocol.
• One thing I would like to understand more is whether or not the start/end times need to match between a V1 and V2 frame. In some ways I see the V2 Frame as a better fit for what V1's "packet" was. So I might want to add in V2 functionality by passing all V1 frames for a given V1 packet into a method that reprocesses them as a V2 frame (if that makes any sense).