[OE-core] [RFC] Transitioning GStreamer 1.0 recipes to meson

Fri Dec 13 11:33:26 UTC 2019

Are your patches in good shape? Please send them here if so, now is a good
time to get them merged.
So that we don't have to later deal with 1.18.0 upgrade and meson
transition at the same time.

Alex

On Tue, 29 Oct 2019 at 22:21, Carlos Rafael Giani <crg7475 at mailbox.org>
wrote:

> Hello all,
>
> I have managed to transition most GStreamer recipes to meson. The
> patches can be found here:
> https://github.com/OSSystems/meta-gstreamer1.0/tree/transition-to-meson
>
> The only recipe that still uses autotools is gst-validate, and that's
> because the tarball does not contain meson scripts. This is a known
> issue. https://gitlab.freedesktop.org/gstreamer/gst-devtools/issues/28
>
> Overall, this worked well in my test builds, both on an i.MX6 machine
> and in a qemux86-64 VM.
>
>
> Please note that this requires the 1.16.0 -> 1.16.1 changes I posted to
> the mailing list a few days ago.
>
>
> Noteworthy changes:
>
> - A lot of autotools/M4 related patches are just gone. Well, obviously
> :) But it is surprising just how much fewer patches there are now.
>
> - gstreamer1.0-libav no longer builds its own FFmpeg copy. This was done
> in the past because there were no stable versioned FFmpeg releases. They
> do exist now, so in meson based builds, gst-libav just builds the actual
> plugin code, meaning that the build time is much shorter, most of the
> recipe code (and all of the patches) are gone (because they were FFmpeg
> specific), and the libgstlibav.so binary in /usr/lib/gstreamer-1.0/ is
> much smaller. This also means that FFmpeg specials do not have to be
> added both to the FFmpeg and to the gstreamer1.0-libav recipe anymore.
>
> - gstreamer1.0-plugins.inc was replaced by
> gstreamer1.0-plugins-common.inc, and gst-plugins-package.inc by
> gstreamer1.0-plugins-packaging.inc . These names are clearer.
> gst-plugins-package.inc in particular was named that way because it used
> to be shared between GStreamer 0.10 and 1.0 recipes. Since the former
> are gone by now, there's no point in keeping that name.
>
> - gstreamer1.0 ptest is now done differently. Originally, make was
> installed on the target and the Makefile was run by the run-ptest
> script. Now, gstreamer is patched to allow for installable tests that
> are accompanied by individual shell scripts that set up the necessary
> environment variables, along with .test files so that the
> gnome-desktop-testing test runner can be used in run-ptest to run the
> unit tests. This also makes it possible to inherit from ptest-gnome in
> the gstreamer1.0 recipe. The patch against gstreamer is necessary
> because by default, one runs the test by executing "meson test". I don't
> think installing meson along with all of the necessary meson.build
> scripts is a practical approach.
>
> - OpenGL packageconfigs now work quite differently in
> gstreamer1.0-plugins-base, since the meson options distinguish between
> OpenGL APIs, platforms, and windowing systems.
>
> - zlib in gstreamer1.0-plugins-base and -good is now required. I don't
> think this is a big deal, since it is also a dependency of GLib itself,
> so zlib has to be present on the rootfs anyway.
>
>
> There are some TODOs left that I want to bring up here for discussion:
>
> - The aforementioned PTest approach needs some review. Also, initially,
> I thought I'd have to add PTest support to several GStreamer recipes,
> which is why I isolated the ptest code in gstreamer1.0-ptest.inc . But
> it turned out that only the gstreamer1.0 recipe needs it. I am unsure if
> I should just merge that .inc into that recipe, since there's no reason
> why the tests from other recipes shouldn't be "ptest-ified" in the
> future. And then that .inc would be useful to have. (Tests from the
> plugin sets may be partially tough to run, since some of them create X11
> windows etc.)
>
> - The code in gstreamer1.0-ptest.inc sets up run-ptest in a rather
> uncommon way, since that file has to be autogenerated.
>
> - gstreamer1.0_1.16.1.bb and gstreamer1.0-plugins-common.inc both
> contain a "gettext_oemeson" function to set up meson NLS options.
> Ideally, this functionality would be part of the gettext bbclass itself.
> However, my bitbake/OE knowledge does not suffice to do that, since with
> meson, you want to be able to configure what the enable/disable flags
> should be ("enabled"/"disabled", "true"/"false" etc.); that's why for
> example the gtk-doc bbclass defines GTKDOC_MESON_OPTION,
> GTKDOC_MESON_ENABLE_FLAG, GTKDOC_MESON_DISABLE_FLAG. I am not sure how
> to combine such variables with this kind of custom python code, and
> still allow for customized values in other recipes. In other words, if I
> first get a "NLS_MESON_DISABLE_FLAG" value with getValue() in a modified
> gettext_oemeson function, then I might not get the value I expect, since
> it will get the initial value (the one set with ?=), not necessarily the
> one that is redefined by a recipe.
>
> - The OpenGL packageconfigs are handled by a get_opengl_cmdline_list
> function in gstreamer1.0-plugins-base_1.16.1.bb . I did this so that a
> comma-separated list can be generated out of the packageconfigs that are
> (a) part of PACKAGECONFIG and (b) part of the newly added
> OPENGL_APIS/OPENGL_PLATFORMS/OPENGL_WINSYS lists. I do not know if
> there's a better approach for this. The intent is that other layers
> (most notably BSP layers) can add custom packageconfig names to these
> lists. One example would be OPENGL_WINSYS += "viv-fb" in meta-freescale.
> Another would be OPENGL_WINSYS += "dispmanx" in meta-raspberrypi.
>
> - gstreamer1.0-python_1.16.1.bb currently has a problem in that the
> gst-python code tries to load /usr/lib/libpython3.7m.so. But, in a
> regular installation, only /usr/lib/libpython3.7m.so.1.0 would be
> availale. It is possible to adjust the libpython path & name during the
> build. But - what would it be adjusted to? How would the recipe know
> that "/usr/lib/libpython3.7m.so.1.0" is the correct choice? Or perhaps
> would it make sense to add the /usr/lib/libpython3.7m.so symlink to the
> regular (as in: non-dev) Python package?
>
>
> cheers,
>
>    Carlos
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191213/63c9d62b/attachment-0001.html>