Build File relocation

[rgleason]

The location of build files has been changed.

As per bdbcat: List is here: OpenCPN/OpenCPN#2125

[bdbcat]

Rick... This is not at all necessary. The new CDN server functions just fine. The current master CI build is now correct, completes without error. Let us stop this noise, please.

[bdbcat]

Rick.... The links may be found by inspecting the OCPN master branch source code. Fix them once in Frontend, and done. We don't need another floating repo.

[bdbcat]

List is here: https://github.com/OpenCPN/OpenCPN/issues/2125

[bdbcat]

Not appropriate for the Downloads page. The list is as noted as an OCPN Issue (https://github.com/OpenCPN/OpenCPN/issues/2125), and is available to all devs, as they need it. And yes, failures will occur. This phenomenon is called "bit-rot". A common situation for large complex projects, with multiple online dependencies, like O.

[rgleason]

All the Cloudsmith files have been removed.

[jongough]

For development purposes placing download locations in an 'issue' is not really helpful. New developers, or those that are not up to speed with the current move from navnux to opencpn download will not really know what to do. The fact that the download links are unintelligible to humans does not help either. There needs to be clear, easy to find, documentation regarding the downloads available for builds and an easy way to check what is being downloaded in case it changes again (it will with new versions). The old method was fine, the new method works, but is going to cause issues.

[bdbcat]

"The old method was fine," And what method was that?

[jongough]

The use of navnux with a clear file name so that the developer knew what was being requested. The new method, i.e. the one that uses some cloud storage behind the opencpn.org name is obscure with a random, or seemingly random, string of characters pointing to a file. To help in my configs I have a comment saying what is being done.

I request that somewhere other than in an 'issue' this be documented, possibly in the developers manual. My preference would be for a 'developers' download area that gives the links that need to be used and these links should avoid random character strings as this is probably going to cause issues when a new version of one of these files is generated and needs to be used.

So if http://opencpn.navnux.org/build_deps/wx312_opencpn50_macos109.tar.xz is replaced with https://download.opencpn.org/*/wx312_opencpn50_macos109.tar.xz where '*' can be a recognisable directory, i.e. 'macos10.9', or a set of directories at least that would be 'readable'. The use of: https://download.opencpn.org/s/rwoCNGzx6G34tbC/download to me, at least, is not very user (dev) friendly.

[rgleason]

Rather than doing anything at this point, may I make an additional suggestion friendly to unknowing Plugin Developers? Under the Developer Manual > Developer Plugins make a new namespace called "Plugin Build Files" and in that new page provide links to the file resources that Plugin Developers should use.

Additionally I note that this page Modularized Packaging probably needs to be updated as I believe it has changed recently. Other pages in the manual need review too.

[bdbcat]

The new server uses cryptic naming structures. No way to change, AFAICT. So the best solution is to use comments in the code, indicating exactly what content is being downloaded. You will note that the Appveyor builds already show the file content in the download instruction: - ps: Start-FileDownload https://download.opencpn.org/s/oibxM3kzfzKcSc3/download -FileName OpenCPN_buildwin-4.99a.7z Thinking about new plugin developers: Almost every one will start their work based on an existing plugin workflow, just like Frontend1/2 started from leamas' port of oesenc_pi, which started from the original unmanaged plugin build process. These server download links have been in the build recipes forever, and have not been a central issue to the process. Thus, the correct new file download strings, with comments, will be in place in the starting template, however opaque. I cannot think of any other "resource" that might be currently available in the server that might be of use to a developer. Can anyone? Indeed, most developers will not have the creds to browse the server for possibly useful stuff.

[rgleason]

Thank you for explaining. Congrats on this recent difficult transition. So it is best to try to keep the documentation inside the code because it stays current and is reliably up to date? Then external documentation does not need to be maintained and updated. So we should just be sure to have adequate comments.

There is one problem however, existing developers will be fixing one thing at a time, and not know where to get the new location, in a serial fashion, which is sort of a pain. Is a page in the Dev Manual > Plugins out of line?

[bdbcat]

No

[jongough]

Does the name of the download link change if the file on the server is changed? Does it change if the same file is put up again? I suppose the question I am asking is 'how stable is the name being generated/used'? If it is unstable, i.e. changes for every upload done then can we use a proxy name or a redirect to get to this so that the change is constrained to one location rather than all plugins?

[bdbcat]

I think that the auto-generated name is unique to a file. If the file is changed, the name changes. Probably uses some kind of hash of the file content to create the name. But really, these linked resources have not changed in literally years. Not to say that they won't change tomorrow, based on upstream wxWidgets or MacOS changes. But I think it is infrequent enough to not be a pressing concern. And a change in wx version or MacOS toolset will have wide ranging and highly visible effects, not confined to plugins only. So we will all be in the loop.

[jongough]

Not sure if there is also an issue with `http://opencpn.duckdns.org/opencpn/opencpn.flatpakref, but flatpak builds keep failing because this website does not respond and a timeout occurs. The file it is trying to get contains:

[Flatpak Ref]
Name=org.opencpn.OpenCPN
Title=OpenCPN - Concise ChartPLotter - Main package
Description=OpenCPN main package, loaded by Plugin.Base
Branch=master
Url=http://opencpn.duckdns.org/opencpn/repo
Homepage=https://opencpn.org
Icon=https://opencpn.org/OpenCPN/assets/img/logoOriginal.png
GPGKey=mQENBFyk1UIBCACwFaQLPtrmEhOddy7LYJ6wmRJs9MNBtSp7F3+3uWX+uycQSW3strOwbyYwiDsuymWwmjRfDDBClYvIrFlUAB/OPiuSimE7CHZVye0zbT9i9W4LMf2uRYtYxkZYAngF6NPye8qANRbwocqn3QPBjlNdjd7OjBSCpBUwy50EW3JtstxKeth3Fn7a6EI3sCkHZLaFxhO3A6uxk89Wpq1lBqWAkkR1zMHrIs1TKrvGP/Dfc0ShYdwWaOeuzkWaDYkF0SZiSQcV3JLkIIJh8KJpos4+izYdmrLkDFdpyXit9OByd42mjbWkHKicAkUKrsjQDL2G6FSXs1IdTBh3j1y88aVPABEBAAG0EmxlYW1hc0BvcGVuY3BuLm9yZ4kBVAQTAQgAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBBcYLymPkdBZBDv7MPuc+iyUDyOBBQJeYh4bBQkCqpbZAAoJEPuc+iyUDyOB/IYH/Rk9UVwUoe+9kNkR/lFrxoMWr9nPCRVs/8Sa1cc/qjuyp1sHkF4fiOJtbOUIam3mWkz1Kikh52i8A+aWdTQSicFORR2Te8rbi3KMsXA2+KT6IKLw1oq7/uK935PKShIm7JPjCwiWpY87zYynmhsr34/7PbsYY4El9wxyNFBUOxXrJgQwUHAlg4JlMEgm8CTG0eNjCjMRc4EbAD3T4oDRFgtiBAG/cEBgnUYm+O5BSUSg8xPPUXx/1+n35+HMQ9Dd1WTL9o/ZEAqgQWW4kXVGd4oUKZiKW2tWo1mMlKMvCPykk9b8delXcZ/cb04dVeUfqL9j5LPeDLXUurxFd0AWl0S5AQ0EXKTVQgEIAKurHsSJyZCsi0MBYbPd9LFYgf6hQK61TwVq7bk0d9VJxbCBhHl2p+hFJB786cQrPEXOy76QrLvooM8dsP6f/qdUkIb4esBteq07bga+HQOc94KafZ54OWFMn/7g+abU3RAKbM7RwfDj20wvEQuqxMeA5JNzZaamAa84Uq9ZdMpDJL4qN/4VTST5XFgGpRYM+qTC54HRfRh2uOUy13nlYpbUKQU1PcBvuOU6lhRs1fEr+VBbNfVmS1zfagNQ8h0om+65AynWkU9eqCIstaH++6e7bobv1rLo9QZsyMZl14Qw5FQzGKobqy8TdB2/D62SyDJOcIVjef0eB55Ys30cSkkAEQEAAYkBNgQYAQgAIBYhBBcYLymPkdBZBDv7MPuc+iyUDyOBBQJcpNVCAhsMAAoJEPuc+iyUDyOBQa0IAKwnA2CF9V21VeWdhQxSrYgtL8cLcsV7wVAsR5dPvC6gDzbrG6kFd5GRAs28EdsqDJvyhqlGWqcMc1ldEUiE3OpPxCTLHfRoccBgTNYJd2yTPyKjDyqsiEYGtKXBMadUrS0NdOM/d4Yj7mtX9VDS/bl/KWo9W3PJc2IxKeXGEDhOdy8jppFStPCoIOeSTDWGzRAZ9UPMANojbx5cmYrP8SxCSneJGZKbdvDFMEmmmFwHut3PFPdmF8rwkpQQzjXrR5a59pereGU910jWpxaazwMaoJaI8NOOp06XZfufR6IGyMWvhvwtxKW6GG+WfLCta9hqtmzZQiwLeStn3dfkbbc=

Which refers to Url=http://opencpn.duckdns.org/opencpn/repo. Is there some other way to installing the required files for flatpak?

[leamas]

@jongough. The flatpak stuff is a plain, separate bug. Will look into it

[leamas]

Almost every one will start their work based on an existing plugin workflow, just like Frontend1/2 started from leamas' port of oesenc_pi, which started from the original unmanaged plugin build process.

On a sidenote: what I have done in the shipdriver plugin is a new attempt on what I did when porting oesenc_pi.

I do think that the code in shipdriver has many advantages compared to what I did in oesenc. As always, looking back you know what should have done in a different way. Or just done, given more time. Anyway, my second attempt is better.

[leamas]

@jongough: please file a new issue for the flatpak stuff so we can stay on topic here.

yes, I know, I wrote a sidenote... "blushes"

[rgleason]

Alec just curious, is ship driver frontend update?

[leamas]

there is no such thing as shipdriver frontend. There is just shipdriver, and Mike which uses the same basic files on one or two ther plugins.

That said, I just made a PR to shipdriver to handle all sorts of changes in the environment including the links which is the topic here.

[jongough]

New issue created. #295

@jongough: please file a new issue for the flatpak stuff so we can stay on topic here.

[rgleason]

If there are other files found that are vital build files for any environment here is a place for developers to list them (and to correct them as needed). https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:plugins:plugin_build_files

[rgleason]

I could close this, but it might serve as a guide for other plugin dev. Should I close it?

[rgleason]

Closing. Developers know where things are.