Beta Test / Technical

[rgleason]

I am incredibly impressed with the range and depth of knowledge of many of the talented programmers working on opencpn and the plugins. I am reminded daily of how little I know!


When I rename my opencpn.ini for reuse later, and restart O to create a new blank opencpn.ini, what happens is all my chart SENC get deleted. I do this fairly frequently and it involves recreating the SENC when I reinstate my saved opencpn.ini.


Should/can I rename my SENC file and just make a new blank one, so that I can save that work and then rename it back when I go back to my original opencpn.ini?


Any thoughts?


Is there any chance I could just tell it to stop, and have it pick up again when I restart O?


Sometimes I think it is repeating scans of some of the chart directories. Is that possible? I finallly finished.

[bdbcat]

Rick....


re:

Should/can I rename my SENC file and just make a new blank one, so that I can save that work and then rename it back when I go back to my original opencpn.ini?


Yes, you may. SENC files are system and filesystem agnostic. I have captured a master file of all NOAA SENCs built by O5, and sometimes upload them manually to new machines, even Android devices, in order to save time.


Good Luck
Dave

[rgleason]

Originally Posted by bdbcat

Rick....
re:

Should/can I rename my SENC file and just make a new blank one, so that I can save that work and then rename it back when I go back to my original opencpn.ini?


Yes, you may. SENC files are system and filesystem agnostic. I have captured a master file of all NOAA SENCs built by O5, and sometimes upload them manually to new machines, even Android devices, in order to save time.


Good Luck
Dave

Awesome. Huge timesaver. Thank you.

[rgleason]

Github News:
next step in secure software development with GitHub
https://live-stream.github.com/?utm_...estream-091719
Also Semmle joins with Github
This will all be good.

[rgleason]

Regarding the current version of Squiddio, the appveyor files are using what I believe to be opencpn.lib (146 kb), possibly v5.01 from the special MacOS changes?

Squiddio appveyor (for Windows)

https://downloads.sourceforge.net/pr...libopencpn.lib (146 kb)

I have been using the opencpn.lib (126 kb) for version 5.00 and squiddio shows several errors.

Can someone please confirm which version we should be using now? and what plugin API version each one is?
opencpn.lib (126 kb) for Opencpn v5.0.0
opencpn.lib (146 kb) for Mac v5.0..1?

Also please advise specifically about compatibility of these two versions with Opencpn v 5.0.0.

Also I would like to get this Dev Wiki page properly updated to reflect the last few API steps correctly.
Different Plugin API Versions

[bdbcat]

Rick...


There is no concept or need for opencpn.lib on Mac. This is purely a Windows creation, an artifact of an intermediate build step.



As a general rule, on Windows, if thh opencpn.lib is wrong, or corrupted, then a plugin built using that opencpn.lib will simply fail to load.


What errors are you seeing on Windows?


Hope this helps.


Dave

[rgleason]

Sorry for the confusion, and conflating MacOS and Windows builds. ...so I must have had a corrupted or wrong opencpn.lib -- Main problem solved, but I have a question still.

I believe the opencpn.lib (126 124 kb) that I am using is from Opencpn v5.00 of March 22 (The files do not open on github so I cannot compare them right now.)

When I compile locally, the most current squiddio_pi with Jon Gough's changes, branch od_fixes when using v5.00 opencpn.lib (124kb) now builds without errors!

The thing that puzzles me is that the appveyor file (-Jon changed this file I believe) uses an opencpn.lib (146 kb) from https://downloads.sourceforge.net/pr...libopencpn.lib

These are different file sizes, is this file also from v5.0.0? This version does build without errors and is the build that the downloads page references. Why are these opencpn.lib different sizes? Where did the 146kb one come from?

Which one should I be using for building Opencpn v5.0.0 plugins now?

[bdbcat]

Rick...
I do not know where the various version of opencpn.lib in circulation have come from.
But it really does not matter. The plugin build process does not use any executable code from the opencpn.lib. It is only used by Windows to confirm the method signatures of the plugin callbacks, so that it will link correctly at run-time.
So, bottom line: any 5.0.x lib should work, as long as the plugin uses API calls defined in 5.0.x.


Dave

[rgleason]

Ok, I think I understand. If it builds without errors, and contains the v5.0.0 API it should work, and don't be concerned about the different sizes of the two files.


If the opencpn file has been extended for some reason by adding a couple of new items, without changing any existing items, and there has been no change in wxWidgets, that file would still be ok to use for building v5.0.0 plugins, because all of the v5.0.0 items exist in the opencpn.lib file as a subset. - Correct?

So generally, ok to use v5.0.1, or whatever, opencpn.lib for v5.0.0 plugins.


====
I believe the wiki Plugin API page is missing some info at the bottom about recent opencpn.lib versions, because there is a larger 146kb version on sourceforge that is being used (certainly by Jon Gough). I will track it down eventually and update the wiki page if necessary.

Originally Posted by bdbcat

Rick...
I do not know where the various version of opencpn.lib in circulation have come from.
But it really does not matter. The plugin build process does not use any executable code from the opencpn.lib. It is only used by Windows to confirm the method signatures of the plugin callbacks, so that it will link correctly at run-time.
So, bottom line: any 5.0.x lib should work, as long as the plugin uses API calls defined in 5.0.x.


Dave

[rgleason]

The v4.99 one on https://sourceforge.net/projects/ope...1405-vc141_xp/
is 149kb. I believe that is what Jon is using for his appveyor builds. I've seen some v5.0.0 opencpn.libs built at 124kb, so I shouldn't pay any attention to size I guess.


Yes, from the appveyor file

"https://downloads.sourceforge.net/project/opencpnplugins/opencpn_lib/4.99.1405-vc141_xp/opencpn.lib"

[bdbcat]

Rick...


All correct. If it builds and loads, then no problem. The version of opencpn.lib has no bearing on the specific function of the plugin itself.


Dave

[rgleason]

Thank you, Dave.

This is just a place marker about Alec Leamas' current Plugin Installer and the Plugin API.


https://github.com/search?q=leamas%2Fopencpn
Added to API 1.16

• extern DECL_EXP bool ShuttingDown( void );
• extern DECL_EXP wxString GetPluginDataDir(const char* plugin_name);

Found in Leamas ocpn_plugin.h https://github.com/leamas/opencpn-ap.../ocpn_plugin.h

GetpSharedDataLocation() -> GetPluginDataDir().
GetPluginDataDir() must be used so the plugin can find it's own data directory even if relocated to an unknown location by the loader.

Using Alec Leamas Opencpn version with the "Plugin Installer" requires a new version of opencpn.lib for compiling Windows plugins for that system.


I've added a link to this post in the wiki in Plugin API Versions

[rgleason]

Note: Alec has put his additions into API 1.17 now

[sparticle]

Hello,


I have successfully compiled openCPN on the Rpi4 running Ubuntu 18.04.3 and it seems to run fine with accelerated graphics becasue if I switch that off in openCPN it runs very slowly. However I cannot get the chart plugins S63 and osenc to compile as they seem to think this is a armhf platform and not a aarch64 platform.


It is beyond my skill level to understand the intricacies of the make environment.



Can anyone point me in the right direction to compile these two plugins on the rpi4 please.


I checked out both git repos and complied following the instructions but they both produce armhf packages.



Cheers
Spart

[bdbcat]

Spart...


if you check out the Beta PPA, you will find oeSENC for ARM64 available for direct install.


https://launchpad.net/~bdbcat/+archi...ncpn/+packages


Unfortunately, we do not have S63_pi available yet for arm64. Simply a developer bandwidth issue....


Thanks, and good luck
Dave