Sean Depagnier's Plugins

[cagney]

Originally Posted by rgleason

By the way, the note above is about the 2/23/2014 compile. Currently a number of the plugins are not compiling succesfully in msvc++ as stated two notes above.

Sent from my GT-N5110 using Cruisers Sailing Forum mobile app

I updated all the plugins. 7 did not compile!!
Typical output

[ 94%] Building CXX object plugins/climatology_pi/CMakeFiles/climatology_pi.dir/src/climatology_pi.cpp.o   
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp: In member function ‘virtual int climatology_pi::GetPlugInVersionMajor()’:
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp:143:14: error: ‘PLUGIN_VERSION_MAJOR’ was not declared in this scope
       return PLUGIN_VERSION_MAJOR;
              ^
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp: In member function ‘virtual int climatology_pi::GetPlugInVersionMinor()’:
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp:148:14: error: ‘PLUGIN_VERSION_MINOR’ was not declared in this scope
       return PLUGIN_VERSION_MINOR;
              ^
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp: In member function ‘virtual int climatology_pi::GetPlugInVersionMajor()’:
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp:144:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp: In member function ‘virtual int climatology_pi::GetPlugInVersionMinor()’:
/home/thomas/Testing/GitHub/OpenCPN_alpha/OpenCPN/plugins/climatology_pi/src/climatology_pi.cpp:149:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
make[2]: *** [plugins/climatology_pi/CMakeFiles/climatology_pi.dir/src/climatology_pi.cpp.o] Error 1
make[1]: *** [plugins/climatology_pi/CMakeFiles/climatology_pi.dir/all] Error 2
make: *** [all] Error 2

[rgleason]

Sean, I realize we are transitioning to a new way of working that will hopefully be more effective. With separate compiling plugins etc. Let me know if there is anything I can do to help. I know this kind of transition takes some time.


Sent from my GT-N5110 using Cruisers Sailing Forum mobile app

[seandepagnier]

Originally Posted by cagney

I updated all the plugins. 7 did not compile!!
Typical output

Lots of people are confused. The plugins no longer build within the opencpn source tree. This means you must make a build directory, and run cmake from this directory for each plugin. This allows the use of "make package"


So far I have built all of my plugins as well as the installer binary packages (either .deb .exe installer for windows) with success on:
1. linux64 (gcc and clang-llvm)
2. linux32 inside a chroot
3. mingw cross compiler for windows under linux
4. mingw native compiler for windows under wine

Soon I will be building windows 64 binaries as well as opencpn could theoretically benefit from more than 4gigs of ram on systems that have this. Eventually I may attempt building using llvm to build binaries and installers for macosx, but I will probably wait a year or two before I bother with this one.

If you are using visual studio, it may break, but I tried to keep things working. I don't think it will be very hard to fix this one.

For example, after cloning watchdog_pi:

cd watchdog_pi
mkdir build
cd build
cmake ..
make
make install

If you want to try using mingw, either cross compiling, or native, see the mingw thread, the instructions for the main program are the same as for any plugin.

I hope this clears things up. Maybe it is more annoying to build all the plugins this way, if you don't like it, write a script to automate it. Since you need to git clone each plugin individually anyway, the script would improve that.

I continue to update the build system as I discover problems, but as of today I think it is basically all working well.

[rgleason]

Awesome can't wait to try it.
Passed ham technical and general just this morning. Missed extra by 4. Hope to pass next month and use it taking friends boat across to England in june.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[cagney]

Sean

I know I'm confused ...

I started with the astro nav plugin and the build system works.
But, make package creates files in /usr/local... while all O packages are looking in /usr..... Also, it was not possible to change this.
Running

cmake -DPREFIX=/usr ../

I had this response

CMake Warning:
Manually-specified variables were not used by the project:

PREFIX

Thomas

[seandepagnier]

So make install and make package are both putting files in /usr/local correct?

Very good point. We need to address this one. When I compile opencpn from source, it puts everything in /usr/local, so everything works, but I suppose you must be using the prebuilt debian package which is in /usr? This means that maybe the make package should be built for /usr, but I dont know how to do this unless make install also targets /usr. Maybe it can search for opencpn and target wherever it is installed?

opencpn could include both /usr/lib and /usr/local/lib in the search path for plugins, so that if users manually compile plugins they are in /usr/local/lib/opencpn, but if installed with installer in /usr/lib/opencpn This proves a slight technical difficulty as the routine which tells the plugin where it's data is, needs to be modified so that depending on the location of the shared object it can find the correct data. What do you think?

For now, maybe you can try

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..

[cagney]

