Re: [Hamlib-developer] Yaesu FTX-1--target for 4.7.0?

[Nate B. <n0...@n0...>]

Good list, George.

* On 2025 19 Jun 14:04 -0500, George Baltz wrote:
> I do have a couple of things I would like to see in 5.0, and I've been doing
> some reading and doodling about them; nothing concrete yet, but here's my
> blue-sky ideas:
> 
> 1. Update the requirements for building/running/developing with Hamlib.
> 
>  * ANSI C is 35 years old - no need to support K&R C anymore.  I'd like
>    to see -std=c17 at least, but -std=c11 would still be better than c89.

I think that should probably a 5.0.0 target.  C11 would likely be
safest, even though these days C17 should be supported, though likely
only really well on distros less than five years old, I would guess.

I'm not sure what C standard MinGW/MSYS supports.

>  * 4.6.x won't compile without P_THREADS - make that an overt requirement.

This should be a 4.7.0 target.

>  * Split include/hamlib/rig.h so including rig.h gives the app access
>    to the whole API, but none of the structures - and guarantee this is
>    stable. Allows app developers to not worry about Hamlib internal
>    changes unless they explicitly need/include the structure definitions.

I would say this is a 5.0.0 target as the API is being changed
considerably and the promise is that such a change is signaled by
advancing the major version number.

> 2. Follow up on the cache move by breaking out the port and state
> structures.  Now I'm not sure we can make things transparent across
> 4.7<->5.0 - having cache inside state inside rig throws a monkey wrench into
> what I had hoped to do.

Your decision.  I get the sense you're leaning toward the 5.0.0 target.

> 3. Regarding thread safety; the answer could be 'yes', 'no', or 'which one?'
> There at least 4 different locking mechanisms in Hamlib.  None cover
> everything.  Current code(rig_lock()) fixes interference between some API
> calls and morse_data_handler() so CW works, and I think the Icom code
> handles their flavor of automatic updates.  The multicast stuff I haven't
> looked into, and the original morse_mutex() could now be replaced by a
> simple flag. And none of these look like a good candidate for the whole
> shebang.

This sounds like something that will be ongoing over the next several
releases and maybe not something easily confined to a single release
target.

> 4. The usual lineup of bug busting and feature/model requests.

+1

> Whew!  Writing that tells me I might have bitten off more than anyone can
> chew. Prioritize away!

This is exactly why I want there to be no more than two or three
priority items per developer for each release.  It frees up the mind
from feeling overwhelmed and trying to do everything at once.  Over the
past five years I observed Mike seemingly swamping himself in just this
manner and we had much too long time elapse from the last 4.5.x release
to 4.6.  Of course that time included his ALS fight so that likely was a
huge factor as well.

If I can help establish a process whereby we take smaller bites and make
more frequent releases, that is what I am hoping to achieve.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819