DEV: Building the plugin - script Improvements

[rgleason]

@quinton-hoole
Have you seen the latest windows bash script to build plugins? It might help.

But first I used TransmitterDan's Complete windows installation of MSVC 2022 which dramatically simplified by his script. The script downloads and builds wxWidgets and puts it into a folder named ocpn_wxwidgets That is the path this script uses:

https://github.com/rgleason/weather_routing_pi/blob/improve/bldwin-rdeb.sh

Everything gets built and the metadata is added to complete the tarball.

[quinton-hoole]

Thanks @rgleason . I'll take a look. I think wxWidgets should potentially be included in opencpn-libs. I've asked about that here:
OpenCPN/opencpn-libs#20

[rgleason]

Worthwhile asking the question, but it is complex, because there are multiple OS builds with some of them using different wxWidgets, this makes putting wxWidgets into opencpn-libs evern bigger because multiple versions are needed.

It will be interesting to see what they say about this idea.

[quinton-hoole]

@rgleason @sebastien-rosset It's still not clear to me why we have so many different and often incompatible ways of building OpenCPN and it's plugins. For example, why do we use different versions of wxWidgets on different platforms? Surely we could pick one version (e.g. 3.2) and use that across the board? I can image perhaps needing different patches for different platforms, but that's a slightly different matter, and fairly easily solvable.

So here's a strawman proposal for y'all to shoot down.

1. We define a standard set of libraries (and other dependencies), including version numbers that all plugins (and core) can use. Developers are strongly encouraged to use those libraries, in preference to alternatives, when practical. In general those will be the latest stable version of those libraries, but the keeper of them (e.g. opencpn-libs) can decide on exceptions.
2. We build all those libraries from source code (probably using CMake).
3. It probably makes sense to do that in some central place (e.g. opencpn-libs) but could equally be done in each plugin independently, as long as the source version number, build process (CMake) and build tools (e.g. compilers) are standardized.
4. We use exactly the same process to build all of these (and the plugins and core themselves) on all platforms. So both locally on developer machines, and remotely on places like cloudsmith or wherever.

C'mon, shoot me down :-)

[rgleason]

Quinton, tonight I don't want to get into this discussion. I have other things I am trying to accomplish. I will read your comment later.

BTW Look at https://github.com/rgleason/weather_routing_pi/tree/improve see all the green checks?

If you watch and learn how the system works, perhaps you'll come up with some other suggestions as well.

[rgleason]

Quinton, BTW the merge all built pretty fast https://github.com/rgleason/weather_routing_pi
Now I'll increment and publish.

[sebastien-rosset]

@rgleason @sebastien-rosset It's still not clear to me why we have so many different and often incompatible ways of building OpenCPN and it's plugins. For example, why do we use different versions of wxWidgets on different platforms? Surely we could pick one version (e.g. 3.2) and use that across the board? I can image perhaps needing different patches for different platforms, but that's a slightly different matter, and fairly easily solvable.

So here's a strawman proposal for y'all to shoot down.

1. We define a standard set of libraries (and other dependencies), including version numbers that all plugins (and core) can use. Developers are strongly encouraged to use those libraries, in preference to alternatives, when practical. In general those will be the latest stable version of those libraries, but the keeper of them (e.g. opencpn-libs) can decide on exceptions.
2. We build all those libraries from source code (probably using CMake).
3. It probably makes sense to do that in some central place (e.g. opencpn-libs) but could equally be done in each plugin independently, as long as the source version number, build process (CMake) and build tools (e.g. compilers) are standardized.
4. We use exactly the same process to build all of these (and the plugins and core themselves) on all platforms. So both locally on developer machines, and remotely on places like cloudsmith or wherever.

C'mon, shoot me down :-)

hmm, personally I don't really have the appetite to propose such a change to the maintainer community. In order to make such a proposal, IMHO the submitter who is going to do the work needs to have a very detailed understanding of all the build intricacies across all supported platforms, and proven experience in the area of OpenCPN build maintenance. I'm not in that place now, and out of respect for the maintainer time, I'm mindful of how much time they would have to spend on this. That's just my personal position.

[quinton-hoole]

That makes a lot of sense. If the maintainers like it the way it is, and don't think it needs to be changed, who am I to question that.

I do think it would be useful for the people actively working on this particular plugin (i.e. us) to make it's build process work correctly on at least Windows, Linux and Macos, on both dev machines and ci pipelines, without unnecessary duplication and manual hacking (i.e. the clean 'CMake && make' process we've discussed before).

Now that i understand the maintainer position on this (or at least Pavel's), I think I can make some progress on that.

[rgleason]

Quinton, I for one am always interested in improving the process. So keep an open mind and help us streamline what is a moving parts operation. Your experience and knowledge about these aspects should help.

Keep in mind that we are right now building for 16 different OS (and variations). That is down from 21, so perhaps we are gaining. Also circleCI is updating its process on a regular basis, so changes to the scripts are needed when certain builds no longer complete.

If you could establish and maintain a definitive approach or script for building MacOS locally, that would be a big gain. Windows is fortunate to have TransmitterDan providing that for MS Visual Studio 2022. Of course Linux has so many flavor and libraries, that it requires 6 builds right now, and then flatpak came along to try to simplify things and we now have 4 flatpak builds. Of course this is expanded because we have different machine architectures. It is not simple and never will be, but it can be improved.

I personally don't see any so called hacking being done, but I am not as involved with MacOS locally. We have a circleCI script which I have sent you.

[rgleason]

rgleason/celestial_navigation_pi#143 (comment)