Hamlib 4 compatibility

[xylo04]

goHamlib is working well with the computers on which I have hamlib 3.3, but when attempting to compile against hamlib 4.1 (on Mac via homebrew) I get errors:

# github.com/dh1tw/goHamlib
rig.c:70:31: warning: passing 'int *' to parameter of type 'vfo_t *' (aka 'unsigned int *') converts between pointers to integer types with different sign [-Wpointer-sign]
/usr/local/Cellar/hamlib/4.1/include/hamlib/rig.h:2308:35: note: passing argument to parameter 'vfo' here
rig.c:333:46: warning: passing 'int *' to parameter of type 'vfo_t *' (aka 'unsigned int *') converts between pointers to integer types with different sign [-Wpointer-sign]
/usr/local/Cellar/hamlib/4.1/include/hamlib/rig.h:2423:41: note: passing argument to parameter 'tx_vfo' here
rig.c:408:39: error: too few arguments to function call, expected 4, have 3
/usr/local/Cellar/hamlib/4.1/include/hamlib/rig.h:2595:1: note: 'rig_set_ant' declared here
rig.c:423:39: error: too few arguments to function call, expected 7, have 3
/usr/local/Cellar/hamlib/4.1/include/hamlib/rig.h:2600:1: note: 'rig_get_ant' declared here
rig.c:583:8: error: use of undeclared identifier 'RIG_LEVEL_VOX'
rig.c:652:8: error: use of undeclared identifier 'RIG_LEVEL_VOX'
rig.c:702:8: error: use of undeclared identifier 'RIG_LEVEL_VOX'

[dh1tw]

Hi @xylo04,
with each major version (3.x.x, 4.x.x, ...) , the Hamlib team allows breaking changes in the API. So the errors you describe are actually expected, since goHamlib doesn't support hamlib version 4 (yet).

I think we could cover these changes by introducing conditional checks in goHamlib for the known API changes between Hamlib3 and Hamlib4. Probably making hamlib 4 the default and covering hamlib 3 compatibility with conditional checks.

Hamlib actually provides the library's semantic version in the const char hamlib_version [] string located in hamlib/rig.h. As far as I remember, this constant was introduced with version 3.x.
Since it wasn't available with version 1.x, I had to do some hacky conditional testing.

Maybe it's also time to deprecate the support for version 1.x and focus on supporting version 3 and version 4.

So, I guess we have to

• export the version constant in a go variable / constant.
• identify the breaking changes between hamlib 3 and 4 and handle them in conditional checks within the particular functions.
• adopt the tests for using the hamlib version

hw?

Tobias

[BigNerd95]

What about using again c-for-go like you did some years go?
https://github.com/dh1tw/hamlib-go
I know you don't like its syntax, but maybe it is easier to maintain

[dh1tw]

I can certainly see the advantages of using an automated tool for generating API bindings automatically. Don't get me wrong, I'm not against them. But so far, non could really convince me. I poked around with SWIG and c-for-go. The quick win is certainly there, but once we dig into edge cases, it's where the problems start.
For example, supporting C libs with ABI incompatibilities (e.g hamlib3 vs hamlib4) isn't really covered and still requires manual programming. Since most of the code for this particular binding is already written, I guess I'll stick to what exists for the time being.

[xylo04]

Hi @dh1tw, circling back on this (was this really a year ago?), I think introducing a new major module version would be appropriate. We could even call it v4 to align with the Hamlib version. That blog post recommends using a subdirectory per major version, but I've actually seen it more often done as branches. For example, that's what I've done with my wsjtx-go repo; the default branch is now v4 instead of main.

With this strategy, any development needed for hamlib v3 (and v1) can continue on the master branch, and the v4 branch can be pristine and not have to make any hacky conditional testing.

What do you think?

[xylo04]

Oh yeah, and I forgot that #14 was still hanging out there.