Setup to Compile OpenCPN in Windows

[rgleason]

Dan,

I forgot to "Get the Binary Dependencies" !

Now that I've fixed that and I think OpenCPN is compiling and not getting any errors, I think the weatherfax_pi that I git cloned into ...github/OpenCPN/plugins/ into a new weatherfax_pi directory. seems to be throwing lots of errors after cmake -T v120_xp .. and cmake --build . -config debug on the entire github/OpenCPN/build

I have copied the weatherfax_pi dependencies into ..\GitHub\OpenCPN\plugins\weatherfax_pi\buildwin

but these errors still occur. weatherfax-errors.txt

I am trying to get a debug setup for various plugins with weatherfax_pi being the first one. Sean's plugins have various small issues and I want to get them fixed, but identifying the lines that are bad. Also it will be a skill I should have, and I am going to try to write it up more completely.

[rgleason]

Ok, so now I have removed the github/OpenCPN/plugins/weatherfax_pi directory and re run the compile commands, and OpenCPN compiles with no errors for both Debug and Release, and "cpack" starts NSIS and builds the installer.

Now I have to get weatherfax_pi debugging going.

[rgleason]

I also had to follow my previous writeup very carefully for copying files and directories to get Debug working.

https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:developer_guide:compiling_windows#step_by_step_manual_copy_of_setup_files

The batch files would have been easier, and I have them right in the text!

Anyway, I now have MSVC++ reinstalled and working.

Also, I've copied weatherfax_pi (data directory and PVW32.exe into github/OpenCPN/plugins. Then also copied it to .. GitHub\OpenCPN\build\plugins And put weatherfax_pi.dll from the standalone debug directory.

And it seems to work.

[transmitterdan]

The scripts here make debugging "easy". There are 3 main scripts that do 99% of the work.

There is also a seldom used but handy script called clone_opencpn.bat. This script takes one or two arguments. The first argument is your github username. It will clone your fork of opencpn into a folder the same as your github username. If you don't like that folder name you can give a second argument and it will create that folder name and clone opencpn into it. Then it calls the configure.bat file to set up the build process.

If you have set up the environment variable WXDIR correctly then running configure.bat in the opencpn\build folder will detect your version of Visual Studio and run the Cmake process. I recommend getting the latest version of Cmake. Old versions of Cmake can cause problems.

The other 2 main scripts are build.bat and dbbuild.bat. These scripts build release or debug versions of OpenCPN. I use these all the time. Run them in the opencpn\build folder.

A helper script is Osetup.bat. For VS2013 I add a call to Osetup.bat in the "Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat". It goes here:

`@rem VisualStudioVersion @rem ------------------- @set VisualStudioVersion=12.0

@rem Local stuff @rem ------------------- @call \storage\transmitterdan\BatchUTILS\Osetup.bat @goto end `

Now for the fun part. After you run dbbuild.bat you can start the VS IDE with this command from the build folder:

opencpn.sln

Then when VS IDE opens do these steps: 1) Set opencpn as the startup project. 2) Choose debug mode then open the opencpn properties sheet (right click and select Properties). Under Configuration Properties->Debugging add to the Command Arguments these 2 letters -p. This runs O in portable mode. That way the debugging environment is mostly isolated from your regular OpenCPN installation. All the settings you change here stay local to the debug environment and do not affect your regular installation. 3) To debug a plugin that comes with OpenCPN (e.g. Dashboard) all you have to do is set a breakpoint and click "Local Windows Debugger". O will start and when that line is executed in a plugin the debugger will break.

To debug any other plugin the easiest way is to add that plugin's project to the opencpn\plugins folder. This is the so-called build in place method. The dbbuild.bat script will visit all plugins and build them. It will also copy all plugins to the debug folder. So you have an environment much like a regular installation except is it isolated to the build\debug folder.

