Development Debugging Environment - Setup Help

[Hakan]

Dave
Yes it works fine.
Hopefully are there no two letters filename of relevance out there? There was at least none for me playing around.
Or I may misunderstand it. Never mind, it's fine now.

Many thanks
Håkan

[rgleason]

Dave, Thank you. Debug mode seems to work fine now for me too. Dashboard, Gribs and ChartDownloader are all there. Routes work too. Reasonably fast too.

What happened to WMM? Has it been incorporated?

Now we can debug some plugins with Hans.

[Hakan]

Rick
WMM comes with OCPN repo as Dashboard, Grib, Chartdldr and Demo.
https://github.com/OpenCPN/OpenCPN/tree/master/plugins
Håkan

[hasse_A]

Dave.

Yes confirmed, now I can start opencpn, set breakpoint etc...

Thanks Dave, Rick and Håkan for your help.

I will now try to incorporate weatherfax_pi.

/Hans

[hasse_A]

Originally Posted by Hakan

Hans - Good trace.
re: "There is a file named Track.h under weatherfax_pi\src\libaudiofile."
I've unloaded weatherfax from my repo but two things you could try?
1)
edit all #include "Track.h" in project weatherfax to something like
#include "plugins\\weatherfax_pi\\src\\libaudiofile\\Track. h"
or as you say:
2) Rename all references to, and the file itself to something else: wTrack.h ?
Obviously is Sean's Track.h no longer equal to OCPN's Track.h
Håkan

Ok, so now we are back with this problem in weatherfax_pi.
What is your take on this ?
It seems a little awkward to fetch the plugin and then have to be forced to
edit a set of files before you could debug it.

I don't have the knowledge to fix this name space issue.
Is there someone out there that can point me in the right direction ?

/Hans

[hasse_A]

I am trying to incorporate weatherfax_pi into the debug environment under OpenCPN.

As soon as I make a change to the CMakeLists.txt (Track.h -> wTrack.h)
and run the configuration, the Source directory and CmakeFiles.txt disappears from the Solution Explorer.
Only "External Dependencies" is still there.

I find this very surprising.
What am I missing ?

/Hans

[Rasbats]

On my machine I found a significant difference in the procedure for making Debug and Release versions of OpenCPN 4.5.215 when compared with the wiki. Visual Studio 2013 was being used.

https://opencpn.org/wiki/dokuwiki/do...piling_windows

The wiki has been edited with what I think are the steps needed (prefixed by 4.5.215).

Also the Package made with VS 2013 did not install several files in the root folder of OpenCPN. Files needed are also listed in the wiki. Does the NSIS script used by Package need amending?

Mike

[hasse_A]

Mike.

I think you are correct.
I use Håkans copyfiles.bat so I have not run across the problem but I agree
it should be specified in the wiki.

/Hans

[hasse_A]

I am now able to build OpenCPN with weatherfax_pi.

However. I had to add

"typedef int ssize_t;"

to 2 of the files since it was said to be undefined.
The 2 files are File.h and FileModule.h

The compiler complains about ssize_t to be undefined.
It is declared in config.h but is not reached by the chain of includes.

It's a bit confusing since there are no errors when building the plugin standalone.
If you study the included headerfiles in File.h and FileModule.h there is no
declaration of ssize_t in any of these so it's only natural that you get compile
errors. But, why do you not get those when building the plugin by itself ?


File.h -> Shared.h no declaration of ssize_t in these files

FileModule.h -> Module.h -> AudioFormat.h -> aupvlist.h
-> Shared.h
-> afinternal.h -> audiofile.h
-> error.h

no declaration of ssize_t in any of these files

Another thing I don't understand is why there are 2 types of include of aupvlist.h

#include <aupvlist.h> in audiofile.h
#include "aupvlist.h" in AudioFormat.h

#include <aupvlist.h> tells the compiler the headerfile is in a known include directory or have I misunderstood ?

/Hans

[hasse_A]

Originally Posted by hasse_A

Another thing I don't understand is why there are 2 types of include of aupvlist.h

#include <aupvlist.h> in audiofile.h
#include "aupvlist.h" in AudioFormat.h

#include <aupvlist.h> tells the compiler the headerfile is in a known include directory or have I misunderstood ?

I can answer this myself. The 2 different includes differ only in the order in which the directories are searched so if the file only exist in one place which I suspect it does not matter.

