Next Step: API Update from 116 to 118

[rgleason]

See https://github.com/rgleason/watchdog_pi/issues/70 There is a small bug in version numbering when a user installs a Beta plugin and then switches and updates to Master catalog, the version number shown is from the master catalog rather than the plugin version installed. Leamas advises this can be corrected by updating to API 118. Updating to API 118 then means only O5.8 can be built.

Also see how Shipdriver is done https://github.com/Rasbats/shipdriver_pi/blob/master/UPDATE_PLUGIN_API.md We need to develop a list of steps like this, or can it simply be changed in the template? I think it may have to be a little of both template and a documented list. Also note that Autotrackraymarine is using API118

Of course once this is done, OpenCPN 5.6.2 plugins cannot be built unless we have added code to make the choice of API at the time of compiling, as Steve Adler (TwocanPlugin) has suggested. (See the next post below)

[rgleason]

I found Steve Adler's 8/30/23 email regarding conditional building based on OpenCPN 5.6 and 5.8

Re ocpn_plugins.h and opencpn.lib, I updated these ages ago in my own repo. BTW, That was my interest in using a git submodule

For developing plugins that support multiple versions of O and take advantage of newer API's and features in new versions of OpenCPN, I think I've come up with a solution that may work. Essentially it is how can we carry over an environment variable into a source file so we can do conditional compilation.

In the circleci config.yml we can set an environment key. (Similar to how the WX_VER environment variable is set today)

environment: OCPN_TARGET_VERSION: ​_OCPN_58

That means you could have different circleci jobs, that target different versions of OpenCPN.

Then in a CMake file we can add something like the following:

IF ($ENV{OCPN_TARGET_VERSION} STREQUAL "OCPN​58")

Do some conditional stuff such as adding the correct folder for ocpn_plugins.h or adding the correct LINK_LIBRARY statement

ELSEIF ($ENV{OCPN_TARGET_VERSION} STREQUAL "_OCPN​_56")

• Do some other conditional stuff such as adding a different folder for ocpn_plugins.h and link to the correct version of opencpn.lib ENDIF()

Then in a CMAKE CONFIGURE_FILE statement add something like the following to an in file (look at what we do today in version.h.in)

  #define $ENV{OCPN_TARGET_VERSION}

Finally in the source files we can use something like

#if (defined _OCPN​_5_6_)
       Do something that is supported on OpenCPN 5.6 (eg. use the SetNMEASentence API)
#elif (defined _OCPN_5_8)
       Do something that is only supported on OpenCPN 5.8 (eg. use the new NMEA 2000 Listener classes)
#endif

We kind of do some of this today for the WX_VER stuff, although it doesn't get carried through into the source files.

Steve's plugin TwoCan_pi is here https://github.com/TwoCanPlugIn/TwoCanPlugIn

Perhaps he has done this?

[rgleason]

We have two choices:

1. Build all the API116 plugins for both O5.6 and O5.8, after completing the sublibs changes, then push to plugins, so that we at least have some metadata that is for O5.6 that will be left in place. Then change all plugins to use API 118 and build only O5.8 and push those to plugins.
2. Implement Steve's idea above and continue building O5.6 and O5.8 and we can then turn off O5.6 after a couple of builds and leave the previous metadata in place in plugins.

[rgleason]

Dave reports:

Using opencpn-libs as a submodule provides the machinery to select API level at build time. eg:

add_subdirectory(${PROJECT_SOURCE_DIR}/opencpn-libs/api-16)
target_link_libraries(${PACKAGE_NAME} ocpn::api)

What is missing is the switch logic in the CI build scripts.

[rgleason]

From bdbcat: Move to API-16 to API-17 so we can still build PI for O5.6.2 For plugins now at API-18 such as autotrackraymarine simply keep them at API-18