Hi Greg,
The points you mention, of course, are the main reasons why rig-control
issues seem to require >90% of our programming effort. It's also why
there is no rig control in MAP65 or in the original WSJT -- that
convenience is not really needed for meteor scatter or EME (although no
doubt some folks would like to have it).
It's also why WSPR, which needs rig control in order to do "band
hopping", used the relatively simple expedient of invoking the
rigctl[.exe] executable and effectively saying "if hamlib doesn't
support your rig, and you can't fool it by using a similar rig, perhaps
from the same manufacturer, you're out of luck until hamlib is updated."
-- Joe
On 11/12/2014 3:14 PM, KI7MT wrote:
> From what I can gather, it's been just over two years since a formal
> update was publisged. Bill probably has a much better intel on this than
> I do, as he works with Nate on various elements. From where I sit,
> there's 3 rational options and one not so popular idea.
>
> - The ideal situation, not just for the WSJT group, would be to get some
> level of update published from the Hamlib team, but I have no idea how
> far out that is. Something is better than nothing at this point.
>
> - Publish a shared-dev version to link against, one that can die off (
> become deprecated ) as the formal Hamlib is released, a transitional
> package of sorts. This done in allot of cases, py2 to py3 for example.
>
> - Publish a fork, be it static or shared. Or, maybe just include the
> Hamlib source code along WSJT-X Source code and be done with it. Then
> build both elements separately.
>
> - Last and I'm sure not very popular, de-leverage the WJSTX application
> from Hamlib.
>
> Having WSJT-X tied to Hamlib this way has been frustrating for a long
> time. Especially as there seems no real target date ( maybe there is,
> and it's just not published or something ) or milestone for releases exists.
>
> As it stands now, I would be included to publish pre-built packages
> somewhere until this gets sorted out properly. Builds can easily be done
> today with minimal time invested at each even turn.
>
>
> On 11/12/2014 12:03 PM, Bill Somerville wrote:
>> On 12/11/2014 18:41, Joe Taylor wrote:
>>> Hi Bill and all,
>> Hi Joe,
>>>
>>> Back to more-or-less normal here, after a busy weekend in the ARRL EME
>>> Contest -- a total of 215 QSOs by our multi-op crew. :-)
>> That's impressive.
>>>
>>> I just wanted you to know that I have now done both a "Type 1" and a
>>> "Type 2" build using your Superbuild script. Both worked without
>>> problems.
>> Unfortunately the concept has hit yet another road block on the route to
>> acceptance by the official Linux distributions. The bundling of a fork
>> of hamlib or just the use of a fork of another project internally is not
>> really acceptable so we may have to wait until the hamlib team catch up
>> and get their v3 release into the distributions before we can proceed
>> smoothly. This basically boils down to the need for the distribution
>> maintainers to control the patching of all sources that they distribute
>> from. I can sort of see their point but there has, at some point, to be
>> a boundary of the domain of the application developers responsibility
>> and the distribution managers. OTOH I don't think we want to be adopting
>> hamlib in any way, they have a product in the field and offer support
>> etc. for it and we must be careful not to step in inadvertently and find
>> ourselves inflating the WSJT-X sources with the hamlib sources and the
>> consequential support requirements.
>>
>> We might be able to progress a little further if I generate a giant
>> patch of the differences between the current released hamlib2 and what
>> we are using. This may be more acceptable and the superbuild script can
>> be fairly easily adapted to use such a patch as it already has patching
>> capabilities. I will try an progress this soon after kvasd matters are
>> resolved. Update on that to follow.
>>>
>>> The man pages for wsjtx, jt65code, and rigctld-wajtx also look very
>>> nice. Many thanks for setting these up!
>> These are a requirement of Linux packaging for the official
>> distributions. Every executable must have a manpage.
>>>
>>> -- Joe, K1JT
>> 73
>> Bill
>> G4WJS.
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
