Delivering plugins to users

[axxie]

How the external plugins are supposed to be delivered to end users?

1. It is clear that in-tree plugins are built together with far2l.
2. It look like that out-of-tree plugins are de facto also build together with far2l. Authors recommend putting them under the tree, modifying the CMakeLists.txt and building far2l as usual.
3. This leads to the need to build far2l if you want to use some out-of-tree (external) plugins. This renders prebuilt binaries, such as .deb packages, less useful.

It is clear that in general case the software is delivered to user in source code form in Linux/Unix world. What is the far2l model?

[shmuz]

In my limited experience it is not necessary to build far2l when one wants to build an external plugin.
But I do use header files from the far2l source tree (farplug-wide.h, farcolor.h, farkeys.h and WinPort directory).

[elfmz]

From WinPort you need only WinCompat.h windows.h WinPort.h and may be sudo.h (you need later only if you know that you need it)
Potentially its possible to create far2l-dev package that would put all this stuff into /usr/include/far2sdk and then build plugins truly independently, but i rather sure nobody did it yet.

[axxie]

Ok, as I understand really there two questions:

1. How to build plugins out of tree
2. How to distribute plugins

The first one is not an issue: the plugin developer can use the far2l tree for this purpose.
The questions is, is such binary really usable?
Or users should be building plugins against some "far2l sdk"?

[shmuz]

This leads us back to the original question: how to distribute plugins?

FWIW, my plugins are supposed to be built by the user. Unpack from GitHub's zip and run make.

[unxed]

As for me and my plugins, I am ready to follow a guideline for plugin developers if potential plugin user's UX can benefit from it. Still no such guideline exists currently.

[axxie]

Let's use this issue for creating the guideline.
What are our options?

1. Totally source-level: placing into far2l tree and building
2. Far2l-SDK: only sdk is required for build, the far2l can be obtained from .deb
3. Prebuild: Authors build binaries for multiple platforms
4. Separate .deb packages, for example, far2l-plugins with all currently known plugins
5. Build on demand: some infrastructure to build plugins online and obtain binaries for your platform from there (not much different from item 3, but can benefit from centralized approach)
6. Your variant?

[axxie]

7. Just add all known external plugins into the tree, commit them to far2l repo, and always build together with far2l. Users then should be able to enable and disable them.

[elfmz]

All are possible, separate standalone binary level distribution is unusual in nix world, unlike Windows. Either distributive-specific package with all information about its dependencies, either sources.
Standalone binary may work, but need to minimize its dependencies i.e. leaving only libc.so.6 visible in ldd will make it compat with most distributives. Most but still not all, as there are other libc 'flavors' beside of glibc.