-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
I'm reluctant to #include "ocpn_plugin.h" in every project. Thanks |
We may also include shared cmake files |
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... |
What do you mean with "plugins with different API compatibility levels"? For the latter, you can do it with --with-ocpn-plugin=/path/to/ocpn_plugin_api_vXXX.h |
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. |
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: Thanks |
Made obsolete by history |
J-E...
I'm converting all the plugins to the new unified packaging system. Should work without any problems on all the platforms.
Pavel