Anyhow I think it should be corrected in audiofile.h to read
#include "aupvlist.h"

/Hans

[Hakan]

Hans
Good work on a long road.
So I think you solved why it could build alone but not inside OCPN.
Thanks for sharing.
What about a push request, or an issue to Sean's Github?
Håkan

[rgleason]

Rick
WMM comes with OCPN repo as Dashboard, Grib, Chartdldr and Demo.
https://github.com/OpenCPN/OpenCPN/tree/master/plugins
Håkan

Oddly, it is not available in Debug mode under Settings > Plugins. Is this normal?
It is available in the Release version.

[Hakan]

Rick
I understand it as you are running OCPN in Debug mode and can't find WMM listed in options > Plugins?
If so: Did you really included WMM in the Debug environment?
Please read my post:http://www.cruisersforum.com/forums/...ml#post2326572
Part of it:

To debug OCPN and one or more plugins you need to copy all files from corresponding C:\Builds\OCPN\OpenCPN\build\plugins\BR24radar_pi\ Debug\ to one common folder you have to specify in pluginmanager. AND that copying has to be done for every plugin change you want to debug. Otherwise will the change not be seen in debug mode and no brake will be recognized. (The brake symbol will be a ring instead of a fat dot.

First build the whole project for Debug e.g. Ctrl+Shift+B. Then copy all created plugin debug files to the common directory of yours. Then run Debug - F5.
Later if you change in WMM you can build only WMM, right click in Solution Explorer, and again copy all Debug files. (That's way I have automated that moment in my pluginmanager.)
Håkan

[transmitterdan]

It would improve efficiency if the VS build process used an end of build event in the debug build process to copy all required files (plugin dlls, etc.) to the proper directory under the build\debug tree. I was able to add that here and it saves a lot of head scratching. Also it eliminates the need to edit pluginmanager.cpp. VS is smart enough to know where the source file is so even by moving the debug build .dll file it will find the original source folder and you can set break points in the plugin before starting the OpenCPN debug executable.

Is anyone interested in trying to come up with a "standard debug scenario" for plugins built inside the O tree? If so, I will help. Would be good to ensure all plugins can be built this way. It takes a lot of time to test every plugin. And like weatherfax_pi some plugins don't build in the current development environment, would be good to fix that too.

[hasse_A]

So now I can start OpenCPN in debug mode with the weatherfax_pi code placed under OpenCPN\plugins where they are built along with the rest of the project.

I have created a dedicated directory to where I copy the library files and to which I point pluginmanager to.

grib_pi and dashboard_pi works fine but weatherfax will not load.
The log-file says it can't find the module.

grip_pi :

2:26:13 PM: PlugInManager searching for PlugIns in location C:\Users\hasse\Plugins_dir
2:26:13 PM: PlugInManager: Loading PlugIn: C:\Users\hasse\Plugins_dir\grib_pi.dll
2:26:13 PM: C:\Users\hasse\Plugins_dir\grib_pi.dll
API Version detected: 112
PlugIn Version detected: 401

dashboard_pi :

2:27:14 PM: PlugInManager searching for PlugIns in location C:\Users\hasse\Plugins_dir
2:27:14 PM: PlugInManager: Loading PlugIn: C:\Users\hasse\Plugins_dir\dashboard_pi.dll
2:27:14 PM: C:\Users\hasse\Plugins_dir\dashboard_pi.dll
API Version detected: 106
PlugIn Version detected: 102

weatherfax_pi :

2:27:14 PM: PlugInManager: Loading PlugIn: C:\Users\hasse\Plugins_dir\weatherfax_pi.dll
2:27:14 PM: Error: Failed to load shared library 'C:\Users\hasse\Plugins_dir\weatherfax_pi.dll' (error 126: det g沠inte att hitta den angivna modulen.)
2:27:15 PM: PlugInManager: Cannot load library: C:\Users\hasse\Plugins_dir\weatherfax_pi.dll

Translation : Unable to find named module.

This "else if" around row 1170 in pluginmanager.cpp is true which I think is not very good since we then end up with the error message in the log-file.

else if(!plugin->IsLoaded())
{
if( m_benable_blackdialog ){
// Look in the Blacklist, try to match a filename, to give some kind of message
// extract the probable plugin name


Any ideas ?

/Hans