Development Debugging Environment - Setup Help

[rgleason]

For Plugin Internationalization see
Plugin Languages | Official OpenCPN Homepage

[Hakan]

Rick.
A little correction or add: Pavel "owns" OpenCPN Crowding and both he and bcdcat will of course maintain Crowdin. I've offer my help to relieve the pressure on them in this matter. So I'll of course do what I can whenever possible and needed.

What a plugin developer has to do is give us a message whenever the code is ready enough to update Crowdin, that's the main issue. If potfiles.in and the xxx_pi.pot is also updated in source it's very fine. But the message to any or all of us is the main task.

Then we will try to watch Crowdin for updated translations but a forum note from translators is of course also appreciated.

Håkan

[rgleason]

I am trying to debug weather_routing_pi because it is not working in Windows, using a github local repository for OpenCPN v4.2.1 and after Building, then hit Debug and I get messages that I am missing cairo.dll and several other dll's.

Yet I do have those under buildwin directory and I have downloaded and unpacked the full package needed.

Where should I be putting these files?
I always seem to get that screwed up.

Also Debug was asking for lib files too... but I think that has gone away.

[transmitterdan]

Originally Posted by rgleason

I am trying to debug weather_routing_pi because it is not working in Windows, using a github local repository for OpenCPN v4.2.1 and after Building, then hit Debug and I get messages that I am missing cairo.dll and several other dll's.

Yet I do have those under buildwin directory and I have downloaded and unpacked the full package needed.

Where should I be putting these files?
I always seem to get that screwed up.

Also Debug was asking for lib files too... but I think that has gone away.

Put this in a .bat file (I call mine dbcopy.bat) in the build directory.

@echo off
@echo "Copying gtk dlls."
copy /Y .\debug\gtk\cairo.dll .\debug
copy /Y .\debug\gtk\fontconfig.dll .\debug
copy /Y .\debug\gtk\pixman-1.dll .\debug
copy /Y .\debug\gtk\libpng16.dll .\debug
copy /Y .\debug\gtk\libxml2.dll .\debug
copy /Y .\debug\gtk\iconv.dll .\debug
copy /Y .\debug\expat-2.1.0\*.dll .\debug
@echo "Copying expat dlls."
copy /Y debug\expat-2.1.0\expat.dll .\debug
@echo "Copying chartdldr_pi.dll to .\plugins"
copy /Y plugins\chartdldr_pi\Debug\chartdldr_pi.dll .\plugins
@echo "Copying grib_pi.dll to .\plugins"
copy /Y plugins\grib_pi\Debug\grib_pi.dll .\plugins
@echo "Copying dashboard_pi.dll to .\plugins"
copy /Y plugins\dashboard_pi\Debug\dashboard_pi.dll .\plugins
@echo "Copying gecomapi_pi.dll to .\plugins"
if exist plugins\gecomapi_pi\Debug\gecomapi_pi.dll copy /Y plugins\gecomapi_pi\Debug\gecomapi_pi.dll .\plugins
@echo "Copying wmm_pi.dll to .\plugins"
copy /Y plugins\wmm_pi\Debug\wmm_pi.dll .\plugins
@echo "Copying vdr_pi.dll to .\plugins"
if exist ..\plugins\vdr_pi\build\Debug\vdr_pi.dll copy /Y ..\plugins\vdr_pi\build\Debug\vdr_pi.dll .\plugins

Run this after you build the debug version. I will put everything where it needs to be. I put all the plugins in the plugins folder under the base OpenCPN folder. You can add any other plugin dlls you build.

Note: This method avoids the common complaint that breakpoints can't be set in plugins.

[Hakan]

Dan.....
Nice tip and my adding here is maybe obvious but a possible helpful reminder:
If you change the code in one plugin be sure to:
-Build only "plugin"_pi for debug
-Run the .bat file to copy the new dll to \plugins
-Build entire OCPN for debug

[rgleason]

If you change the code in one plugin be sure to:
-Build only "plugin"_pi for debug
-Run the .bat file to copy the new dll to \plugins
-Build entire OCPN for debug

Hakan,
Do you build only the "plugin_pi" for debug, under MSVC++ by finding and selecting the "plugin_pi.sln" which is usually found under the plugin's build directory?

--How do you get the plugin_pi.sln into the 'build' directory? Don't you have to run "cmake -T v120_xp .." and "cmake --build . --config release' from the command prompt first? Probably easiest to do this on the entire local repository for all of opencpn?

