On 2018-07-19 14:12, Martin Jansa wrote:
On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:
As a general rule, I think adding packageconfigs to an oe-core recipe
that has dependencies outside of oe-core and meta-openembedded is
questionable. Take the qt5 packageconfig for example. It is *not* part
of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs
extra switches for passing paths to moc, uic etc.
I don't see what's questionable with that. PACKAGECONFIG is just a way
to pass configure options like EXTRA_OECONF just with benefit that it's
easily switched from outside and that it encapsulates build time and
runtime dependencies together with the options.
Now, what if a recipe outside of oe-core and meta-openembedded is just
like that? It needs its own customizations, its own switches. It would
be better off setting up its own packageconfig, just like what that
bbappend in meta-qt5 does.
If someone submits PACKAGECONFIG addition for something which only
exists in his own layer, I'm fine with that, why should we make it
harder for people to use oe-core or meta-oe recipes?
Adding a .bbappend that adds the packageconfig does not sound hard to
me. However, having packageconfigs whose dependencies may or may not be
dead (because of the layer being dead) sounds more like a maintenance
problem.
No I don't like that meta-qt5 has to use own bbappend for gstreamer,
it's necessary in this case because of the paths as you sad, but also
causes:
https://github.com/meta-qt5/meta-qt5/commit/73f99f2370a3dc5b81f42d0af7fe530431599454
which is quite annoying for meta-qt5 users, because this is one of very
few reasons why different meta-qt5 version isn't compatible with
different oe-core. So in order to use Qt 5.11 with oe-core from morty, I
need to BBMASK this bbappend and create the old one for
gstreamer1.0-plugins-bad in our project layer, it would be much nicer
and less error prone with PACKAGECONFIG directly in oe-core.
Agreed. This is a drawback. Unavoidable in this case, unfortunately.
Also if you look at EXTRA_OECONF you'll see either --disable-qt twice or
--disable-qt followed by --enable-qt (when we depend on configure to let
the last option on command line win) which isn't ideal as well and might
confuse people looking at the log.do_configure.
Hmm perhaps a bit, but the order matters, so I know that the last one
"wins". Multiple switches like that are not uncommon in automated build
environments, so I am used to seeing these.
I suppose with libvisual such a central packageconfig would work, but
isn't the whole idea of oe-core to be lean? And yet, now we start adding
more and more packageconfigs even though the recipes are in some other
layers that are not part of the central ones (oe-core and
meta-openembedded)?
Yes it's supposed to be lean as in number of recipes it needs to carry,
not lean by number of lines (PACKAGECONFIG is 1 line exactly as the
--diable flag in EXTRA_OECONF) or lean in number of ways how people are
able to use it.
Why should meta-openembedded have special status for PACKAGECONFIGs
anyway, if you want to make it harder to customize the build, why stop
there?
meta-openembedded isn't tied to any particular platform, BSP, distro,
environment. It does have a special place, since it is a central layer
for many setups. How many BSP layers, distro layers etc. list both
oe-core and meta-openembedded as dependency, for example? meta-debian
and meta-qt5-extra however do not have nearly the same status (and these
are the places where libvisual is).
You might as well add dozens of packageconfigs to
gstreamer1.0-plugins-bad, just in case some obscure layer adds a recipe
for OpenEXR or spandsp for example.
Yes, that's exactly what I often do, last time e.g. with libdrm
http://git.openembedded.org/openembedded-core/commit/?id=dc7d3b2ff79ae324b96a51ec1be557a432ed351d
and e.g. qemu before that, adding PACKAGECONFIG for dependencies which
I haven't submitted to meta-networking yet at that time:
http://git.openembedded.org/openembedded-core/commit/?id=ebb6ef1dbc7e03a4b7030b3056bd0fa59fdd047b
and I haven't submitted the recipe for virglrenderer yet as well and
I don't see any issue with having the PACKAGECONFIG for it already.
Eh, I don't think I can agree with that approach. Having an openexr
packageconfig for example implies that this packageconfig is actually
usable and gstreamer1.0-plugins-bad can be built with it enabled. But
adding it without an openexr dependency? Sounds broken to me. This is
why I prefer to keep such features disabled until there is a recipe for
them in meta-openembedded.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
