Update readme file. General path to opencpn.lib for WIN.

[Hakansv]

Dave..

• Suggest for readme file for oesenc_pi. Based on my experiences. Take it or scarp it.
• More general opencpn.lib path instead of your local.

[leamas]

Hej Håkan,

I'm trying to merge your changes to the README file with my own. Could you possibly review the README.md file at https://github.com/leamas/oesenc_pi/ and provide possible feedback here ? I've shamelessly stolen the windows part from you, but also changed it considerably.

--alec

[rgleason]

ubiquotious
https://www.google.com/search?client=firefox-b-1-d&q=ubiquitous+definition

Nope. Good word. Just the spelling Alec. Which I had to check too. It looked strange.

[leamas]

@rgleason : You are the native speaker... are you saying I'm using this word in a strange way?

[Hakansv]

alec.. I don't remember me being involved but if so do use it. I see nothing strange with the text but obviously some additions are needed for the the new build processes. Håkan

[leamas]

obviously some additions are needed for the the new build processes.

Such as, in particular for Windows? Yes, I have tried to adapt this to the new processes...

[Hakansv]

For plugins there will be new experiences as for Linux. The text you refer to may be good so far. In future there will be two scenarios I suppose. When someone want to change and build a plugin for local installation from master or a test branch later merged to master. When good enough for release master is merged int to the ci branch where routines to load the plugin manager are present. The first part will not change much but the latter is new for most plugin developers. I was partly involved in the radar_pi plugin manager process. But very little in the last phase. Others made the crucial parts. But for that plugin I couldn't finalize on Win. Mostly due to Kees have used Unix processes where curly and jq was involved. But afterwards I found a Win technic also for that to test next time:

On Windows 10 is curl mostly included now a days. For jq I found a solution

• Install Chocolatey
• Then do the Unix like command "chocolatey install jq"
• After that the script runs fine when calling it by shell scripts: C:\Builds\OCPN\plugins>sh cloudsmith-sync.sh radar_pi kees-verruijt ocpn-plugins-unstable

To understand this it may be good to have a look at Kees' methods? https://github.com/opencpn-radar-pi/radar_pi/blob/ci/RELEASE.md

[leamas]

OK, now I see what you mean. I have an overall knowledge of these processes, so to speak ;)

But no, we cannot pull in that in a simple README, it's just too much, at least for now. My idea is to document a plain, local build (and how to install it locally). That is, things which should be expected to work after a plain fork.

If I understand you correctly, you are saying that it looks sane from that perspective (?)

EDIT: You have an important point here: we should leave room for the upcoming documentation for the complete system with builders and deployment. That is, split this into a small README + a separate BUILD.md or so.

But now I need some sleep. Thanks for input!

[Hakansv]

For local install it's fine. It's as usual presumed the wiki for general OCPN build is followed. But that is normally not mentioned in the "Readme". Win Builds

[leamas]

I have references to the wiki in the windows section. But the others are actually self-contained, they have all the necessary steps required to build without consulting the wiki.

[leamas]

I have filed a PR #76 which if/when merged will close this one. This is because I have used the README update here and merged it into #73, and since the propesed patch to CMakelists is obsoleted by commits lately removing the patched definition completely.

Please re-open bug if required.