dominikschnitzer/musly — pull request #10 by f0k (2014-09-26 16:05:58+00:00)
Title: Explicitly register plugins when built statically

This PR fixes static builds of the library and command line client (with `BUILD_STATIC=1` in cmake). The issue was that the plugin self-registration code was only executed when loading libmusly as a shared library. When compiling it as a static library and statically linking a binary (such as the musly command line client) against it, the linker decided that the plugin classes are unused and did not include them.

To fix that, my original plan was to add a `musly_static_init()` function to the API that has to be called by binaries statically linking against the library to trigger registration of the plugins. But I found that it's enough to just define `static const plugin_creator_impl<...>` variables at the top of `lib.cpp`, which makes it easier for the user.
On a side note, I'm not sure why this is any different than registering them at the top of the `mandelellis.cpp`, `timbre.cpp` and `libav_0_8.cpp` files by initializing the `static const plugin_creator_impl<...>` class members (this is what was done before and is still done for dynamic builds now). Defining `static const` variables in these files instead of the class members did not help for static builds either, the definitions have to be placed in `lib.cpp`.

Note that `BUILD_STATIC=1` only builds the library statically; it still links dynamically against libgcc, libstdc++ and libav. The PR changes the description of `BUILD_STATIC` accordingly, but maybe we should change the build process instead.