OpenCPN Beta Version 3.3.1824 Released

[seandepagnier]

Originally Posted by nohal

I have started a little experiment in https://github.com/nohal/OpenCPN/tree/strip_docs
The plan is to split the package in two by default - "opencpn", containing just the program files and minimal set of data and opencpn-doc, containing the manual.

Of course we can even strip (most of) the gshhs shoreline data and create two more extra packages "opencpn-data-midres" (containing the current default detail level) and "opencpn-data-highres" (containing the full resolution data)

Pavel

Yes.

This is exactly what I have. Strip the gshhs to the first level (or even no level maybe) as it is quite useless for navigation. And strip documentation. Finally it might make sense to strip the tide data, because it only works in the US right? So for most people this data is also completely useless. The install packages could be something like:

opencpn-stable (core binary, grib and dashboard plugins, translations)
opencpn-data (data files that rarely change, s57 chart data, gshhs level 1, sounds etc)
opencpn includes all of above suggesting doc and tide-data

opencpn-doc
opencpn-tide-data
opencpn-gshhs-highres (some plugins suggest this package)
opencpn-beta

opencpn-dev includes opencpn as well as several versions of ocpn_plugin.h, development documentation, build scripts (so we can avoid duplicating cmake scripts in every plugin) and possibly opencpn.lib files for cross compiling to windows. This is the same as "make install" when built from source
opencpn-wmm_pi
...
opencpn-plugins meta package for all plugins listed on the site

Maybe this is too many, at first tide-data may be included with data

Then if you want to upgrade, most of the time the download would be ~2MB.

For other operating systems just split to minimal and full installers.

[cagney]

Originally Posted by boat_alexandra

Yes.

....

Finally it might make sense to strip the tide data, because it only works in the US right?
......

Wrong!
Just test it!

Thomas

[Viking Sailor]

What would be really helpful to the guys with low bandwidth and/or unreliable connections would be providing OpenCPN via a download program that can handle lost connection, partial downloads, and continuing/restarting a partial download.

[seandepagnier]

Originally Posted by cagney

Wrong!
Just test it!

Thomas

I stand corrected. So now we have North America, Hawaii, Australia, nz, UK, and Japan, and a few other places.

Still not helpful to me, but much better. Was this recently updated?

[rgleason]

Sean, does it make sense to enable option to use this tide data (currents) for wxroute plugin?

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[nohal]

