On 2018-07-18 14:16, Peter Kjellerstedt wrote:
-----Original Message-----
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Carlos Rafael Giani
Sent: den 17 juli 2018 11:35
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/6] gstreamer1.0-plugin-base: Update
packageconfigs
* Always enable zlib, since it is part of oe-core, and dependencies that
are in oe-core can be always enabled
Just because it can be enabled does not mean it should be unconditionally
enabled. If building for an environment where, e.g., flash memory is scarce,
every byte counts. Keeping the packageconfig and leaving it enabled by
default will give the same result, but for someone trying to remove anything
they do not need, it is then more obvious that the jpeg dependency is
optional and can be removed if wanted.
* The jpeg packageconfig is not needed, since there are no configuration
switches to enable or disable it, and libjpeg-turbo is part of oe-core
Same here as for zlib.
* libpng is a dependency, and is part of oe-core, so add it to DEPENDS
This too is optional and should have a packageconfig (which can be
enabled by default since it is pulled in anyway due to other dependencies).
Well, okay, I can add them back in. However, there are no config
switches for the jpeg support. If someone enables a shared sysroot, and
there's libjpeg, gst-plugins-base will enable its support.
* There is no libvisual recipe in oe-core or in meta-openembedded, so
the visual packageconfig needs to go
* Reorder the packageconfigs alphabetically
You also add dependencies on libgudev and libdrm, without mentioning it here.
Why is this? They too are optional, and they have not been needed before.
If you want to add support for them, then do so by adding packageconfigs
(which I don't think should be enabled by default to maintain the
configuration as it was).
These are now needed for the Mesa GBM based EGL contexts. However, just
as with jpeg, there are no config switches for them. Now that you
mention it, yeah, it makes more sense to patch this..
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