Sean
Any package made for a wider distribution should use /usr, while those used locally are OK with /usr/local. I have a mixture of both on my box.
I'm thinking of making packages for wider distribution, and then /usr is what O uses and the standard says. But there is no problem with this, as your suggestion

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../

works.

Next, naming of the packages created.
I get, for example

celestial_navigation_pi_1.8-_.deb

while I expected

celestial_navigation_pi_1.8-1_amd64.deb

Thomas

[seandepagnier]

I think we should manually set the prefix to /usr if you plan to distribute the package. I have fixed the package naming for celestial navigation, so you will get the expected filename now. Other plugins to will follow.

Thank you for the feedback.

[seandepagnier]

I have been playing around with actually installing the packages:

 dpkg -i package.deb

Despite what prefix is used (which sets where make install goes) the relevant files are always using a prefix of /usr for the packages, so I'm confused why the prefix needs to be set at all now.

[cagney]

Originally Posted by boat_alexandra

I have been playing around with actually installing the packages:

 dpkg -i package.deb

Despite what prefix is used (which sets where make install goes) the relevant files are always using a prefix of /usr for the packages, so I'm confused why the prefix needs to be set at all now.

I just tested this, and I got the expected result. Files went to /usr/local !
Something fishy with your build environment, ...perhaps.

[seandepagnier]

Could you try the packages I built for climatology? I am using a prefix of /usr/local, but these seem to install in /usr

opencpnplugins - Browse /climatology_pi at SourceForge.net

[cagney]

Well, then your prefix isn't working, because both the 32 & 64 bits packages are made for /usr , so that's where they will install.
I'm just checking with "ark" or "xarchiver", no need to install.

[seandepagnier]

What version of cmake? I am using latest git plus a small patch I wrote to support xz compression for deb packages.

[cagney]

Originally Posted by boat_alexandra

What version of cmake? I am using latest git plus a small patch I wrote to support xz compression for deb packages.

Strange.... I can repeat your problem with climatology. Using "make install", installs in /usr/local, but make package installs in /usr, in spite of the scripted prefix.
Surprisingly I used an old version of cmake, located in /usr/local/bin:cmake version 2.8.6
Using the main Ubuntu version in usr/bin, 2.8.11.2, made no difference however.

[rgleason]

Sean,
I've sent 4 emails, one from a different address and I am still getting blacklisted. Don't know why. So I will post it here.

Copied recent Opencpn.lib to c:/o-plugins/watchdog_pi/build
and ran what is below, stil need to use ">cmake --build c:/o-plugin/watchdog_pi"
to get it to run, but there are two less errors.
Also I just ran it from my standard cmd prompt this time, no real difference from MSVC++ command prompt.

=== what ran in prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Rick>cd C:\o-plugin\watchdog_pi\build

C:\o-plugin\watchdog_pi\build>cmake ..
-- *** Building watchdog_pi ***
-- Found OpenGL...
-- Lib: glu32opengl32
-- Include:
-- import lib: opencpn.lib
-- Install Prefix: C:/Program Files (x86)/watchdog_pi
-- Configuring done
-- Generating done
-- Build files have been written to: C:/o-plugin/watchdog_pi

C:\o-plugin\watchdog_pi\build>cmake --build .
Error: could not load cache

C:\o-plugin\watchdog_pi\build>cmake --build c:/o-plugin/watchdog_pi
Microsoft (R) Build Engine version 4.0.30319.18408
[Microsoft .NET Framework, version 4.0.30319.18444]
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 3/9/2014 7:10:59 PM.
Project "c:\o-plugin\watchdog_pi\ALL_BUILD.vcxproj" on node 1 (default targets).