I've been using the standalone version and building the debug version then copying the debug .dll over, but then there is the need for "data" directory etc. so I end up copying the entire standalone into the opencpn repos. I suppose I should be doing a git clone of the plugin from the plugins directory?

[Hakan]

Rick..
Sorry, it may be I misunderstood basics here. I was referring to my own method where I have the plugin inside OCPN repository beside Dashboard etc.
That's my way to be able to debug a plugin. But my case it's rather simple since I extend it with only one _pi, BR24....
I haven't tried to debug and breakpoint a plugin from outside O.

To get a plugin inside O's repository I (git)clone it at my "C:\Builds\OCPN\OpenCPN\plugins\".
Git will then handle that plugin individually and you can make local branches and commits.
The main OCPN Git will not handle every detail in the added plugin but you'll have to commit that "Something has happened" to the plugin. The disadvantage is you can't make a plugin only installation package from inside OCPN. For that you'll have to have also an "outside" plugin repository where you can implement your debugged changes from the "inside" plugin.

I'm not sure if I succeed to describe it understandable??
Håkan

[Hakan]

Rick...
This is then my OCPN repository:

[transmitterdan]

Hakan's method is what I also use. Develop/debug the plugin inside the OpenCPN tree. Then when it is in fully committed to git and ready for distribution, clone the repository to it's own tree outside of all other git structures. Then build the installation package from there.

It is easier for me to debug plugins this way and I don't have to modify the source code of OpenCPN as others have suggested. Their method works too but for me the method Hakan and I use seems "more natural".

[rgleason]

Hakan and TDan that's very helpful. Thankyou.

Hakan, just a question about this:
The main OCPN Git will not handle every detail in the added plugin but you'll have to commit that "Something has happened" to the plugin.
--so MSVC++ will ask? for my affirmation? Or I "commit" something?

[rgleason]

Hakan,

As well as cloning from the "C:\..github\OCPN\OpenCPN\plugins\"
you might be interested to know, that I can copy a standalone plugin into the plugin directory "C:\..github\OCPN\OpenCPN\plugins\" and rename it, and I can then use the MSV++ command prompt in that plugin under the "build" directory with cmake to make a debug dll that can be copied or even a release dll. Haven't tried making a release dll and then an executable with "cpack" but I think it might work.

I think I need to get a handle on this debug routine! and develop some better skills.

[rgleason]

wxWidgets debug alert. If I hit "no" I can just continue.
Do you guys know what this is from? Can I just hit cancel and forget it happens?
The program seems to come up and run after that.

[Hakan]

rick..
re: "--so MSVC++ will ask? f"
No, MSVC don't care for history, That's Git's task.

re:"As well as cloning from the "C:\..github\OCPN\OpenCPN\plugins\" ......... I can copy a standalone"
Yes, but if you use Git to clone it, from it's origin master, you'll have use of Git's features of history control and possibilities to back off any changes to prior stage.

re: "wxWidgets debug alert."
I use to cancel that one. Haven't seen any disadvantages.

And, yes, the debug/release dll's are always created for each plugin by MSVC builds and can be copied to use wherever you like. We were talking about the installation setup creation.

Normally I don,t use cmake for anything else than to create the build environment for MSVC. After big changes to the repository, like a new plugin, I may delete what's in \build and rerun cmake -T v120_xp .. and my bat file to copy all files and binaries needed for debug and release build. (Attached as an example - delete .pdf and edit path to fit your repo)
Håkan

[rgleason]

Jon's reply:

You need to build the plugin with 'DEBUG' set in the mode at the top of the VC screen. You then need to copy the dll to the build_dir\plugins directory. I add the plugin project file to the solution package for opencpn (File/Add/Add existing project). Now you should be able to debug by running the main opencpn exec, i.e. just start debug.

I do this all in VM and sometimes have issues with screen redraws, particularly with opengl, but I can get by. You may not have these issues if you are using a native windows box.

[hasse_A]

Hi!

I am trying to run VS2013 debugger on my gxradar_pi under OpenCPN-4.4.0 and I get no ethernet data on m_sock->RecvFrom().
Building the plugin by itself and installing it under OpenCPN-4.4.0 it works fine but not in Visual Studio.
Anyone got any idea ?

/Hans