I've been working on migrating the GStreamer 1.0 recipes from autotools
to meson.
As expected, it is far from a straightforward change. Obviously,
autotools/m4 specific patches need to be discarded or replaced. But
there are also other differences, like how the OpenGL platforms and APIs
get selected, or how the unit tests are built and run. Some of these
changes are severe, and break not only the current way we do things in
the recipes, but also some gstreamer1.0 bbappends. Some packageconfigs
also changed. Certain checks are again done automatically without the
ability to explicitely enabling/disabling them (like valgrind checks),
so this needs patching again (ugh). gst-libav no longer has its own
libav/FFmpeg copy, and relies on an external one now. Furthermore, I've
had to create new nontrivial meson.build patches for proper ptest
functionality.
I think it would make sense to not try to get a meson based build done
for GStreamer 1.16, and instead target it for 1.18. Minor version
upgrades like 1.16.0 -> 1.16.1 aren't expected to bring major changes
with them, while major upgrades like 1.16 -> 1.18 are generally known to
potentially bring such changes. Also, there's a chance that new patches
might make their way into 1.18 before its release.
I write this in case anybody else is also working on meson, and/or
planning on upgrading the existing recipes once 1.18 is out, to avoid us
working in parallel on the same recipes without knowing. I'll push my
changes to a development branch in the meta-gstreamer1.0 recipes in a
few days so that people can bring in input if they want.
cheers,
Carlos
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
