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