Enable the building of a single, combined plugin per scheme.
Having separate plugins for different handler interfaces originally made some sense, as they were being loaded by different services (and could therefore be potentially deployed to different systems).
Since 20277644, all interfaces are loaded by the VTS, so having separate plugins for them no longer makes any sense.
Other reasons to combine plugins:
It shortens build time quite significantly. On my system, by about eight seconds:
$ for i in $(seq 1 3); do
make clean &>/dev/null && \
{ time make &>/dev/null; } 2>&1 \
| grep real | cut -f2;
done
0m19.769s
0m19.611s
0m19.635s
and with combined plugins:
0m11.876s
0m11.854s
0m11.883s
It results in less space being consumed on disk. The vast majority of the size of an executable is due to Go runtime.
actual scheme code only take up ~1-3M of the binary, with ~20M being Go runtime.
Both "docker" and "native" deployments already use combined plugins (for the reasons above). If someone creates a deployment, and then re-builds everything by doing "make", right now that would result in both combined and split plugin executables being inside scheme/bin/. If they then run vts pointing it at that directory (or copy it into a deployment), that will result in an error as the same implementation will be advertised by multiple plugins.
Enable the building of a single, combined plugin per scheme.
Having separate plugins for different handler interfaces originally made some sense, as they were being loaded by different services (and could therefore be potentially deployed to different systems).
Since 20277644, all interfaces are loaded by the VTS, so having separate plugins for them no longer makes any sense.
Other reasons to combine plugins:
and with combined plugins:
and with combined plugins:
actual scheme code only take up ~1-3M of the binary, with ~20M being Go runtime.