Two years ago I wrote a blog post about using gst-build inside of WebKit SDK flatpak. Well, all that has changed. That’s the true upstream spirit.
There were two main reason for the change:
- Since the switch to GStreamer mono repository,
gst-buildhas been deprecated. The mechanism in WebKit were added, basically, to allow GStreamer upstream, so keeping
gst-builddirectory just polluted the conceptual framework.
- By using
gst-buildone could override almost any other package in WebKit SDK. For example, for developing gamepad handling in WPE I added
libmanetteas a GStreamer subproject, to link a modified version of the library rather than the one in flatpak. But that approach added an unneeded conceptual depth in tree.
In order to simplify these operations, by taking advantage of Meson’s subproject support directly,
gst-build handling were removed and new mechanism was set in place: Local Dependencies. With local dependencies, you can add or override almost any dependency, while flatting the tree layout, by placing at the same level GStreamer and any other library. Of course, in order add dependencies, they must be built with meson.
For example, to override libsoup and GStreamer, just clone both repositories below of
Tools/flatpak/local-projects/subprojects, and declare them in
WEBKIT_LOCAL_DEPS environment variable:
$ export WEBKIT_SDK_LOCAL_DEPS=libsoup,gstreamer-full $ export WEBKIT_SDK_LOCAL_DEPS_OPTIONS="-Dgstreamer-full:introspection=disabled -Dgst-plugins-good:soup=disabled" $ build-webkit --wpe
One thought on “From gst-build to local-projects”
I had a regular WebKitGTK build (no WEBKIT_LOCAL_DEPS set) and then enabled some dependencies to override just GStreamer:
export WEBKIT_SDK_LOCAL_DEPS_OPTIONS=”-Dgstreamer-full:introspection=disabled -Dgst-plugins-good:soup=disabled”
After that, when doing “run-minibrowser –gtk” or even when calling gst-inspect-1.0 inside the flatpak environment, I was getting this warning:
GStreamer-WARNING **: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.
I got rid of it by setting the path to the gst-plugin-scanner binary inside flatpak from the built dependencies:
The funny thing is that the warning was gone with the variable set… and also even with the variable unset the following times. This was one of those strange poltergeists that happen from time to time. It might be related to a stale registry cache file or something.
Anyway, I’m mentioning it here in case it’s useful to somebody else in the future.