Project "c:\o-plugin\watchdog_pi\ALL_BUILD.vcxproj" (1) is building "C:\o-plugin
\watchdog_pi\ZERO_CHECK.vcxproj" (2) on node 1 (default targets).
InitializeBuildStatus:
Creating "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbui ld" because "Always
Create" was specified.
FinalizeBuildStatus:
Deleting file "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbui ld".
Touching "Win32\Debug\ZERO_CHECK\ZERO_CHECK.lastbuildstate" .
Done Building Project "C:\o-plugin\watchdog_pi\ZERO_CHECK.vcxproj" (default targ
ets).
Project "c:\o-plugin\watchdog_pi\ALL_BUILD.vcxproj" (1) is building "C:\o-plugin
\watchdog_pi\watchdog_pi.vcxproj" (3) on node 1 (default targets).
Project "C:\o-plugin\watchdog_pi\watchdog_pi.vcxproj" (3) is building "C:\o-plug
in\watchdog_pi\watchdog-i18n.vcxproj" (4) on node 1 (default targets).
InitializeBuildStatus:
Creating "Win32\Debug\watchdog-i18n\watchdog-i18n.unsuccessfulbuild" because "
AlwaysCreate" was specified.
CustomBuild:
watchdog_pi-i18n: Done.
FinalizeBuildStatus:
Deleting file "Win32\Debug\watchdog-i18n\watchdog-i18n.unsuccessfulbuild".
Touching "Win32\Debug\watchdog-i18n\watchdog-i18n.lastbuildstate".
Done Building Project "C:\o-plugin\watchdog_pi\watchdog-i18n.vcxproj" (default t
argets).
InitializeBuildStatus:
Touching "watchdog_pi.dir\Debug\watchdog_pi.unsuccessfulbui ld".
CustomBuild:
All outputs are up-to-date.
ClCompile:
All outputs are up-to-date.
ManifestResourceCompile:
All outputs are up-to-date.
Link:
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPO
RT:QUEUE /OUT:"C:\o-plugin\watchdog_pi\Debug\watchdog_pi.dll" /INCREMENTAL /NOLO
GO /LIBPATH:"C:/wxWidgets-2.8.12/lib/vc_dll" /LIBPATH:"C:/wxWidgets-2.8.12/lib/v
c_dll/Debug" kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.li
b oleaut32.lib uuid.lib comdlg32.lib advapi32.lib "C:\wxWidgets-2.8.12\lib\vc_dl
l\wxbase28ud.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wxmsw28ud_core.lib" "C:\wxWidg
ets-2.8.12\lib\vc_dll\wxbase28ud_net.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wxbase
28ud_xml.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wxmsw28ud_html.lib" "C:\wxWidgets-
2.8.12\lib\vc_dll\wxmsw28ud_adv.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wxpngd.lib"
"C:\wxWidgets-2.8.12\lib\vc_dll\wxtiffd.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wx
jpegd.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wxzlibd.lib" "C:\wxWidgets-2.8.12\lib
\vc_dll\wxregexud.lib" "C:\wxWidgets-2.8.12\lib\vc_dll\wxexpatd.lib" winmm.lib c
omctl32.lib rpcrt4.lib wsock32.lib glu32.lib opencpn.lib /MANIFEST /ManifestFile
:"watchdog_pi.dir\Debug\watchdog_pi.dll.intermedia te.manifest" /MANIFESTUAC:"lev
el='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:/o-plugin/watchdog_pi/Debug/watc
hdog_pi.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/o-pl
ugin/watchdog_pi/Debug/watchdog_pi.lib" /MACHINE:X86 /DLL watchdog_pi.dir\Debug\
watchdog_pi.dll.embed.manifest.res
watchdog_pi.dir\Debug\watchdog_pi.obj
watchdog_pi.dir\Debug\WatchdogDialog.obj
watchdog_pi.dir\Debug\WatchdogPrefsDialog.obj
watchdog_pi.dir\Debug\Alarm.obj
watchdog_pi.dir\Debug\WatchdogUI.obj
watchdog_pi.dir\Debug\icons.obj -L../buildwin /debug
LINK : warning LNK4044: unrecognized option '/L../buildwin'; ignored [C:\o-plugi
n\watchdog_pi\watchdog_pi.vcxproj]
LINK : fatal error LNK1104: cannot open file 'opencpn.lib' [C:\o-plugin\watchdog
_pi\watchdog_pi.vcxproj]
Done Building Project "C:\o-plugin\watchdog_pi\watchdog_pi.vcxproj" (default tar
gets) -- FAILED.
Done Building Project "c:\o-plugin\watchdog_pi\ALL_BUILD.vcxproj" (default targe
ts) -- FAILED.

Build FAILED.


"c:\o-plugin\watchdog_pi\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\o-plugin\watchdog_pi\watchdog_pi.vcxproj" (default target) (3) ->
(Link target) ->
LINK : warning LNK4044: unrecognized option '/L../buildwin'; ignored [C:\o-plu
gin\watchdog_pi\watchdog_pi.vcxproj]


"c:\o-plugin\watchdog_pi\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\o-plugin\watchdog_pi\watchdog_pi.vcxproj" (default target) (3) ->
(Link target) ->
LINK : fatal error LNK1104: cannot open file 'opencpn.lib' [C:\o-plugin\watchd
og_pi\watchdog_pi.vcxproj]

1 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.50

C:\o-plugin\watchdog_pi\build>

On 3/9/2014 6:24 PM, Sean D'Epagnier wrote:
You are going to have to copy opencpn.lib to where it can
be found, I put it in a folder named buildwin in the plugin folder,
although this could change in the future. I would like to see this
file get installed with the main program.

Sean