Let command line util peaq load the plugin statically
#29
Conversation
| peaq = gst_element_factory_make ("peaq", "peaq"); | ||
| if (!peaq) { | ||
| puts ("Error: peaq element could not be instantiated - is the plugin installed correctly?"); | ||
| puts ("Warning: peaq plugin is not installed - registering statically"); | ||
| GST_PLUGIN_STATIC_REGISTER(peaq); | ||
| } | ||
|
|
||
| peaq = gst_element_factory_make ("peaq", "peaq"); | ||
| if (!peaq) { | ||
| puts ("Error: peaq element could not be instantiated"); |
There was a problem hiding this comment.
Maybe unconditionally doing GST_PLUGIN_STATIC_REGISTER(peaq) is better? The only benefit of first trying to load the plugin dynamically seems to be that one could swap out the plugin for another version/implementation without modifying the executable. But that seem rather niche. OTOH, one could fall in the trap of updating the executable but not realizing that an outdated plugin is lingering somewhere. Opinion on that, @mincequi?
There was a problem hiding this comment.
Hi @martinholters,
well it depends, if you plan to re-use your plugin system-wide. But my assumption is: the gstreamer element is only supposed to be used within that tool and therefore no system-wide installation is needed.
In general i prefer statically linked stuff nowadays for easier library handling (installing shared libraries by bypassing the package manager is a mess).
Just my two cents ;)
There was a problem hiding this comment.
Well, either way, installation of the plugin (in a suitable location) would be optional. Actually, building it would be optional. And that's good, because I agree that most users won't deal with the plugin directly, but just use the executable. But if the plugin is built and installed, should it then be used by the executable, although it is statically linked anyway? I see no benefit in that. Or is there any problem if the executable invokes GST_PLUGIN_STATIC_REGISTER although the plugin is available dynamically? I'll try and see if anything can be made to break with an unconditional GST_PLUGIN_STATIC_REGISTER...
Maybe a compile-time setting would be nice:
- Option 1: Basically the status quo before this PR. Plugin and (slim) executable are built, plugin needs to be installed for executable to work.
- Option 2: No separate plugin is built, instead it is linked statically to and registered by the executable. No installation required.
But that might just not be worth it. Will need to ponder this a bit...
Another excerpt from #24 thanks to @mincequi.
It should be noted that this causes a significant relative increase of the executable size (more than 4 times, depending on architecture), but it's still quite small, so should be ok. Alternatively, a compile-time option to select between dynamic and static linking might make sense.