Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the packaging and out of the tree build system #2

Closed
wants to merge 13 commits into from

Conversation

nohal
Copy link

@nohal nohal commented Nov 17, 2014

J-E...
I'm converting all the plugins to the new unified packaging system. Should work without any problems on all the platforms.

Pavel

@SethDart
Copy link
Owner

I'm reluctant to #include "ocpn_plugin.h" in every project.
I'd rather create a opencpn-devel package that'd install it under /usr/include/ocpn_plugin.h and use that one.
I know it'd not be portable for windows but we could come with an option --with-ocpn-plugin=/path/to/ocpn_plugin.h

Thanks

@SethDart
Copy link
Owner

We may also include shared cmake files

@nohal
Copy link
Author

nohal commented Nov 17, 2014

But how do you want to handle the (normal) situation when you will work on plugins with different API compatibility levels? Not easily doable using the dev package even on Linux...
Not including ocpn_plugin.h will at the end have only one effect: Total confusion.

@SethDart
Copy link
Owner

What do you mean with "plugins with different API compatibility levels"?
The same plugin behaving differently for different API version?
Or the plugin built for different API version?

For the latter, you can do it with --with-ocpn-plugin=/path/to/ocpn_plugin_api_vXXX.h
If you're packaging it, you can require a different opencpn-devel version in your spec file and the builder will do the job.

@nohal
Copy link
Author

nohal commented Nov 17, 2014

While I can imagine several workarounds to make it work on Linux. I can't imagine anybody on Windows or OS X being able to follow the logic, really. For example on Windows, you can't even link the plugin without the right combination of the header and opencpn.lib, unfortunately. I also don't have capacity to maintain the dev packages on all the platforms and am not aware of anybody who would.
But feel free to prove me wrong, of course - If it works and somebody will maintain it, it is no doubt the cleanest solution.

@SethDart
Copy link
Owner

Don't get me wrong, I'm trying to find the best solution.

If I follow your logic, we should also include opencpn.lib or the plugin may not be built on Windows for this particular header file.

Please let's follow this on the forum to see how it goes:
http://www.cruisersforum.com/forums/f134/plugin-distribution-120929-4.html

Thanks

@nohal
Copy link
Author

nohal commented Apr 14, 2022

Made obsolete by history

@nohal nohal closed this Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants