| Message ID | 20221223093229.823322-1-mingli.yu@eng.windriver.com |
|---|---|
| State | Accepted, archived |
| Commit | 47b0bf034796b6f159110dae363fe11eab3eab08 |
| Headers | show |
| Series | gcr: add opengl to REQUIRED_DISTRO_FEATURES | expand |
Is OpenGL really mandatory for gtk4? Alex On Fri 23. Dec 2022 at 10.32, Yu, Mingli <mingli.yu@eng.windriver.com> wrote: > From: Mingli Yu <mingli.yu@windriver.com> > > Fixes: > $ bitbake gcr > ERROR: Nothing PROVIDES 'gtk4' (but > /build/layers/oe-core/meta/recipes-gnome/gcr/gcr_4.0.0.bb DEPENDS on or > otherwise requires it) > gtk4 was skipped: missing required distro feature 'opengl' (not in > DISTRO_FEATURES) > ERROR: Required build target 'gcr' has no buildable providers. > Missing or unbuildable dependency chain was: ['gcr', 'gtk4'] > > Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > --- > meta/recipes-gnome/gcr/gcr_4.0.0.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-gnome/gcr/gcr_4.0.0.bb b/meta/recipes-gnome/gcr/ > gcr_4.0.0.bb > index 264069ffd1..22edd386fc 100644 > --- a/meta/recipes-gnome/gcr/gcr_4.0.0.bb > +++ b/meta/recipes-gnome/gcr/gcr_4.0.0.bb > @@ -20,6 +20,8 @@ GTKDOC_MESON_OPTION = "gtk_doc" > inherit gnomebase gtk-icon-cache gi-docgen features_check > upstream-version-is-even vala gobject-introspection gettext mime mime-xdg > UPSTREAM_CHECK_REGEX = "gcr-(?P<pver>\d+\.(\d*[02468])+(\.\d+)+)\.tar.xz" > > +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', > 'x11', 'opengl', '', d)}" > + > SRC_URI += > "file://0001-meson.build-correctly-handle-disabled-ssh_agent-opti.patch" > SRC_URI[archive.sha256sum] = > "c45855924f0ee7bab43e2dd38bfafd2ac815c6e9864341c0161e171173dcec7c" > > -- > 2.25.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#174976): > https://lists.openembedded.org/g/openembedded-core/message/174976 > Mute This Topic: https://lists.openembedded.org/mt/95842308/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Hi Alex, Yes, The setting REQUIRED_DISTRO_FEATURES = "opengl" is in gtk4 recipe. Apart from that, gtk4 depends on libepoxy which also needs opengl distro. Thanks,
But does this mean we now have to insert required distro features statement into everything that depends on gtk4? That doesn’t seem useful; it should be enough to say that only in the recipe where the requirement originates. Alex On Thu 5. Jan 2023 at 3.10, Yu, Mingli <Mingli.Yu@windriver.com> wrote: > Hi Alex, > > Yes, The setting REQUIRED_DISTRO_FEATURES = "opengl" is in gtk4 recipe. > Apart from that, gtk4 depends on libepoxy which also needs opengl distro. > > Thanks, > ------------------------------ > *From:* Alexander Kanavin <alex.kanavin@gmail.com> > *Sent:* Friday, December 23, 2022 17:43 > *To:* Yu, Mingli <Mingli.Yu@windriver.com> > *Cc:* openembedded-core@lists.openembedded.org < > openembedded-core@lists.openembedded.org> > *Subject:* Re: [OE-core] [PATCH] gcr: add opengl to > REQUIRED_DISTRO_FEATURES > > * CAUTION: This email comes from a non Wind River email account!* > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > Is OpenGL really mandatory for gtk4? > > Alex > > On Fri 23. Dec 2022 at 10.32, Yu, Mingli <mingli.yu@eng.windriver.com> > wrote: > > From: Mingli Yu <mingli.yu@windriver.com> > > Fixes: > $ bitbake gcr > ERROR: Nothing PROVIDES 'gtk4' (but > /build/layers/oe-core/meta/recipes-gnome/gcr/gcr_4.0.0.bb > <https://urldefense.com/v3/__http://gcr_4.0.0.bb__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgAucUmL4$> > DEPENDS on or otherwise requires it) > gtk4 was skipped: missing required distro feature 'opengl' (not in > DISTRO_FEATURES) > ERROR: Required build target 'gcr' has no buildable providers. > Missing or unbuildable dependency chain was: ['gcr', 'gtk4'] > > Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > --- > meta/recipes-gnome/gcr/gcr_4.0.0.bb > <https://urldefense.com/v3/__http://gcr_4.0.0.bb__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgAucUmL4$> > | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-gnome/gcr/gcr_4.0.0.bb > <https://urldefense.com/v3/__http://gcr_4.0.0.bb__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgAucUmL4$> > b/meta/recipes-gnome/gcr/gcr_4.0.0.bb > <https://urldefense.com/v3/__http://gcr_4.0.0.bb__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgAucUmL4$> > index 264069ffd1..22edd386fc 100644 > --- a/meta/recipes-gnome/gcr/gcr_4.0.0.bb > <https://urldefense.com/v3/__http://gcr_4.0.0.bb__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgAucUmL4$> > +++ b/meta/recipes-gnome/gcr/gcr_4.0.0.bb > <https://urldefense.com/v3/__http://gcr_4.0.0.bb__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgAucUmL4$> > @@ -20,6 +20,8 @@ GTKDOC_MESON_OPTION = "gtk_doc" > inherit gnomebase gtk-icon-cache gi-docgen features_check > upstream-version-is-even vala gobject-introspection gettext mime mime-xdg > UPSTREAM_CHECK_REGEX = "gcr-(?P<pver>\d+\.(\d*[02468])+(\.\d+)+)\.tar.xz" > > +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', > 'x11', 'opengl', '', d)}" > + > SRC_URI += > "file://0001-meson.build-correctly-handle-disabled-ssh_agent-opti.patch" > SRC_URI[archive.sha256sum] = > "c45855924f0ee7bab43e2dd38bfafd2ac815c6e9864341c0161e171173dcec7c" > > -- > 2.25.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#174976): > https://lists.openembedded.org/g/openembedded-core/message/174976 > <https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/message/174976__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgJaHBHwR$> > Mute This Topic: https://lists.openembedded.org/mt/95842308/1686489 > <https://urldefense.com/v3/__https://lists.openembedded.org/mt/95842308/1686489__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgFA08ADx$> > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub > <https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/unsub__;!!AjveYdw8EvQ!aAHHBL_XF2Kj8Qx6nJlx-VEmLcYaA6O2xpfAAnzq3_mgKI4R6JBzXRulca1gkiY5Et5Kwi6bPycXwXHb4CuXgMLu9URo$> > [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Hi Alex, The gtk4 depends on libepoxy [1] which needs opengl DISTRO_FEATURES and it makes gtk4 require opengl DISTRO_FEATURES too. And it also introduces the opengl DISTRO_FEATURES requirements for other recipes which depend on gtk4, please help to check. [1] https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/libepoxy/libepoxy_1.5.10.bb Thanks,
I understand where it comes from, and that's not what I'm trying to express. Why do we need to insert those REQUIRED_DISTRO_FEATURES lines into every recipe that, directly, or indirectly depends on an opengl implementation, even when the component itself uses nothing from the opengl stack? With gtk4 becoming one of those items, this really does become a maintenance burden. What would happen if we instead drop them all, and keep REQUIRED_DISTRO_FEATURES only in the opengl provider itself, which would be mesa? Alex On Fri, 6 Jan 2023 at 10:11, Yu, Mingli <Mingli.Yu@windriver.com> wrote: > > Hi Alex, > > The gtk4 depends on libepoxy [1] which needs opengl DISTRO_FEATURES and it makes gtk4 require opengl DISTRO_FEATURES too. And it also introduces the opengl DISTRO_FEATURES requirements for other recipes which depend on gtk4, please help to check. > > > [1] https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/libepoxy/libepoxy_1.5.10.bb > > Thanks, > ________________________________ > From: Alexander Kanavin <alex.kanavin@gmail.com> > Sent: Thursday, January 5, 2023 14:55 > To: Yu, Mingli <Mingli.Yu@windriver.com> > Cc: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> > Subject: Re: [OE-core] [PATCH] gcr: add opengl to REQUIRED_DISTRO_FEATURES > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and know the content is safe. > But does this mean we now have to insert required distro features statement into everything that depends on gtk4? That doesn’t seem useful; it should be enough to say that only in the recipe where the requirement originates. > > Alex > > On Thu 5. Jan 2023 at 3.10, Yu, Mingli <Mingli.Yu@windriver.com> wrote: > > Hi Alex, > > Yes, The setting REQUIRED_DISTRO_FEATURES = "opengl" is in gtk4 recipe. Apart from that, gtk4 depends on libepoxy which also needs opengl distro. > > Thanks, > ________________________________ > From: Alexander Kanavin <alex.kanavin@gmail.com> > Sent: Friday, December 23, 2022 17:43 > To: Yu, Mingli <Mingli.Yu@windriver.com> > Cc: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> > Subject: Re: [OE-core] [PATCH] gcr: add opengl to REQUIRED_DISTRO_FEATURES > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and know the content is safe. > Is OpenGL really mandatory for gtk4? > > Alex > > On Fri 23. Dec 2022 at 10.32, Yu, Mingli <mingli.yu@eng.windriver.com> wrote: > > From: Mingli Yu <mingli.yu@windriver.com> > > Fixes: > $ bitbake gcr > ERROR: Nothing PROVIDES 'gtk4' (but /build/layers/oe-core/meta/recipes-gnome/gcr/gcr_4.0.0.bb DEPENDS on or otherwise requires it) > gtk4 was skipped: missing required distro feature 'opengl' (not in DISTRO_FEATURES) > ERROR: Required build target 'gcr' has no buildable providers. > Missing or unbuildable dependency chain was: ['gcr', 'gtk4'] > > Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > --- > meta/recipes-gnome/gcr/gcr_4.0.0.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-gnome/gcr/gcr_4.0.0.bb b/meta/recipes-gnome/gcr/gcr_4.0.0.bb > index 264069ffd1..22edd386fc 100644 > --- a/meta/recipes-gnome/gcr/gcr_4.0.0.bb > +++ b/meta/recipes-gnome/gcr/gcr_4.0.0.bb > @@ -20,6 +20,8 @@ GTKDOC_MESON_OPTION = "gtk_doc" > inherit gnomebase gtk-icon-cache gi-docgen features_check upstream-version-is-even vala gobject-introspection gettext mime mime-xdg > UPSTREAM_CHECK_REGEX = "gcr-(?P<pver>\d+\.(\d*[02468])+(\.\d+)+)\.tar.xz" > > +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'opengl', '', d)}" > + > SRC_URI += "file://0001-meson.build-correctly-handle-disabled-ssh_agent-opti.patch" > SRC_URI[archive.sha256sum] = "c45855924f0ee7bab43e2dd38bfafd2ac815c6e9864341c0161e171173dcec7c" > > -- > 2.25.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#174976): https://lists.openembedded.org/g/openembedded-core/message/174976 > Mute This Topic: https://lists.openembedded.org/mt/95842308/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Fri, 2023-01-06 at 10:19 +0100, Alexander Kanavin wrote: > I understand where it comes from, and that's not what I'm trying to > express. Why do we need to insert those REQUIRED_DISTRO_FEATURES lines > into every recipe that, directly, or indirectly depends on an opengl > implementation, even when the component itself uses nothing from the > opengl stack? > > With gtk4 becoming one of those items, this really does become a > maintenance burden. > > What would happen if we instead drop them all, and keep > REQUIRED_DISTRO_FEATURES only in the opengl provider itself, which > would be mesa? There is a bitbake 'limitation' where these things don't automatically flow through dependency chains. The net result of that is that if you just do this in mesa, "bitbake world" would show errors that XXX can't find dependency mesa or opengl. The first thought is, 'lets just make bitbake flow them' however the trouble is bitbake can't know when this is appropriate and when it is not. For example, imagine the dependency is "virtual/libc" and somehow you break the providers of it, i.e. break the glibc recipe. All of a sudden "bitbake world" would return success even though it built nothing since anything depending on virtual/libc was magically removed (which is nearly everything at some point). The conclusion I came too last time I thought about this was they we really did want to mark up the cases where things have a specific requirement, even if at times that is painful. Cheers, Richard
On Fri, Jan 6, 2023 at 11:36 AM Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > For example, imagine the dependency is "virtual/libc" and somehow you > break the providers of it, i.e. break the glibc recipe. All of a sudden > "bitbake world" would return success even though it built nothing since > anything depending on virtual/libc was magically removed (which is > nearly everything at some point). > > The conclusion I came too last time I thought about this was they we > really did want to mark up the cases where things have a specific > requirement, even if at times that is painful. > FWIW: here is the earlier (2014) discussion about this: https://lore.kernel.org/all/1414675717.7649.56.camel@ted/
On Fri, 6 Jan 2023 at 11:47, Martin Jansa <martin.jansa@gmail.com> wrote: >> For example, imagine the dependency is "virtual/libc" and somehow you >> break the providers of it, i.e. break the glibc recipe. All of a sudden >> "bitbake world" would return success even though it built nothing since >> anything depending on virtual/libc was magically removed (which is >> nearly everything at some point). >> >> The conclusion I came too last time I thought about this was they we >> really did want to mark up the cases where things have a specific >> requirement, even if at times that is painful. > > > FWIW: here is the earlier (2014) discussion about this: > https://lore.kernel.org/all/1414675717.7649.56.camel@ted/ Then there's a more specific question: should we treat opengl as an optional distro feature at all? We don't treat 'posix api' as a distro feature, even though theoretically we could, and in 2023 opengl is pretty much on the same level. What is being gained by ability to block it out on the distro level? Alex
On Fri, 2023-01-06 at 11:58 +0100, Alexander Kanavin wrote: > On Fri, 6 Jan 2023 at 11:47, Martin Jansa <martin.jansa@gmail.com> wrote: > > > For example, imagine the dependency is "virtual/libc" and somehow you > > > break the providers of it, i.e. break the glibc recipe. All of a sudden > > > "bitbake world" would return success even though it built nothing since > > > anything depending on virtual/libc was magically removed (which is > > > nearly everything at some point). > > > > > > The conclusion I came too last time I thought about this was they we > > > really did want to mark up the cases where things have a specific > > > requirement, even if at times that is painful. > > > > > > FWIW: here is the earlier (2014) discussion about this: > > https://lore.kernel.org/all/1414675717.7649.56.camel@ted/ > > Then there's a more specific question: should we treat opengl as an > optional distro feature at all? > > We don't treat 'posix api' as a distro feature, even though > theoretically we could, and in 2023 opengl is pretty much on the same > level. What is being gained by ability to block it out on the distro > level? Most hardware is capable of running posix apis however there is a large subset of hardware without displays that doesn't care about opengl. There is also hardware with simple graphics that doesn't support GL, or doesn't support it without horrible binary only stuff. We there aren't going to make opengl mandatory any time soon. Cheers, Richard
diff --git a/meta/recipes-gnome/gcr/gcr_4.0.0.bb b/meta/recipes-gnome/gcr/gcr_4.0.0.bb index 264069ffd1..22edd386fc 100644 --- a/meta/recipes-gnome/gcr/gcr_4.0.0.bb +++ b/meta/recipes-gnome/gcr/gcr_4.0.0.bb @@ -20,6 +20,8 @@ GTKDOC_MESON_OPTION = "gtk_doc" inherit gnomebase gtk-icon-cache gi-docgen features_check upstream-version-is-even vala gobject-introspection gettext mime mime-xdg UPSTREAM_CHECK_REGEX = "gcr-(?P<pver>\d+\.(\d*[02468])+(\.\d+)+)\.tar.xz" +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'opengl', '', d)}" + SRC_URI += "file://0001-meson.build-correctly-handle-disabled-ssh_agent-opti.patch" SRC_URI[archive.sha256sum] = "c45855924f0ee7bab43e2dd38bfafd2ac815c6e9864341c0161e171173dcec7c"