[Hamlib-developer] const breakage, plans for very-near-term 4.6.1??

[Greg T. <gd...@le...>]

Greg Troxel <gd...@le...> writes:

I wrote earlier about problems after upgrading hamlib to 4.6:

> I see
>
>         * rig_caps is no longer constant -- this may break some 3rd party relying on the "const" declaration.  Here's an example of how to handle compatibility.
> 	    #ifdef RIGCAPS_NOT_CONST
> 	    static int add_to_list(struct rig_caps* rc, void*)
> 	    #else
> 	    static int add_to_list(const struct rig_caps* rc, void*)
> 	    #endif
>
> but I don't understand what's going on and why.  It makes sense that
> when supplying a function to an iterator, that the function is not
> allowed to modify.  And I don't see why passing a non-const to a
> function that promises not to modify is trouble.

I am still not following.  But, I found that out of 4 installed programs
that depend on hamlib, 3 of them (xlog, fldigi, freedv) would no longer
compile).  It seems gpredict doesn't use rig_caps.

I've reported problems upstream to xlog and freedv; pkgsrc's fldigi
entry is behind and it isn't reasonable to report bugs against old
releases.

  xlog: https://savannah.nongnu.org/bugs/index.php?66598a
  freedv: https://github.com/drowe67/freedv-gui/issues/806


I see

  https://github.com/Hamlib/Hamlib/commit/f2a9f091d08667db9d3fc2e842a427af7cfb990e
  https://github.com/Hamlib/Hamlib/commit/b3ef41354d9c7f97959e65d09aadb53bbb1d3232

which is reverting the the API change to `rig_list_foreach`.

Packaging systems are in a bind here, if they have updated to 4.6.
Depending packages do not have releases that work with the new API, and
given the intent to undo the change, are not likely to publish them.

I would therefore suggest immediately (within a few days) creating 4.6.1
as 4.6 plus those two commits cherry-picked, so packaging systems that
did update to 4.6 can just update to 4.6.1.

73 de n1dam