If your plugin will not build inside the OpenCPN build environment (some plugins don't) not to worry.

Build the debug version of the plugin as normal. Copy the dll and other files to opencpn\build\debug folder.

Using a VS command prompt go to the opencpn\build\debug folder and run this command:

opencpn -p

This will start the debug version of O.

Then open the plugin in the VS ide (open the plugin's .sln file). There is a debugging option in VS to connect to an already running process. Just connect to opencpn.exe and then you should be able to set breakpoints in your plugin.

Debugging plugins is not for the faint of heart. If you tell me what specific issue you are having with a plugin I will give a look to see if I can find the problem.

[rgleason]

TDan, These batch files appear to be more advanced than the ones I have in Dev wiki compile section of yours & Hakan's. I liked both versions. Hakans could be used for quick runs and yours for more extensive setup.

I would like to reorganize the wiki compile document to make it simpler for debug with the release stuff as an option at the end. I still want to list all the files source & destination.

The question I have is, should we reference this git repos and remove all the older files? Also we should have a insructive section for the batch files?

[rgleason]

I need to try these to learn more.

[transmitterdan]

Rick,

I keep updating these as I learn more about the prerequisites for building OpenCPN. They are more complex because there are now 3 compilers and multiple versions of wxWidgets (2.8, 3.0, 3.1). Using these scripts one can create O with any of the compilers and various versions of wxWidgets.

Eventually we will be forced to adopt a newer compiler. VS 2013 is getting pretty long in the tooth as is wxWidgets 3.0.

Maybe I could start a thread for windows builders. I could show how the scripts automate the process. I am pretty busy with work right now so time is a bit limited.

[CaptPat]

Dan, Rick - I have VS141 (2017) as my compiler, CMAKE 3.9.2, and wxWidgets 3.1.0 - I've built wxWidgets libraries from source, and also built wxrc.exe (built in utils separately), and now am trying to get opencpn to build - svg did not find cairo/cairo.h - and thus wxSVG lib is not available - but other warnings look mostly non-fatal - deprecated uses, macro redefines, unref'd local variables, etc. I then installed GTK 2.12.9 devkit and pointed wxsvg includes at that cairo.h and cairo-features.h... If I can provide you with the V141 build files perhaps we could also support VS 2017... Best, CaptPat

[CaptPat]

I picked up expat from sourceforge v 2.2.4 - added an include to the build for wxsvg, and that builds now... https://sourceforge.net/projects/expat/, Best, CaptPat

[CaptPat]

I found this version of cairo on github prebuilt - it looks like it's complete and stand-alone. https://github.com/preshing/cairo-windows/releases, I took the includes and the x86 Lib from this, as the GTK release referenced above had headers for compile but not the standalone cairo.lib for the link step. Best, CaptPat

[CaptPat]

The DEBUG build generated 76 warnings - they all look like typical legacy code things or cross-platform compatability things. I can post the list if that helps - but I'll first try to get to NSIS and see how to install the target binary for testing. Best, CaptPat

[CaptPat]

F:\Github\OpenCPN\buildwin\NSIS_Unicode seems to be where the NSIS dependencies reside, but I am getting an error:
Error: Can't open "@CPACK_NSIS_DIR@/UI/opencpn_ui.exe"! Error in macro MUI_INTERFACE on macroline 54 Error in macro MUI_PAGE_INIT on macroline 3 Error in macro MUI_PAGE_WELCOME on macroline 5 Error in script "F:\Github\OpenCPN\NSIS.template.in" on line 547 -- aborting creation process

I don't see where CPACK_NSIS_DIR is set. I "built" all 4 targets in another directory tree (F:\OPCPNBuild) - but i think i need to build the installer and install this version locally to run it - i see crshhandler1403.dll etc is present etc, and the other dependencies - but without the nullsoft installer i'm likely not going to get to the next step:) Thanks for any advice, CaptPat

[rgleason]

CaptPat, You're adept at programming than I obviously. You can be a good help. We do have the binaries necessary on sourceforge. Please read the development manual for compiling. It is good. I think.

[rgleason]

I think it might help and you won't need to reinvent so much. Very good that you have tried newer versions, but sometimes there are problems that need solving. Best.s

[CaptPat]

I'm WAY out of date:) it will take a while to catch me up...:) thanks for the pointers...

[rgleason]

I think it might help and you won't need to reinvent so much. Very good that you have tried newer versions, but sometimes there are problems that need solving. Best. Rick

[rgleason]

I am trying to improve weatherfax_pi opening screens because critical commands do not show. Which is bad for new users. I have used Formbuilder 3.5 to get this fixed, but when I save the changed fbp file, recompiled debug, and copied the new dll to the msvc++ github/opencpn/plugins and my changes are not showing!

What is the process and how should I be doing this?

[rgleason]

I think a tread for windowsbuilders would be good. There is an old Development Environment thread.

[CaptPat]

Rick - I'm deep in the Compiling Windows page you linked to - I had skimmed it, but not all the stuff about NSIS cpack at the end:) I have gotten a "release" build to run, but not with the plugins yet - I think there was a compiler error that matters wrt to the plugins and will check into that... Thanks for the pointers, I think I see how to get around most of the wrinkles in the build right now... Best, CaptPat

[transmitterdan]

Guys,

You do not have to go looking all over the internet for Cairo and other bits and pieces. All you need to build OpenCPN with VS is right at your fingertips. If something is missing then you did something wrong.

Here are some questions:

Do you have 7-zip (7z) and git installed and in the path? You need that to be able to get O and unzip the buildwin dependencies.

If you have 7-zip and git installed here is what I recommend as a test:

1) Open a Visual Studio command window 2) Create a folder close to the root of a drive. For example: mkdir \testing and move into it with: cd \testing 3) In the testing folder type this command: git clone https://github.com/transmitterdan/BatchUTILS.git 4) Add BatchUTILS to the path with this command: path c:\testing\BatchUTILS;%PATH% 5) Type: set "WXDIR=C:\wxWidgets-3.0.2" Note: If you are using a different wxWidgets version stop and get wxWidgets-3.0.2. There are issues using wxWidgets 3.1 which is why we don't use it. Make sure WXDIR points to a proper version of wxWidgets 3.0.2. 6) While still in the testing folder type: clone_opencpn transmitterdan otest Or if you have your own fork substitute your GitHub username for transmitterdan in above command.

