[Buildroot] [PATCH] package/gstreamer1/gst1-plugins-good: Optionally select GUDEV
Yann E. MORIN
yann.morin.1998 at free.fr
Mon Jun 1 08:01:59 UTC 2020
Ezequiel, Nicolas, All,
On 2020-05-31 21:05 -0300, Ezequiel Garcia spake thusly:
> On Sun, 2020-05-31 at 22:49 +0200, Yann E. MORIN wrote:
> > On 2020-05-31 10:53 -0300, Ezequiel Garcia spake thusly:
> > > From: Nicolas Dufresne <nicolas.dufresne at collabora.com>
[--SNIP--]
> > > + select BR2_PACKAGE_LIBGUDEV if BR2_PACKAGE_HAS_UDEV
> > The title is a bit misleading: gudev is not optional; instead, it is
> > forcibly selected when udev is enabled.
>
> How about "package/gstreamer1/gst1-plugins-good: Select GUDEV if available"
As I see it, gudev is optional, and brings the whole libglib2 stack
behind it. Do we really need to forcibly select it?
I mean: can't we just keep the part in the .mk, to guarantee the build
ordre when libgudev is enabled?
> > > +ifeq ($(BR2_PACKAGE_LIBGUDEV),y)
> > > +GST1_PLUGINS_GOOD_DEPENDENCIES += libgudev
I.e. we just keep that part.
> > I think we would also need to add:
> > GST1_PLUGINS_GOOD_CONF_OPTS += -Dv4l2-gudev=enabled
> > and the converse when ghudev is not enabled:
> > GST1_PLUGINS_GOOD_CONF_OPTS += -Dv4l2-gudev=disabled
> You made me dig on this a bit closer :-)
That was my intention. ;-)
> v4l2-gudev is a meson feature, auto-detected by default,
> so the above is not required to enable it on the build.
>
> The same applies to v4l2-libv4l2, so it seems to me
> enabling/disabling is not needed.
We want explcit enableing/disabling of optional features when there is
an option for that: this ensures that the buildsystem of the package
does not accidentally picks up the headers or libs from the host by
chance (e.g. a build on an x86 host for an x86 target).
By the look of it, that val2-gudev option is exactly about controlling
use of gudev:
option('v4l2-gudev', type : 'feature', value : 'auto',
description : 'Use libgudev for probing v4l2 devices')
So, is this correct, that this option controls use of gudev?
> If the library is present, the only thing needed is
> the xxx_DEPENDENCIES change, to enforce a build order.
>
> The story is different for the v4l2 option. It's also
> an auto-detected feature, but we are interested
> in controlling its enable/disable state.
Regards,
Yann E. MORIN.
> > Regards,
> > Yann E. MORIN.
> >
> > > +endif
> > > +
> > > ifeq ($(BR2_PACKAGE_LIBV4L),y)
> > > GST1_PLUGINS_GOOD_CONF_OPTS += -Dv4l2-libv4l2=enabled
> > > GST1_PLUGINS_GOOD_DEPENDENCIES += libv4l
> > > --
> > > 2.26.0.rc2
> > >
> > > _______________________________________________
> > > buildroot mailing list
> > > buildroot at busybox.net
> > > http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list