GStreamer 1.0 meson build transition

GStreamer 1.0 meson build transition

[Carlos Rafael Giani]

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

Re: GStreamer 1.0 meson build transition

[Ross Burton]

On 26/10/2019 11:57, Carlos Rafael Giani wrote:
> 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.

That's fine, but there is value in doing the migration separately to the 
1.16->1.18 upgrade: there should be no difference to the installed files 
which makes verification easier.

Basically I've no opinion on when the meson migration is merged, as you 
say it's not trivial, but please have it as a separate commit to an upgrade.

Thanks,
Ross

Re: GStreamer 1.0 meson build transition

[Carlos Rafael Giani]

Hm, true. Alright, I'll do that. For discussions about the recipe 
changes, should I create a fork of oe-core and place them there, just 
like how one would prepare merge requests? To me, it sounds more 
efficient than posting the patches in the mailing list for discussing them.

And speaking of upgrades, my changes are against 1.16.1, so the 1.16.0 
-> 1.16.1 upgrade needs to make it into master-next in first.

Carlos

On 28.10.19 17:44, Ross Burton wrote:
> On 26/10/2019 11:57, Carlos Rafael Giani wrote:
>> 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.
>
> That's fine, but there is value in doing the migration separately to 
> the 1.16->1.18 upgrade: there should be no difference to the installed 
> files which makes verification easier.
>
> Basically I've no opinion on when the meson migration is merged, as 
> you say it's not trivial, but please have it as a separate commit to 
> an upgrade.
>
> Thanks,
> Ross

Re: GStreamer 1.0 meson build transition

[Ross Burton]

On 28/10/2019 23:01, Carlos Rafael Giani wrote:
> Hm, true. Alright, I'll do that. For discussions about the recipe 
> changes, should I create a fork of oe-core and place them there, just 
> like how one would prepare merge requests? To me, it sounds more 
> efficient than posting the patches in the mailing list for discussing them.

You can create a fork to ease merging, but review happens by patches 
sent to this list.

> And speaking of upgrades, my changes are against 1.16.1, so the 1.16.0 
> -> 1.16.1 upgrade needs to make it into master-next in first.

Queued in ross/mut already.

Ross