7) Then type: cd OpenCPN\build 8) Then type: dbbuild

If all goes well you will have built a debug version of OpenCPN. If you want to test it do this:

cd Debug opencpn.exe -p

This runs opencpn in portable mode locally from the debug build folder.

If you want to run opencpn in the debugger do this in the build folder:

opencpn.sln

That command opens the opencpn project files.

Set opencpn as the startup project. Select debug version at the top drop-down list. Open project properties->debugging and add -p to the command arguments. Close properties. Then click "Local Windows Debugger" and you should see OpenCPN as normal but running in the debugger.

If any problems report back here and I will help sort it out.

[CaptPat]

Dan - latest "stable" wxwidgets seems to be 3.0.3 - getting 3.0.2 seems to be a sourceforge DL and presumably rebuild it? Thanks, Pat

[transmitterdan]

Version 3.0.3 should be ok.

[transmitterdan]

Go here: http://wxwidgets.org/downloads/ and download the Windows installer for 3.0.3.

Don't forget that you have to build debug and release versions of the DLLs if you want to debug OpenCPN. If you only want to build the release version of O then you don't have to build the DLLs. But I would strongly recommend that you build the DLLs per the instructions in section 2.1 of https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:developer_guide:compiling_windows

[CaptPat]

so 3.0.3 installs but they did not compile wxrc in utils to produce wxrc.exe ... where do you get that exe? It seems to be needed later in the OpenCPN build?

[rgleason]

Tdan, Will try batchutlils in the morning, but have to go pick tomatoes too (farm work). (:-)

Can you offer any insight on using formbuilder, otherwise i xan ask in CF.

[transmitterdan]

Pat,

What error do you get from compiling wx 3.0.3? I typed in the 2 command lines exactly as written in section 2.1 and it compiled both debug and release dlls the first time with no errors. So something is wrong with your setup if you get any errors compiling wx. if we fix that then maybe we will solve your problem.

[transmitterdan]

Pat,

What error do you get from compiling wx 3.0.3? I typed in the 2 command lines exactly as written in section 2.1 and it compiled both debug and release dlls the first time with no errors. So something is wrong with your setup if you get any errors compiling wx. if we fix that then maybe we will solve your problem.

[transmitterdan]

Rick,

Wxformbuilder is a tool that writes C++ code. Then you have to compile that code. The difficulty with it is that you cannot edit the C++ code to fix little bugs. If you do then the next time you chage something in the forms your C++ change will be overwritten. So a lot of programmers use for builder to get a basic layout done then they stop using the forms and manually edit the C++ code thus abandoning the forms forever. It could be that is what has happened to weather fax plugin. I guess the issue you have can be fixed with a little editing of the C++ code. When I get some time I will take a look. What is the location of the plugin sources?

[rgleason]

TDan, Thanks for the explanation. I've figured it out how to run it.See other thread. Also I've fixed the problem and have improved the layout in other ways. Will upload to O file thingie and make a PR to sean.

[rgleason]

TDan, Thanks for the explanation. I've figured it out how to run it.See other thread. Also I've fixed the problem and have improved the layout in other ways. Will upload to O file thingie and make a PR to sean. I'll also update my wxroute repos.

[rgleason]

TDan wrote "Don't forget that you have to build debug and release versions of the DLLs if you want to debug OpenCPN."

Just want to clarify...this is regard to the internal plugins wmm, chartdownloader, grib, dashboard.

Other plugins act similar, however for debug only degug version needs compiling, same with release. -- isn't this correct TDan?

[rgleason]

PS sidetracked by weatherfax today. Will try batch utils tomorrow. But am on road to ct from chicago tomorrow.

[transmitterdan]

Rick,

Windows DLLs have to build in the same mode as the application. So if you want to debug a plugin you should build a debug version of O and a debug version of the DLL. I think the DLL will not load otherwise.

There is some convoluted thing you can do to debug a DLL if you don't have a debug .exe file but it's not worth the trouble.

[rgleason]

TDan, You have updated BatchUtils. Should I also git fetch and git merge? Or will this change my setup? Yes, I think I changed paths etc in certain files, so I should make a branch for me "Rick-setup" and commit each file that was changed.

Then I think I checkout master and git fetch and gir merge to get current with your version on master.

Then what do i do with branch "rick-setup" to get current?