Plugin Distribution

[seandepagnier]

I discussed with nohal the possibilities of "make package".

This command creates deb and rpm on linux, and installers for windows (and possibly mac) and is used for the main program.

To make this work for plugins, we need the plugins to be able to compile from a directory outside of the main source tree. This means modifying the cmakelist for opencpn to also install ocpn_plugin.h as well as other changes. This is the only real reason in my opinion to avoid the so-called external dependencies in plugins as well. Any takers?

[rgleason]

I believe there was a developer who was making stand alone pluggins that he compiled separately for his version of opencpn. I believe he had a github reppository with all the pluggins so they compilied separately. who was that.....?...?

[rgleason]

Tried to search Github, but could not find the repository. He sent notices to all the plugin developers advising of his effort..... There don't seem to be remnants of that effort in github now or I am not looking in the right place...I believe he had a forked repository of most of the plugins and was compiling the plugins as Stand alone.

[bdbcat]

Rick, et al...

The s63 PlugIn build/install system does most of what is wanted here:

1. Builds standalone.
2. Makes installers for Windows/Mac/Linux
3. Copies auxiliary files during install.
4. In windows, honors existing OCPN install by looking at registry.
5. In Windows, keeps its own registry entries, to manage upgrades.

Take a look. If it does not work for an average developer, I'd like to fix it so that it will. And maybe it becomes the root for other PlugIns.

https://github.com/bdbcat/s63_pi

Dave

[rgleason]

Wow, I've looked at it on github. How do you do so much? I looked at notes and readme and various files, looking for where we modify the files to compile a different plugin and make exe install. I think the first thing to do is to just download and compile the S-63 you've provided. Then learn.

I now must hand over my Computer to my wife because her machine lost its Hard Disk. Will try it later.

Thanks for the big boost in the right direction.

[rgleason]

I've followed the readme doc and have created a directory

c:/s63_pi_build and git cloned [bdcat/s63_pi] & copied opencpn.lib

From the MSVC command prompt at that directory executed

"C:\Program Files (x86)\CMake 2.8\bin\cmake" -G "Nmake Makefiles"

and got

C:\s63_pi_build>"C:\Program Files (x86)\CMake 2.8\bin\cmake" -G "Nmake Makefiles
"
CMake Error: Could not create named generator Nmake Makefiles

C:\s63_pi_build>"C:\Program Files (x86)\CMake 2.8\bin\cmake" -G "Nmake Makefiles
"
CMake Error: Could not create named generator Nmake Makefiles

[bdbcat]

Rick....

Probably the MSVC build tools are not in your path.

You will do better to open a DOS command prompt from the menu inside VS2010. e.g. Tools->Visual Studio Command Prompt.

This will automatically set up the environment so that the build tools can be found.

Good Luck
Dave

[seandepagnier]

Built s63 plugin outside of opencpn source tree. Notice ocpn_plugin.h is copied into the plugin tree. I would prefer that this file gets installed with opencpn is there a reason against this?

[bdbcat]

Sean...

s63_pi build tree is new stuff, still Beta. I manually copied the latest ocpn_plugin.h into the build tree, just to move it along. Have not really thought this through yet.

How would you recommend that we handle this?

Please recall that a PlugIn needs only that ocpn_plugin.h which corresponds to the API the PlugIn chooses to use. It is not necessary, and even a little bit wrong to coerce older PlugIns to require the latest include file.

All ideas appreciated
Dave

[rgleason]

Does copying the Opencpn.lib into the directory contain the "symbols" for that version?
If so, would it be possible to have a resource on the opencpn.org downloads, that contains the appropriate opencpn.lib files for :

Opencpn v3.2.2 (Plugin API X.x) ---> opencpn.lib
Opencpn v3.3.x (Plugin API x.x) ---> opencpn.lib

etc
Then we could compile a plugin for a certain version of Opencpn without having to setup the binaries for that version of Opencpn. For example, I need to setup Opencpn 3.2.2 to compile the Statusbar_pi plugin and perhaps Climatology_pi because I've deleted it from my machine a little while ago.

[seandepagnier]

Originally Posted by bdbcat

Sean...

s63_pi build tree is new stuff, still Beta. I manually copied the latest ocpn_plugin.h into the build tree, just to move it along. Have not really thought this through yet.

How would you recommend that we handle this?

Please recall that a PlugIn needs only that ocpn_plugin.h which corresponds to the API the PlugIn chooses to use. It is not necessary, and even a little bit wrong to coerce older PlugIns to require the latest include file.

All ideas appreciated
Dave

Yes, good point. Maybe it is best to copy the file for now and if a good solution comes along change it.

I have modified all of my plugins to build in their own tree, and greatly simplified CMakeLists.txt for them. My build setup is based on a combination of the s63_pi, what was before, and I was able to to put almost all the logic in plugin independent cmake files (this is still evolving)

I can make deb packages for linux as well for every plugin, but there is a slight issue with data directories I am sorting out. Take a look at watchman_pi and hopefully someone can fix/verify it can build installers for windows and macosx:

https://github.com/seandepagnier/watchdog_pi

Originally Posted by rgleason

Does copying the Opencpn.lib into the directory contain the "symbols" for that version?
If so, would it be possible to have a resource on the opencpn.org downloads, that contains the appropriate opencpn.lib files for :

Opencpn v3.2.2 (Plugin API X.x) ---> opencpn.lib
Opencpn v3.3.x (Plugin API x.x) ---> opencpn.lib

