Development Debugging Environment - Setup Help

[nohal]

Originally Posted by hasse_A

Sorry, I don't understand this.
Why would it pick the Release build plugins when I run the Debug build from VS2010 ?

Look at your logfile, you will see from where and what it tries to load.

Will the build tree be infected in some way if I ever run in Release ?

Nope.

Would it be safer to never build the Release build ?

No, it really does not matter.

When locking at the sizes the debug plugins -ddl's are almost twice as large.
I suppose this is as it should be.

Yes, because they contain debugging symbols.

Pavel

[hasse_A]

Hmmmmm!

When running Release it's looking for the dll in :

6:18:41 PM: PlugInManager searching for PlugIns in location C:\Users\hasse\Documents\master\OpenCPN\build\Rele ase\plugins

which is correct.

When running Debug it's looking in :
6:14:11 PM: PlugInManager searching for PlugIns in location C:\Users\hasse\Documents\master\OpenCPN\build\plug ins

which is not correct. Should be

C:\Users\hasse\Documents\master\OpenCPN\build\Debu g\plugins

So that's the obvious reason why I don't see them in Debug.
What controls this ?

/Hans

[transmitterdan]

Originally Posted by hasse_A

When running Debug it's looking in :
6:14:11 PM: PlugInManager searching for PlugIns in location C:\Users\hasse\Documents\master\OpenCPN\build\plug ins

which is not correct. Should be

C:\Users\hasse\Documents\master\OpenCPN\build\Debu g\plugins

So that's the obvious reason why I don't see them in Debug.
What controls this ?

/Hans

When running from command line it looks in the plugins folder below where the .exe is. But when run from VS2010 it looks for plugins folder below the build folder. I think this is an artifact of how VS2010 starts the executable. The executable does not think it started in the debug folder but rather it thinks it is running in the build folder. My solution is to put the debug plugins in both the build and debug folder. Then it works as you want it to. I put the release plugins in the release folder only. I never run the release executable in the debugger.

[transmitterdan]

Originally Posted by hasse_A

Why not let your batch file copy the files and directories ?

/Hans

It does copy all the data and plugin files and directories needed to run O from command line. I will update it to copy the data and plugin files need to debug and upload it again.

Does anyone else think automating the git clone and first time build is a bad thing? I might be able to make the batch file generic enough that pretty much anyone could begin debugging. But there may be some merit in making it a bit of a treasure hunt to ensure only the truly motivated try it. It took me about 5 days to sort out in my mind how to get all the command line methods working.

[nohal]

If you want to debug a plugin (which you usually do from inside VS), the easiest is to modify https://github.com/OpenCPN/OpenCPN/b...nager.cpp#L236 as I suggested earlier. I think you can believe me, I have written a few of them

Pavel

[transmitterdan]

Ok, you can try this batch file in an empty folder. It will clone O from latest git head and build the debug and release (including the default plugins). Then it sets up the debug environment so you can debug O or the default plugins from VS 2010.

To debug in VS 2010 you have to open the .sln file in the build folder. Then you can make OpenCPN the startup program if you like but what works for me is to right click OpenCPN in the solution explorer and select "Debug->Step Into new instance".

Let me know if it works or not for anyone else.

[rgleason]

Like to show directories involved.

C:\..\GitHub\OpenCPN\build
C:\..\GitHub\OpenCPN\build\Debug
C:\..\GitHub\OpenCPN\build\release

C:\..\GitHub\OpenCPN\build\plugins\grib_pi\Debug
C:\..\GitHub\OpenCPN\build\plugins\grib_pi\Release
C:\..\GitHub\OpenCPN\build\plugins
- Dlls copied to this dir
- Use debug.dll version to debug a plugin
- If for some reason you want to run a plugin_release.dll you can.
- OR use Pavel's nice technique to change path

Transmitter Dan in your Batch file
When you create and copy the directories
uidata
s57
tcdata
sounds
gsshs
etc,

What is the command robocopy? I am unfamiliar with it.

[rgleason]

Robocopy

http://technet.microsoft.com/en-us/m.../ee851678.aspx

[hasse_A]

Originally Posted by transmitterdan

Let me know if it works or not for anyone else.

Thanks transmitterdan!

I have added the gxradar plugin to your script and have tested that
on 2 of my computers.

On the one without the scanner all work as expected and the plugins are there as they should be.
Since there is no scanner attached it wont find it but I am able to
debug gxradar_pi.

On the other computer all works as in the first one.
However I have a problem not receiving the packets into the plugin.

I do see the packets in Wireshark.

I had this working earlier as can be seen in the plots in the Garnin xHD thread.

I am not a pro on C++ and network programming so it would be nice if someone with better knowledge had a look at it.

In gxradar.cpp

Line 762
Line 3082

And there about.

I think the problem with building is solved and I will continue in the xHD radar thread.

Tanks to all of you that has put in time and effort.

/Hans

[ewzachmann]

Running linux eclipse...doing a build and I hit this...

I have libjasper_dev installed (1.900.1)...so why does not

...
line 73: FIND_PACKAGE(Jasper REQUIRED)
...
find it?

-- *** Staging to build grib2_pi ***
-- Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR)
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
Could NOT find Jasper (missing: JPEG_LIBRARIES) (found version "1.900.1")
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-2.8/Modules/FindJasper.cmake:45 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
plugins/grib2_pi/CMakeLists.txt:73 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!
See also "/home/eric/OpenCPN/build/CMakeFiles/CMakeOutput.log".
make: *** [cmake_check_build_system] Error 1

[nohal]

Try...

sudo apt-get install libjpeg-dev

Pavel

[ewzachmann]

DOH!

Thanks Pavel

[ewzachmann]

Hi Pavel,

What kind of shape is grib2_pi in? I can run it, download grib files etc, but I keep getting SegFaults when viewing data. I like this method of getting grib data and am wondering about the grib_pi plugin. I guess I'm asking for a little history of the plugins. I saw that there was a request to get grib2 data into/for the grib_pi. I'd also rather be doing web requests for data instead of email requests.

Thanks again for your help
Eric

[nohal]

Broken
All I did at the time was fixing it to build. Never had a closer look at the code.

Pavel


Sent from my iPhone using Cruisers Sailing Forum

[transmitterdan]

O has a lot of developers (ok, maybe not a lot but more than a couple) and so it has a standard build environment making collaboration easier. Maybe I haven't looked at enough of the plugins to be certain of what I am about to say so feel free to "educate" me. My experience is that the various plugins don't integrate into the base O development tree the same as the in-built plugins. For example, almost every plugin I have tried to build has an issue with where to look for opencpn.lib. Some (most?) have Cmake dependency issues. None so far will build right out of git like O will.

Does it make sense to have a plugin development "style guide" so that all plugins can be pulled from git into the O environment and have the build just work out of the box? This would seem to make collaboration on plugins easier. Or is it the case that plugin development is so personal that there is no desire or need for large group collaboration?