nmea0183 left overs from OCPN

[Hakansv]

In present collection there are two files with a not valid "extern" reference creating build errors. The files are seldom used by plugins but still there.
..\opencpn-libs\nmea0183\src\apb.cpp. Take out the (extern) for int g_NMEAAPBPrecision
..\opencpn-libs\nmea0183\src\response.cpp. Take out the (extern) for wxString g_TalkerIdText

Error example:

Creating library C:/radar/radar2/radar_pi/build/Release/radar_pi.lib and object C:/radar/radar2/radar_pi/build/R
  elease/radar_pi.exp
NMEA0183.lib(apb.obj) : error LNK2019: unresolved external symbol "int g_NMEAAPBPrecision" (?g_NMEAAPBPrecision@@3HA

[leamas]

Good catch, thanks! Probably not just to remove, will fix somehow anyway.

[leamas]

Filed OpenCPN/OpenCPN#3161. This actually reflects a bug in core OpenCPN and it should be solved there before we make anything here.

If you have an immediate problem building a plugin I for now suggest the manual work around:

• Create a directory libs/ if it does not exist.
• Copy the complete nmea0183 library from opencpn-libs to libs/
• Make hot fixes required in libs/nmea0183
• Update Plugin.cmake to include libs/nmea0183 instead of opencpn-libs/nmea0183.

[Hakansv]

Your insights have taken this to higher level to find the root cause.
Very good. Thanks
No immediate problem here. We have just deleted the "extern" call for the two mentioned variables and then he builds fine.

[leamas]

I am preparing a PR for main opencpn. There is now an updated version of opencpn-libs available in the devel branch. Since you reported this, could you possibly test?

Testing is done using something llike this:

$ cd opencpn-libs
$ git remote update origin
$ git checkout main
$ git fetch -f origin devel:devel
$ git checkout devel
$ cd ..
$ git add opencpn-libs
$ git commit -m "Updating opencpn-libs to devel branch"

EDIT: Of course, Plugin.cmake must be updated to actually use opencpn-libs for this to take effect.

[Hakansv]

Yes, seems to work. I made a test on ais-vd_pi
PKG_API_LIB is pointing to opencpn-libs
and I included:
add_subdirectory("opencpn-libs/nmea0183")
target_link_libraries(${PACKAGE_NAME} ocpn::nmea0183)
and it builds fine.

So now with api-18 I may start to find out out how to use N0183 listener.
This plugin would be a good candidate since it use only one rather rare N0183 message and constantly listen to all must be a waste of resources. I'll most certainly come back on that.
Thanks

[leamas]

I'll most certainly come back on that.

hm... I suppose you are about to re-read https://opencpn-manuals.github.io/main/opencpn-dev/plugin-messaging.html ? in that case, any feedback to that manual page is more than welcome, for example by editing it...

[Hakansv]

Yes I tried to follow that but didn't succeed at first attempt. Partly some api-18 issues and partly I don't understand "what's not said" or there by implication. (Me novice)
We may do it together further on? Would be interesting. I'll come back when time.

[leamas]

Please do. Zulip is probably a better channel for this.

First step would be to check that your "rare message" is supported in src/comm_bridge.cpp , not each and every message type is handled here (I think). If you make this check quickly, we might be able to get a patch into 5.8.2 if it's required.

[Hakansv]

Thanks for info about comm_bridge. I wasn't so far aware of that.
What the ais-vd_pi will receive is "VSD" and more particular the $AIVSD.
Either make comm_bridge to bridge all "VSD" and we filter for AIVSD in the plugin handle if the talker is available or just set up AIVSD in comm_bridge?

I suppose transmit of a message out from the plugin will still be handled by "PushNMEABuffer()"?

To zulip next? If so pls make a topic.

[leamas]

To zulip next? If so pls make a topic.

Done: Testing 0183 messages on new API