Hi all...
We have some real results.
I have broken the package into several optional components, separating the core program (with stripped debugging symbols), documentation, tide/current data and several quality levels of the GSHHS shoreline database.
The default build produces a minimal package (still with the crude GSHHS polygon data as I don't think we should ever distribute a version without a basemap, but without documentation, harmonics and any higher resolution GSHHS data) It is still possible to produce the monolithic package od course.

The sizes are as follows:

Main prog
opencpn_[VERSION]_[PLATFORM].deb (<5 MiB)

Documentation
opencpn-doc_[VERSION]_all.deb (17.4 MiB)

Tide/current data
opencpn-tcdata_[VERSION]_all.deb (697.4 KiB)

GSHHS data (each package requires the lower detailed one, so while installing full, all of them will be downloaded and installed)
opencpn-gshhs-crude_[VERSION]_all.deb (788.5 KiB)
opencpn-gshhs-low_[VERSION]_all.deb (1.5 MiB)
opencpn-gshhs-intermediate_[VERSION]_all.deb (4.2 MiB)
opencpn-gshhs-high_[VERSION]_all.deb (12.3 MiB)
opencpn-gshhs-full_[VERSION]_all.deb (49.8 MiB)

If you want to test it, there's a special PPA created for it at https://launchpad.net/~nohal/+archiv.../opencpn-data/ - Keep the normal beta one as I will not be updating this one beyond extents of this effort.
To test these packages, all you need is

sudo apt-add-repository ppa:nohal/opencpn-data
sudo apt-get update
sudo apt-get install opencpn

It will replace the normal beta as the version number is higher.

Then you can install the data you consider needed with something like

sudo apt-get install openpcn-doc opencpn-tcdata opencpn-gshhs-full

The modified code lives in https://github.com/nohal/OpenCPN/tree/strip_docs (it works, only some minor polishing, like a dialog explaining that the documentation and data have to be installed separately in case they are not availabe, is missing)
My packaging stuff is at https://github.com/nohal/launchpad
The modified code lives in https://github.com/nohal/OpenCPN/tree/strip_docs
The needed data (except the documentation, which is still in the main repository) are at https://sourceforge.net/projects/ope...ackaging_data/

I would like to hear especially from SethDart and the OpenSuSE guys what they think about this system and whether they feel it suites them.

Still undecided how to handle this on Windows (Any NSIS expert here? I haven't touched it for a couple of years, so it will be a PITA to modify the installer) and Mac (For now all I can do is ignore it exists, but the package creation should work fine)

Pavel

[seandepagnier]

Originally Posted by nohal

Hi all...
We have some real results.
...

Great news. Also nice that all of these are platform independent except the core binary package.

I would like to hear especially from SethDart and the OpenSuSE guys what they think about this system and whether they feel it suites them.

Maybe we can make a meta package for "apt-get install opencpn" pull the core, data and tide packages by default as well as crude shoreline data. Then with each update, only the opencpn-core package is updated (unless the data updated)

Still undecided how to handle this on Windows (Any NSIS expert here? I haven't touched it for a couple of years, so it will be a PITA to modify the installer) and Mac (For now all I can do is ignore it exists, but the package creation should work fine)

Pavel

I think for windows, it is too confusing for these users to have too many options and packages since everything must be installed manually with installers. Unless we can update the installer program to download various selected components, we should simply offer two choices:

1. opencpn-minimal-XXX-setup.exe -- Contains minimal coastline data and no documentation. Useful for limited connections and upgrading.

2. opencpn-full-XXX-setup.exe -- Recommended for new users, contains full documention and medium resolution coastline data. This is exactly what is on the site now.

[rgleason]

Still undecided how to handle this on Windows (Any NSIS expert here? I haven't touched it for a couple of years, so it will be a PITA to modify the installer)

Is there any way I can help? Still learning how NSIS works...maybe someone else it more expert?

[bdbcat]

Rick, pavel, etc...

On Windows, we could theoretically build a web-based installer that downloads components as specified by the user. Theoretically...

What we need for this is a volunteer developer who has the web coding skills to pull this off.

Any takers?

Absent that plan, I agree that the reasonable solution that we can do now is to build two binaries, as Sean suggests.

I think modifications to the Windows NSIS installer should be trivial, since he does not install files individually, but works with directory contents.
It will probably just work.

Dave

[rgleason]

I think modifications to the Windows NSIS installer should be trivial, since he does not install files individually, but works with directory contents.
It will probably just work.

Ok, for example where (directory) would you locate the documentation to CPACK that alone without the code? -Also how would I get the Documentation ? Is it html...

file:///C:/Program%20Files%20%28x86%29/OpenCPN%203.3.1911/doc/help_en_US.html

Yes, it is. So what do I do copy it off website? and put it in the subdir needed to install properly...is that it?

I might be able to do this... I think

[bdbcat]

Rick...

Without any testing, I suspect that you can add/remove stuff from {opencpn/data} directory in the build tree, and the CMAKE "package" target will do the right thing. I have not tried this myself.

Anyway, the relevant stuff may be found at
CMakeLists.txt, line 1074...

GL
Dave

[rgleason]

Yes, Dave, I think that would be a good approach.

INSTALL(FILES ${gshhs} DESTINATION ${PREFIX_PKGDATA}/gshhs PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ)

So starting at line 1074 we would comment out all items not to be included in that install package.

I should probably do a dry run... should I use beta? ...is there any timetable?

--Also basic documentation does not include other plugin documentation. What are we doing about that?

[nohal]

The 2 installers approach "simply works" with the changes made here - the small package has 11MB instead of the full 36.
What could be further improved and needs mods to the NSIS scripts:
- On most machines the VC redistributable is not needed nowadays, so it could be downloaded just in case it is needed (Detect (+ VC 8.0 Redistributables - NSIS), download, install)
- One installer, downloading selected components from the net (Builtin NSISdl plug-in - NSIS + new page in the wizard to select what to get)

Pavel

[seandepagnier]

Originally Posted by nohal

The 2 installers approach "simply works" with the changes made here - the small package has 11MB instead of the full 36.

11MB? I got 7MB for windows and 4.5MB for linux using all data, tides, and first level of gsshs. I put packages for mingw minimal (also doesn't require xp service pack 3) and armhf minimal on sourceforge.

I can confirm (I built using visual studio as I have a windows laptop now) that opencpn runs exactly the same speed compiled with mingw as visual studio in release mode. The installer is only slightly smaller, 1-2MB for the mingw version, not 4MB.

Are you sure you have xz compression?

I am using NSIS version 3.0 if you try this version and get errors, take a look at the changes I made to the nsis installer script in my mingw branch it might save some time.

[nohal]

Originally Posted by boat_alexandra

11MB? I got 7MB for windows and 4.5MB for linux using all data, tides, and first level of gsshs. I put packages for mingw minimal (also doesn't require xp service pack 3) and armhf minimal on sourceforge.

I can confirm (I built using visual studio as I have a windows laptop now) that opencpn runs exactly the same speed compiled with mingw as visual studio in release mode. The installer is only slightly smaller, 1-2MB for the mingw version, not 4MB.

Are you sure you have xz compression?

No, I don't. The Windows installer generation is completely untouched, this is just a side effect of the general package generation changes.
And switching to mingw for Windows build is IMO not feasible. Especially now and without all the related necessities (= do it with a stable release, at the same time as switch to wx3.x, write a totally bulletproof documentation for the Windows based devs, make it seamlessly possible for them to keep using VS for their development, rebuild, test and fix all the plug-ins).

I am using NSIS version 3.0 if you try this version and get errors, take a look at the changes I made to the nsis installer script in my mingw branch it might save some time.

I will have a look at it in case I decide to work on this.

Pavel