Add opengl to REQUIRED_DISTRO_FEATURES for some recipes
cover Add opengl to REQUIRED_DISTRO_FEATURES for some recipes
From: Christopher Larson <[email protected]>
These aren't buildable without it, and adding it fixes oe-core world builds with nodistro (which does not have the opengl feature by default).
The following changes since commit 425afe2484707640ac71194885fdb263e95e9950:
lib/oe/utils: Drop python2 compatibility code (2016-12-22 08:50:21 +0000)
are available in the git repository at:
git://github.com/kergoth/openembedded-core without-opengl-fixes
https://github.com/kergoth/openembedded-core/tree/without-opengl-fixes
Christopher Larson (6):
waffle: add opengl to REQUIRED_DISTRO_FEATURES
piglit: add opengl to REQUIRED_DISTRO_FEATURES
libglu: add opengl to REQUIRED_DISTRO_FEATURES
eglinfo-x11: add opengl to REQUIRED_DISTRO_FEATURES
packagegroup-self-hosted: add opengl to REQUIRED_DISTRO_FEATURES
packagegroup-core-lsb: add opengl to REQUIRED_DISTRO_FEATURES
meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 3 +++ meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb | 3 +++ meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.0.bb | 3 ++- meta/recipes-graphics/mesa/libglu_9.0.0.bb | 2 +- meta/recipes-graphics/piglit/piglit_git.bb | 3 +++ meta/recipes-graphics/waffle/waffle_1.5.2.bb | 3 +++ 6 files changed, 15 insertions(+), 2 deletions(-)
Signature · 1 line
2.8.0
PATCH 1/6 waffle: add opengl to REQUIRED_DISTRO_FEATURES
From: Christopher Larson <[email protected]>
Multiple packageconfigs depend upon virtual/libgl, whose providers require the opengl distro feature.
--- meta/recipes-graphics/waffle/waffle_1.5.2.bb | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-graphics/waffle/waffle_1.5.2.bb +3 -0
@@ -20,6 +20,9 @@ PACKAGECONFIG ??= "glx" # libx11 requires x11 in DISTRO_FEATURES. REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG', 'glx', 'x11', '', d)}" +# virtual/libgl requires opengl in DISTRO_FEATURES. +REQUIRED_DISTRO_FEATURES += "${@bb.utils.contains('DEPENDS', 'virtual/libgl', 'opengl', '', d)}" + # I say virtual/libgl, actually wants gl.pc PACKAGECONFIG[glx] = "-Dwaffle_has_glx=1,-Dwaffle_has_glx=0,virtual/libgl libx11"
Signature · 1 line
2.8.0
PATCH 2/6 piglit: add opengl to REQUIRED_DISTRO_FEATURES
In reply to Christopher LarsonFrom: Christopher Larson <[email protected]>
This recipe depend on virtual/libgl, whose providers require the opengl distro feature.
--- meta/recipes-graphics/piglit/piglit_git.bb | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-graphics/piglit/piglit_git.bb +3 -0
@@ -22,6 +22,9 @@ inherit cmake python3native distro_features_check bash-completion # depends on virtual/libx11 REQUIRED_DISTRO_FEATURES = "x11" +# depends on virtual/libgl +REQUIRED_DISTRO_FEATURES += "opengl" + # The built scripts go into the temporary directory according to tempfile # (typically /tmp) which can race if multiple builds happen on the same machine, # so tell it to use a directory in ${B} to avoid overwriting.
Signature · 1 line
2.8.0
PATCH 3/6 libglu: add opengl to REQUIRED_DISTRO_FEATURES
In reply to Christopher LarsonFrom: Christopher Larson <[email protected]>
This requires libgl, and mesa requires the opengl distro feature.
--- meta/recipes-graphics/mesa/libglu_9.0.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-graphics/mesa/libglu_9.0.0.bb +1 -1
@@ -24,7 +24,7 @@ DEPENDS = "virtual/libgl" inherit autotools pkgconfig distro_features_check # Requires libGL.so which is provided by mesa when x11 in DISTRO_FEATURES -REQUIRED_DISTRO_FEATURES = "x11" +REQUIRED_DISTRO_FEATURES = "x11 opengl" # Remove the mesa-glu dependency in mesa-glu-dev, as mesa-glu is empty RDEPENDS_${PN}-dev = ""
Signature · 1 line
2.8.0
Re: [PATCH 3/6] libglu: add opengl to REQUIRED_DISTRO_FEATURES
meta/recipes-graphics/mesa/libglu_9.0.0.bb DEPENDS = "virtual/libgl" · line 27
Quoted 5 lines · Christopher Larson
# Requires libGL.so which is provided by mesa when x11 in
DISTRO_FEATURESmeta/recipes-graphics/mesa/libglu_9.0.0.bb +1
-1-REQUIRED_DISTRO_FEATURES = "x11" +REQUIRED_DISTRO_FEATURES = "x11 opengl"
I sort of have the sense that something has gone a bit wrong with the way {REQUIRED_}DISTRO_FEATURES is now being used.
The original concept with DISTRO_FEATURES was that it would just be a global way of controlling the PACKAGECONFIG options for each recipe. That is, if you have x11 in DISTRO_FEATURES then PACKAGECONFIG[x11] would be turned on automatically for every recipe that supports it, and so on. It was never really intended to be, and I still feel it probably ought not to be, a filtering mechanism.
Or, to put it another way, just because you don't have x11 in DISTRO_FEATURES doesn't necessarily mean that your distro refuses to support x11 at all. It ought simply to mean that you don't want packages compiled with X11 support where this is avoidable.
But in the particular case above, if the comment is correct then the presence of x11 in REQUIRED_DISTRO_FEATURES seems bogus by any interpretation. If it's really true that libGLU simply "Requires libGL.so" then either:
a) it ought to have nothing at all in REQUIRED_DISTRO_FEATURES and simply express a dependency on virtual/libgl (which would be my preference); or
b) it ought to mention only opengl in REQUIRED_DISTRO_FEATURES
p.
PATCH 4/6 eglinfo-x11: add opengl to REQUIRED_DISTRO_FEATURES
In reply to Christopher LarsonFrom: Christopher Larson <[email protected]>
The .inc already included this, but the x11 version was overriding it. This is a problem, as the x11 version still needs opengl as well as x11. Append instead.
--- meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.0.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.0.bb +2 -1
@@ -6,7 +6,8 @@ include eglinfo.inc DEPENDS += "virtual/libx11" inherit distro_features_check + # depends on virtual/libx11 -REQUIRED_DISTRO_FEATURES = "x11" +REQUIRED_DISTRO_FEATURES += "x11" SUMMARY += "(X11 version)"
Signature · 1 line
2.8.0
PATCH 5/6 packagegroup-self-hosted: add opengl to REQUIRED_DISTRO_FEATURES
In reply to Christopher LarsonFrom: Christopher Larson <[email protected]>
This rdepends on libgl.
--- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +3 -0
@@ -10,6 +10,9 @@ inherit packagegroup distro_features_check # rdepends on libx11-dev REQUIRED_DISTRO_FEATURES = "x11" +# rdepends on libgl +REQUIRED_DISTRO_FEATURES += "opengl" + PACKAGES = "\ packagegroup-self-hosted \ packagegroup-self-hosted-debug \
Signature · 1 line
2.8.0
PATCH 6/6 packagegroup-core-lsb: add opengl to REQUIRED_DISTRO_FEATURES
In reply to Christopher LarsonFrom: Christopher Larson <[email protected]>
This group pulls in libglu, which needs virtual/libgl, whose providers require opengl in DISTRO_FEATURES.
--- meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +3 -0
@@ -11,6 +11,9 @@ inherit packagegroup distro_features_check # The libxt, libxtst and others require x11 in DISTRO_FEATURES REQUIRED_DISTRO_FEATURES = "x11" +# libglu needs virtual/libgl, which requires opengl in DISTRO_FEATURES +REQUIRED_DISTRO_FEATURES += "opengl" + # # We will skip parsing this packagegeoup for non-glibc systems #
Signature · 1 line
2.8.0
Quoted 3 lines · Christopher Larson
These aren't buildable without it, and adding it fixes oe-core world builds with nodistro (which does not have the opengl feature by default).
Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else that depends on it is also magically skipped?
Ross
Quoted 11 lines · Ross
Quoted 4 lines · Christopher Larson
These aren't buildable without it, and adding it fixes oe-core world builds
with nodistro (which does not have the opengl feature by default).Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else that depends on it is also magically skipped?
Somewhere, we need to flag that user is shooting his own foot by skipping a given recipe.
Quoted 9 lines
Ross
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 10 lines · Ross
Quoted 4 lines · Christopher Larson
These aren't buildable without it, and adding it fixes oe-core world builds
with nodistro (which does not have the opengl feature by default).Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else that depends on it is also magically skipped?
I’d agree with that. It’d be a nice improvement. The user would see an explicit error if they try to build it, as is always the case with skipped recipes, but it’d be silently excluded from world the way skipped recipes usually are.
Signature · 4 lines
Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics
Quoted 15 lines · Christopher Larson
Quoted 11 lines · Ross
Quoted 4 lines · Christopher Larson
These aren't buildable without it, and adding it fixes oe-core world builds
with nodistro (which does not have the opengl feature by default).Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else that depends on it is also magically skipped?
Quoted 4 lines
I’d agree with that. It’d be a nice improvement. The user would see an explicit error if they try to build it, as is always the case with skipped recipes, but it’d be silently excluded from world the way skipped recipes usually are.
excluding from world builds is a fair argument.
Quoted 12 lines
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 9 lines · Ross
On 4 January 2017 at 22:57, Christopher Larson <[email protected]> wrote:
These aren't buildable without it, and adding it fixes oe-core world builds
with nodistro (which does not have the opengl feature by default).
Quoted 3 lines
Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else that depends on it is also magically skipped?
Not at all, I'd also prefer that. If recipe "foo" has some obscure conditions when it can be built, then repeating those conditions in any recipe depending on "foo" is a maintenance headache.
Last time I brought this up, it was mentioned as advantage of the current approach that conditions are explicit and thus less surprising. There's some truth to that, but I don't believe that it outweighs the disadvantages.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Quoted 21 lines · Patrick Ohly
Quoted 11 lines · Ross
On 4 January 2017 at 22:57, Christopher Larson <[email protected]> wrote:
These aren't buildable without it, and adding it fixes oe- core
world builds
with nodistro (which does not have the opengl feature by default).Quoted 4 lines
Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else
that depends on it is also magically skipped?Not at all, I'd also prefer that. If recipe "foo" has some obscure conditions when it can be built, then repeating those conditions in any
recipe depending on "foo" is a maintenance headache.
Quoted 5 lines
Last time I brought this up, it was mentioned as advantage of the current approach that conditions are explicit and thus less surprising.
There's some truth to that, but I don't believe that it outweighs the disadvantages.
Imagine for example that we accidentally add some condition which results in 50% of the recipes being skipped. "bitbake world" would pass if this auto-skipping functionality was implemented. I worry that it would make it really easy to hide some subset of completely a non- buildable recipes which we can't even easily identify other than directly trying to build each target. We added something to avoid that (the world target).
The second problem is the actual implementation of it. I've never come up with a sane way to address this problem and give errors where people would want them yet hide the cases where people really don't want to be bothered, its very hard to make it work well at the bitbake level and the code is already complex/fragile enough.
Considering this, marking things up explicitly has always seemed like the right thing to do ever time I've looked further into this. If someone has the time and wants to propose a solution, sure, but I think there are other more important/pressing things to do.
Cheers,
Richard
Quoted 28 lines · Richard Purdie
Quoted 21 lines · Patrick Ohly
Quoted 11 lines · Ross
On 4 January 2017 at 22:57, Christopher Larson <[email protected]> wrote:
These aren't buildable without it, and adding it fixes oe-
core
world builds
with nodistro (which does not have the opengl feature by default).Quoted 4 lines
Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else
that depends on it is also magically skipped?Not at all, I'd also prefer that. If recipe "foo" has some obscure conditions when it can be built, then repeating those conditions in any
recipe depending on "foo" is a maintenance headache.Quoted 5 lines
Last time I brought this up, it was mentioned as advantage of the current approach that conditions are explicit and thus less surprising.
There's some truth to that, but I don't believe that it outweighs the disadvantages.
Quoted 7 lines
Imagine for example that we accidentally add some condition which results in 50% of the recipes being skipped. "bitbake world" would pass if this auto-skipping functionality was implemented. I worry that it would make it really easy to hide some subset of completely a non- buildable recipes which we can't even easily identify other than directly trying to build each target. We added something to avoid that (the world target).
Shouldn't it be caught by QA when expected functionality suddenly disappears? But I guess that would only work in a perfect world; in practice, QA coverage isn't sufficient and some recipes are indeed merely in a "we know it compiles" state.
Quoted 5 lines
The second problem is the actual implementation of it. I've never come up with a sane way to address this problem and give errors where people would want them yet hide the cases where people really don't want to be bothered, its very hard to make it work well at the bitbake level and the code is already complex/fragile enough.
How about a compromise: instead of repeating some (potentially complex) checks in every recipe affected by this, could we have a "skip recipe foo if dependencies are unavailable" check?
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Quoted 10 lines · Ross
Quoted 4 lines · Christopher Larson
These aren't buildable without it, and adding it fixes oe-core world builds
with nodistro (which does not have the opengl feature by default).Am I still the only person who thinks skipping of recipes should be recursive, so if say libx11 throws a SkipRecipe then everything else that depends on it is also magically skipped?
Just to highlight the challenge here, the provider of virtual/libc raises a SkipRecipe, therefore every target recipe which isn't allarch gets skipped and "bitbake world" returns success. We have SkipRecipe code in the libcs so this isn't even that unlikely. I suspect you'd argue that is broken.
How do you tell the difference between this case which is a clear error and your case of X11 being disabled?
Cheers,
Richard