Support plugins available at link time

[frutiger]

A plugin available at link time is a static library that is provided as a link-time dependency of some other code. This other code may then freely use functions from the library as long the name of the exported symbols are known (e.g. through header files).

The code may also then be deployed without any further requirements. This stands in contrast to #13, which requires the using code and the shared library to be deployed together.

This would implement option (3) from #7.

[cppguru]

Same as for the dynamic one. The code linking the plugin in is not the
user. As it has no specific dependencies whatsoever to the plugin at all.
It's a third piece of code that uses the plugin, and that code should be
able to require the headers without creating a link time dependency. Why?
Because the user must not be aware if the module is dynamic or static.

On Mon, Feb 2, 2015 at 2:45 AM, Masud Rahman notifications@github.com
wrote:

A plugin available at link time is a static library that is provided as a
link-time dependency of some other code. This other code may then freely
use functions from the library as long the name of the exported symbols are
known (e.g. through header files).

The code may also then be deployed without any further requirements. This
stands in contrast to #13 #13,
which requires the using code and the shared library to be deployed
together.

This would implement option (3) from #7
#7.

—
Reply to this email directly or view it on GitHub
#14.

[frutiger]

All generated libraries have unspecified CMake library type; so static vs. dynamic libraries can be specified at CMake generation time using the BUILD_SHARED_LIBS flag. Either type of library can be linked to at link time.