In cmakelists.txt, also wxroute failure

[rgleason]

These statements

include_directories(BEFORE ${PROJECT_SOURCE_DIR}/ocpninclude/wxcurl)
include_directories(BEFORE ${PROJECT_SOURCE_DIR}/ocpninclude/wxcurl/include)
include_directories(BEFORE ${PROJECT_SOURCE_DIR}/ocpnsrc/lz4)
include_directories(BEFORE ${PROJECT_SOURCE_DIR}/ocpnsrc/bitmaps)

I don't find them in ocpninclude or ocpnsrc so it appears that they are simply not needed is that correct?

[rgleason]

include_directories(BEFORE ${PROJECT_SOURCE_DIR}/libs/wx/include)

Also I don't seem to find any files here either.

I am having trouble geting weather_routing to build. I fails even after just applying the circleci/config.yml, and the ci changes. Then after I apply the cmake changes it still fails without having made any changes to cmakelists.txt.

Do you have any idea where I should look? Because it builds and installs but when I enable it, Opencpn crashes.

[rgleason]

This problem may be due to your change from CMAKE_SOURCE_DIR to PROJECT_SOURCE_DIR

I will be watching for it in other PI!!!

[rgleason]

It is still failing, now as soon as I try to install it, not just enable it.

In cmakelists.txt

if(QT_ANDROID)
    include_directories(BEFORE ${qt_android_include})
    include_directories( ${CMAKE_SOURCE_DIR}/extinclude/GLES2)

    #    #include_directories(BEFORE ${PROJECT_SOURCE_DIR}/libs/glshim/include/GLES)
endif(QT_ANDROID)

Should it be PROJECT_SOURCE_DIR?

[rgleason]

I haven't been able to get this to build properly, the changes don't seem that drastic, but I think you changed to gles from libtess2 and that may be part of the problem?

I pushed the failing commiit to here so you could take a look weather_routing update-tp branch. https://github.com/rgleason/weather_routing_pi/tree/update-tp

[jongough]

At line 114 in weather_routing_pi.cpp the setting of m_pWeather_Routing to NULL is commented out, don't know why. So I set it to null in the constructor by adding this at the end (new line 96). I rebuilt the plugin and it all works, the bits I tested. The issue was that without setting the value to null it could contain anything and that was used in tests. This resulted in OCPN using an invalid value and crashing.

As far as I can see the build works fine, it is the plugin logic that is wrong.

[rgleason]

Yes, this fixed it. I left it at line 113 and took the comments out (don't know why I commented out) but have moved this line up to a new LINE 96 within the "constructor" and have tested and it does work!!

      m_parent_window = GetOCPNCanvasWindow();

      **m_pWeather_Routing = NULL;**   <--- MOVED up to LINE 96

#ifdef PLUGIN_USE_SVG

If I am missing one of these for Polar_pi which fails Opencpn every time I disable it, should I try that? Thank you.

[jongough]

I think with polar_pi the creation of the dialog may be done after OCPN tries to set the colorscheme. So either it needs to be checked for being valid before this call or it needs to be created earlier, either in the instantiation or the Init parts. Currently the only place the PolarDialog is created is in ShowPreferencesDialog (line 220 in polar_pi.cpp).

[rgleason]

Humm, there are some other problems too. 1.. In preferences there is a checkbox "Show Polar Icon" which makes no sense to me because there would be no way to activate the plugin.

2. This checkbox is connected to if(m_bPolarShowIcon) in polar_pi.cpp Lines 119, 212, 252, 265-269, 420, 469.
3. Since there are so many instances, the function must work in some way that is not working now, or is outdated.
4. When the plugin is disabled O crashes.
5. I still have been unable to get the svg icons showing. I've been through it a dozen times and don't see why, however the puzzle icon works as would be expected and shows "Polar" in the popup.
6. I am going to push Polar_pi up to Polar_pi master-update branch in case you can advise.
7. https://github.com/rgleason/polar_pi/tree/master-update

I don't know if I should try to remove the Show Polar Icon from preferences and just leave the parameter but set it to true, or clean up this mess, or perhaps try to get it working when Show Icon is unchecked somehow.

BTW I've tested the file handling and it seems fine because you can browse files to LOAD and browse to SAVE, so I don't know why filochard had problems with the plugin in Flatpak! Also I don't see where I would change the data directory if that is a problem that needs to be solved.

[jongough]

I try to keep clear of other plugins unless it is related to frontend2. As I use frontend2 for three of my plugins I try to make sure it works OK. If other plugins fail it is probably not due to frontend2, but changes in OCPN, changes in the underlaying environment, or usage patterns. This should be fixed by the plugin developer, not you. In the case where OCPN crashes when a plugin is disabled it would suggest that there are plugin issues and not build issues. OCPN is changing, often without notice, and normally with very little documentation/information about why it changed and what has to be done to support the 'new' way of working.

[rgleason]

Problem: Sean is basically AWOL I cannot rely on him. "This should be fixed by the plugin developer, not you" Also he has seldom accepted my Pull Requests and is not set up to build with circleci and cloudsmith. It is not his interest right now. Pypilot is his focus.

[jongough]

You can only do what you can. Changing the logic of plugins or debugging them is very time consuming particularly if you don't know the plugin at all. Apart from the different programming styles it takes time to understand what is being attempted before changes can be made. That is why I say if the plugin has logic issues it should be the developer who changes this or someone who has the time and energy to investigate, fix and support the plugin. I try to do this if it is not too complicated, but..... Sean's plugins I find particularly difficult to work with as he has a diametrically opposite style to me and I always struggle to understand half of what is there.

[rgleason]

Yes, of course I understand devs have different styles.