etc
Then we could compile a plugin for a certain version of Opencpn without having to setup the binaries for that version of Opencpn. For example, I need to setup Opencpn 3.2.2 to compile the Statusbar_pi plugin and perhaps Climatology_pi because I've deleted it from my machine a little while ago.

This is only due to a symbol getting renamed to having _Plugin in the beta which was not renamed in 3.2 that the statusbar uses, and hopefully this situation will never occur again. Climatology should build against beta and work with 3.2 Perhaps I should instead release statusbar for 3.3/3.4?

[rgleason]

From MSVC Tools > Visual ...Command Prompt.
Then cd to C:\s63_pi_build
Then execute the command

Setting environment for using Microsoft Visual Studio 2010 x86 tools.

c:\program files (x86)\microsoft visual studio 10.0\vc\bin>cd C:\s63_pi_build

C:\s63_pi_build>dir
 Volume in drive C is OS
 Volume Serial Number is B845-7168

 Directory of C:\s63_pi_build

02/22/2014  05:24 PM    <DIR>          .
02/22/2014  05:24 PM    <DIR>          ..
02/22/2014  05:24 PM    <DIR>          buildlinux
02/22/2014  05:24 PM    <DIR>          buildlinux64
02/22/2014  05:24 PM    <DIR>          buildosx
02/22/2014  05:24 PM    <DIR>          buildwin
02/22/2014  05:05 PM            17,788 CMakeLists.txt
02/22/2014  05:24 PM    <DIR>          data
02/22/2014  05:05 PM             5,948 Notes
02/22/2014  05:05 PM           147,102 NSIS.template.in
02/22/2014  05:05 PM            24,870 opencpn.ico
02/18/2014  04:57 PM           100,574 opencpn.lib
02/22/2014  05:24 PM    <DIR>          po
02/22/2014  05:05 PM               944 README
02/22/2014  05:24 PM    <DIR>          src
               6 File(s)        297,226 bytes
               9 Dir(s)  414,262,513,664 bytes free

C:\s63_pi_build>"C:\Program Files (x86)\CMake 2.8\bin\cmake" -G "Nmake Makefiles
"
CMake Error: Could not create named generator Nmake Makefiles

C:\s63_pi_build>"C:\Program Files (x86)\CMake 2.8\bin\cmake" -G "Nmake Makefiles
"
CMake Error: Could not create named generator Nmake Makefiles

C:\s63_pi_build>"C:\Program Files (x86)\CMake 2.8\bin\cmake" -G "Nmake Makefiles
"
CMake Error: Could not create named generator Nmake Makefiles

C:\s63_pi_build>

Sorry for the newbie question, but what is Nmake? I have used cmake..... Is that the problem?

[rgleason]

I have modified all of my plugins to build in their own tree, and greatly simplified CMakeLists.txt for them. My build setup is based on a combination of the s63_pi, what was before, and I was able to to put almost all the logic in plugin independent cmake files (this is still evolving)

I can make deb packages for linux as well for every plugin, but there is a slight issue with data directories I am sorting out. Take a look at watchman_pi and hopefully someone can fix/verify it can build installers for windows and macosx:

https://github.com/seandepagnier/watchdog_pi

This is great Sean. Once I understand / fix the problem I am having compiling independently s63_build I think I can help.

[rgleason]

This might help.

C:\s63_pi_build>path
PATH=
c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\;
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN;
c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v3.5;
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\VCPackages;
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;
C:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;
C:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;
C:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;
C:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\jZip;
C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\CMake 2.8\bin;
C:\Program Files (x86)\Codebox\BitMeterOS;
C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Inte\WirelessCommon\;
C:\Program Files (x86)\Poedit\bin;C:\Program Files (x86)\Git\bin;C:\wxWidgets-2.8.12\lib\vc_dll

C:\s63_pi_build>

[bdbcat]

Rick...

NMake is the Microsoft equivalent of make.

Please post the output of the command:

"C:\Program Files\CMake 2.8\bin\cmake"

The key part of mine looks like this:

Generators

The following generators are available on this platform:
  Borland Makefiles           = Generates Borland makefiles.
  MSYS Makefiles              = Generates MSYS makefiles.
  MinGW Makefiles             = Generates a make file for use with
                                mingw32-make.
  NMake Makefiles             = Generates NMake makefiles.
  NMake Makefiles JOM         = Generates JOM makefiles.
  Unix Makefiles              = Generates standard UNIX makefiles.
  Visual Studio 10            = Generates Visual Studio 10 project files.
  Visual Studio 10 Win64      = Generates Visual Studio 10 Win64 project
                                files.
  Visual Studio 6             = Generates Visual Studio 6 project files.
  Visual Studio 7             = Generates Visual Studio .NET 2002 project
                                files.
  Visual Studio 7 .NET 2003   = Generates Visual Studio .NET 2003 project
                                files.
  Visual Studio 8 2005        = Generates Visual Studio .NET 2005 project
                                files.
  Visual Studio 8 2005 Win64  = Generates Visual Studio .NET 2005 Win64
                                project files.
  Visual Studio 9 2008        = Generates Visual Studio 9 2008 project files.
  Visual Studio 9 2008 Win64  = Generates Visual Studio 9 2008 Win64 project
                                files.
  Watcom WMake                = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles= Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
  Eclipse CDT4 - MinGW Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - NMake Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles
                              = Generates Eclipse CDT 4.0 project files.

You can see an entry in the available generators for NMake Makefiles. You should see something similar. If not, maybe your CMake installation is incomplete...

Dave