Development Debugging Environment - Setup Help

[nohal]

Hans...
I'm slowly but surely running out of ideas... Tried with your cache file on my system (just changing the paths to program files as my system is 32bit) and can't reproduce. Can you try to upgrade to cmake 3.1 to eliminate the possibility of 3.02 being buggy?

Pavel

[hasse_A]

Pavel ....

Yes, absolutely. I will upgrade cmake. I will be back...... tomorrow.

/Hans

[transmitterdan]

Originally Posted by hasse_A

Pavel .....

It's getting quite late over here. I think I will have to get horizontal now.
Have to be up at 06:00. Will be at it tomorrow again.

There are some other peculiar things.
VS2010 wants to rebuild ZERO_CHECK every time I start debugging.....
Post what ever you find out and I'll check tomorrow.

/Hans

In VS2010 if you look at the left "Solution Explorer" and find OpenCPN and right click you will see Debug->Start new instance. If it asks to rebuild anything just say no. The debugger should start and show put you at the main loop of OpenCPN. You can't run the debugger from the toolbar in my experience.

P.S. This assumes you have already built the debug version from the command line using:

cmake --build . --config debug

[nohal]

When you right-click on the opencpn project in the solution explorer, select "Set as Startup Project". It will turn bold and since then you are a happy camper.

Pavel

[hasse_A]

Pavel, transmitterdan ....

Originally Posted by nohal

When you right-click on the opencpn project in the solution explorer, select "Set as Startup Project". It will turn bold and since then you are a happy camper.

Pavel

Yeah, I have set the Startup project to opencpn. I just think that the fact that it wants to rebuild ZERO_CHECK is telling us that something is not right.
Have other things to attend to this morning. Will be back later.

/Hans

[hasse_A]

Pavel ...

Ok, got an hour to spare.
Uninstalled CMake 3.0.2, installed CMake 3.1.0.
Notice : even though I clicked in Add PATH to all users" I had to add that manually.

Purged all of OpenCPN. (even the stable release downloaded from the site).
git clone git://github.com/OpenCPN/OpenCPN.git
cd OpenCPN
git fetch --all
mkdir build
cd build
cmake -G "Visual Studio 10" ..

All looks ok this far.

When I do

cmake --build . --config debug

I get :
CMake Error : The source directory "C:....../OpenCPN/build/debug"
does not exist.



/Hans

[hasse_A]

Pavel, transmitterdan ....

I did a new install of the tool chain on another computer, also win7.

Now it looks like I can build the debug buildon this new machine, but same strange problem with the release build.

/Hans

[transmitterdan]

Hans,

I have a batch file that clones, configs then builds release and debug. It also copies all the data files as necessary. I'm testing it now against current git head. If it works I will post it here for you to try. I have to run the .bat file in the visual studio 2010 command prompt.

[transmitterdan]

Hans,

From an empty folder I run this doit.bat file. It clones from git and then does all the configuration, building and copying of data files. It builds both debug and release then runs the debug version to make sure it all went according to plan.

I just ran this a few minutes ago and it build both debug and release and they both run without error. It has to run in a Visual Studio 2010 command prompt.

[transmitterdan]

There is something I don't understand and maybe could be improved in the debugging environment. If I build and run O from the command line then I have to put the uidata, tcdata, plugins, etc. in both debug and release folders. This doesn't make sense to me that I have to copy them twice but ok I do it. Further, if I want to build and debug from Visual Studio 2010 I also have to copy these same data folders into the build folder too. So I end up having to copy them 3 times to 3 different folders else O will not run in one case or another. Same thing goes for the plugins as well. I have to copy the plugins to these same folders else O cannot find them in one case or another. The three cases I use are:

Build and run O from command line in release folder
Build and run O from command line in debug folder
Build and run O from VS 10 in debug config

[hasse_A]

transmitterdan ......

Yes, your batch file seem to work for both debug and release.
At least on the second computer I set up.

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

/Hans

[hasse_A]

One thing.

In VS2010, if start in Release mode i can see the grib and the dashboard lug ins, but not if start in debug mode.

Am I missing something. I want to be able to debug the plugin I am working on.

/Hans

[nohal]

Originally Posted by transmitterdan

There is something I don't understand and maybe could be improved in the debugging environment. If I build and run O from the command line then I have to put the uidata, tcdata, plugins, etc. in both debug and release folders. This doesn't make sense to me that I have to copy them twice but ok I do it.
Further, if I want to build and debug from Visual Studio 2010 I also have to copy these same data folders into the build folder too. So I end up having to copy them 3 times to 3 different folders else O will not run in one case or another. Same thing goes for the plugins as well. I have to copy the plugins to these same folders else O cannot find them in one case or another. The three cases I use are:

Build and run O from command line in release folder
Build and run O from command line in debug folder
Build and run O from VS 10 in debug config

You don't have to copy the data several times. They should go just to the topmost build folder as said in the instructions, at least that's how it works for me. Ideally they should be loaded from the source folder. Care to undertake the task?
If you want to debug plugins, you have two options - copy them or change https://github.com/OpenCPN/OpenCPN/b...nager.cpp#L236 to point to the actual location of the plugin you are debugging, eg.

m_plugin_location = _T("c:\\me\\opencpn\\build\\plugins\\myplugin_pi\\Debug");

I much prefer this second option, of course.

Pavel

[nohal]

Originally Posted by hasse_A

One thing.

In VS2010, if start in Release mode i can see the grib and the dashboard lug ins, but not if start in debug mode.

Am I missing something. I want to be able to debug the plugin I am working on.

/Hans

The debug and release plugin libraries are not the same at all - they use different libs (from the VC through wx to whatever else you are linking)
When you run your Release build, it loads the standard plugins, I suppose. When you run your Debug build, loading these DLLs fails.
In short: You can't mix binaries between debug and release.

Pavel

[hasse_A]

Originally Posted by nohal

When you run your Release build, it loads the standard plugins, I suppose. When you run your Debug build, loading these DLLs fails.
In short: You can't mix binaries between debug and release.

Pavel

Sorry, I don't understand this.
Why would it pick the Release build plugins when I run the Debug build from VS2010 ?
Will the build tree be infected in some way if I ever run in Release ?
Would it be safer to never build the Release build ?

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

/Hans