* [Buildroot] [BR2_EXTERNAL] Ability to specify regular packages behaviour from external.mk @ 2013-12-10 15:18 David Corvoysier 2013-12-10 19:07 ` [Buildroot] [PATH 0/1] Fix GLES when a provider is defined in BR2_EXTERNAL Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: David Corvoysier @ 2013-12-10 15:18 UTC (permalink / raw) To: buildroot Hi, I have been testing BR2_EXTERNAL to generate a firmware for a target that provides proprietary egl and gles implementations. I have created a custom userland package for my target that "provides" egl and gles, but I still need to specify a dependency towards it in libegl and libgles. Before BR2_EXTERNAL, I used to patch buildroot's package/opengl/libgles.mk and package/opengl/libegl.mk directly: ifeq ($(BR2_PACKAGE_XX_USERLAND),y) LIBGLES_DEPENDENCIES += xx-userland endif Now, I would like to add these lines to my external.mk, but I fail on a LIBXX_CONFIGURE_CMDS that exits on error if LIBGLES_DEPENDENCIES are empty. The thing is that since external.mk is included after all other makefiles, my modifications to LIBXX_DEPENDENCIES are applied only after the creation of the LIBXX_CONFIGURE_CMDS, thus causing the exit on error. I managed to overcome this issue by moving the inclusion of external.mk before all other makefiles, but I have no idea if this is the right way to go: what do you think ? David Corvoysier ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATH 0/1] Fix GLES when a provider is defined in BR2_EXTERNAL 2013-12-10 15:18 [Buildroot] [BR2_EXTERNAL] Ability to specify regular packages behaviour from external.mk David Corvoysier @ 2013-12-10 19:07 ` Yann E. MORIN 2013-12-10 19:07 ` [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2013-12-10 19:07 UTC (permalink / raw) To: buildroot David, All, > I have been testing BR2_EXTERNAL to generate a firmware for a target that > provides proprietary egl and gles implementations. Doh, that's a case we did not foresee. :-( > I have created a custom userland package for my target that "provides" egl and > gles, but I still need to specify a dependency towards it in libegl and > libgles. > > Before BR2_EXTERNAL, I used to patch buildroot's package/opengl/libgles.mk and > package/opengl/libegl.mk directly: > > ifeq ($(BR2_PACKAGE_XX_USERLAND),y) > LIBGLES_DEPENDENCIES += xx-userland > endif > > Now, I would like to add these lines to my external.mk, but I fail on a > LIBXX_CONFIGURE_CMDS that exits on error if LIBGLES_DEPENDENCIES are empty. > > The thing is that since external.mk is included after all other makefiles, my > modifications to LIBXX_DEPENDENCIES are applied only after the creation of the > LIBXX_CONFIGURE_CMDS, thus causing the exit on error. > > I managed to overcome this issue by moving the inclusion of external.mk before > all other makefiles, but I have no idea if this is the right way to go: what > do you think ? I don't know what the actual solution will be, but I've done a quick-and-dirty and completely untested patch that postpones the check until runtime (as a follow-up): [PATCH] package/libgles: postpone the check for a missing GLES That patch does not change package/opengl/libegl and others, so you'll have to do it on your side if needed. Can you check this works for you? If not, we'll have to find another solution. (not this one is final, either). Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-10 19:07 ` [Buildroot] [PATH 0/1] Fix GLES when a provider is defined in BR2_EXTERNAL Yann E. MORIN @ 2013-12-10 19:07 ` Yann E. MORIN 2013-12-11 10:46 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2013-12-10 19:07 UTC (permalink / raw) To: buildroot From: "Yann E. MORIN" <yann.morin.1998@free.fr> Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) might be empty hwen we test it. So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must postpone the check until later, ie. at runtime. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- package/opengl/libgles/libgles.mk | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/package/opengl/libgles/libgles.mk b/package/opengl/libgles/libgles.mk index ec157ac..c2e1acf 100644 --- a/package/opengl/libgles/libgles.mk +++ b/package/opengl/libgles/libgles.mk @@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y) LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q endif -ifeq ($(LIBGLES_DEPENDENCIES),) +# Because some GLES providers may be in BR2_EXTERNAL, +# $(LIBGLES_DEPENDENCIES) might be empty right here. +# So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS +# right now, and we must postpone the check until later, +# ie. at runtime. define LIBGLES_CONFIGURE_CMDS - echo "No libGLES implementation selected. Configuration error." - exit 1 + if [ -z "$${LIBGLES_DEPENDENCIES}" ]; then \ + echo "No libGLES implementation selected. Configuration error."; \ + exit 1; \ + fi endef -endif $(eval $(generic-package)) -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-10 19:07 ` [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider Yann E. MORIN @ 2013-12-11 10:46 ` Arnout Vandecappelle 2013-12-11 12:25 ` Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2013-12-11 10:46 UTC (permalink / raw) To: buildroot On 10/12/13 20:07, Yann E. MORIN wrote: > From: "Yann E. MORIN" <yann.morin.1998@free.fr> > > Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) > might be empty hwen we test it. > > So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must > postpone the check until later, ie. at runtime. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > --- > package/opengl/libgles/libgles.mk | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/package/opengl/libgles/libgles.mk b/package/opengl/libgles/libgles.mk > index ec157ac..c2e1acf 100644 > --- a/package/opengl/libgles/libgles.mk > +++ b/package/opengl/libgles/libgles.mk > @@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y) > LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q > endif > > -ifeq ($(LIBGLES_DEPENDENCIES),) > +# Because some GLES providers may be in BR2_EXTERNAL, > +# $(LIBGLES_DEPENDENCIES) might be empty right here. > +# So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS > +# right now, and we must postpone the check until later, > +# ie. at runtime. > define LIBGLES_CONFIGURE_CMDS > - echo "No libGLES implementation selected. Configuration error." > - exit 1 > + if [ -z "$${LIBGLES_DEPENDENCIES}" ]; then \ This should be "$(LIBGLES_DEPENDENCIES)", but otherwise it looks like it would work. Regards, Arnout > + echo "No libGLES implementation selected. Configuration error."; \ > + exit 1; \ > + fi > endef > -endif > > $(eval $(generic-package)) > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-11 10:46 ` Arnout Vandecappelle @ 2013-12-11 12:25 ` Yann E. MORIN 2013-12-11 13:03 ` David Corvoysier 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2013-12-11 12:25 UTC (permalink / raw) To: buildroot Arnout, All, On Wednesday 11 December 2013 11:46:59 Arnout Vandecappelle wrote: > On 10/12/13 20:07, Yann E. MORIN wrote: > > From: "Yann E. MORIN" <yann.morin.1998@free.fr> > > > > Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) > > might be empty hwen we test it. > > > > So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must > > postpone the check until later, ie. at runtime. > > > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > > --- > > package/opengl/libgles/libgles.mk | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/package/opengl/libgles/libgles.mk b/package/opengl/libgles/libgles.mk > > index ec157ac..c2e1acf 100644 > > --- a/package/opengl/libgles/libgles.mk > > +++ b/package/opengl/libgles/libgles.mk > > @@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y) > > LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q > > endif > > > > -ifeq ($(LIBGLES_DEPENDENCIES),) > > +# Because some GLES providers may be in BR2_EXTERNAL, > > +# $(LIBGLES_DEPENDENCIES) might be empty right here. > > +# So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS > > +# right now, and we must postpone the check until later, > > +# ie. at runtime. > > define LIBGLES_CONFIGURE_CMDS > > - echo "No libGLES implementation selected. Configuration error." > > - exit 1 > > + if [ -z "$${LIBGLES_DEPENDENCIES}" ]; then \ > > This should be "$(LIBGLES_DEPENDENCIES)", but otherwise it looks like > it would work. I was afraid using a make variable here would be expanded too early again, that's why I postponed its expansion into the shell command itself. But it does not work either, since the variable is not exported. I'm waiting for feedback from David to confirm either or both solutions work... Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. | '------------------------------'-------'------------------'--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-11 12:25 ` Yann E. MORIN @ 2013-12-11 13:03 ` David Corvoysier 2013-12-11 14:05 ` David Corvoysier 0 siblings, 1 reply; 18+ messages in thread From: David Corvoysier @ 2013-12-11 13:03 UTC (permalink / raw) To: buildroot Guys, The first solution did not work (as yann pointed out, the variable is not exported), but the second does. Who's in for a patch (me ?) David Le 11/12/2013 13:25, Yann E. MORIN a ?crit : > Arnout, All, > > On Wednesday 11 December 2013 11:46:59 Arnout Vandecappelle wrote: >> On 10/12/13 20:07, Yann E. MORIN wrote: >>> From: "Yann E. MORIN" <yann.morin.1998@free.fr> >>> >>> Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) >>> might be empty hwen we test it. >>> >>> So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must >>> postpone the check until later, ie. at runtime. >>> >>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> >>> --- >>> package/opengl/libgles/libgles.mk | 13 +++++++++---- >>> 1 file changed, 9 insertions(+), 4 deletions(-) >>> >>> diff --git a/package/opengl/libgles/libgles.mk b/package/opengl/libgles/libgles.mk >>> index ec157ac..c2e1acf 100644 >>> --- a/package/opengl/libgles/libgles.mk >>> +++ b/package/opengl/libgles/libgles.mk >>> @@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y) >>> LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q >>> endif >>> >>> -ifeq ($(LIBGLES_DEPENDENCIES),) >>> +# Because some GLES providers may be in BR2_EXTERNAL, >>> +# $(LIBGLES_DEPENDENCIES) might be empty right here. >>> +# So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS >>> +# right now, and we must postpone the check until later, >>> +# ie. at runtime. >>> define LIBGLES_CONFIGURE_CMDS >>> - echo "No libGLES implementation selected. Configuration error." >>> - exit 1 >>> + if [ -z "$${LIBGLES_DEPENDENCIES}" ]; then \ >> This should be "$(LIBGLES_DEPENDENCIES)", but otherwise it looks like >> it would work. > I was afraid using a make variable here would be expanded too early > again, that's why I postponed its expansion into the shell command > itself. > > But it does not work either, since the variable is not exported. > > I'm waiting for feedback from David to confirm either or both > solutions work... > > Regards, > Yann E. MORIN. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-11 13:03 ` David Corvoysier @ 2013-12-11 14:05 ` David Corvoysier 2013-12-12 22:00 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: David Corvoysier @ 2013-12-11 14:05 UTC (permalink / raw) To: buildroot Sorry, I did another try from a clean environment and the second solution didn't work either: LIBGLES_DEPENDENCIES has the right (modified) value when it the LIBGLES_CONFIGURE_CMDS is evaluated, but not when the dependencies themselves are evaluated (I think it happens in pkg-generic.mk). So, the build doesn't fail on the LIBGLES_CONFIGURE_CMDS test, but if the xx_userland package has not been installed beforehand, it is not installed automatically when libgles is built. David Le 11/12/2013 14:03, David Corvoysier a ?crit : > Guys, > > The first solution did not work (as yann pointed out, the variable is > not exported), but the second does. > Who's in for a patch (me ?) > > David > ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-11 14:05 ` David Corvoysier @ 2013-12-12 22:00 ` Arnout Vandecappelle 2013-12-12 22:13 ` Thomas Petazzoni 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2013-12-12 22:00 UTC (permalink / raw) To: buildroot On 11/12/13 15:05, David Corvoysier wrote: > Sorry, I did another try from a clean environment and the second solution > didn't work either: LIBGLES_DEPENDENCIES has the right (modified) value > when it the LIBGLES_CONFIGURE_CMDS is evaluated, but not when the > dependencies themselves are evaluated (I think it happens in > pkg-generic.mk). Yes that's right. In this case, there's no workaround AFAICS... Thomas, do you remember what was the reason to include external.mk after package/*/*.mk rather than before? If there is no specific reason for it, we could move it. I also feel that the way the opengl stuff is handled now is a bit hacky, but I don't have any better ideas. Regards, Arnout > So, the build doesn't fail on the LIBGLES_CONFIGURE_CMDS test, but if the > xx_userland package has not been installed beforehand, it is not > installed automatically when libgles is built. > > David > > Le 11/12/2013 14:03, David Corvoysier a ?crit : >> Guys, >> >> The first solution did not work (as yann pointed out, the variable is >> not exported), but the second does. >> Who's in for a patch (me ?) >> >> David >> > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot > > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-12 22:00 ` Arnout Vandecappelle @ 2013-12-12 22:13 ` Thomas Petazzoni 2013-12-12 23:08 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: Thomas Petazzoni @ 2013-12-12 22:13 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Thu, 12 Dec 2013 23:00:18 +0100, Arnout Vandecappelle wrote: > Thomas, do you remember what was the reason to include external.mk > after package/*/*.mk rather than before? If there is no specific reason > for it, we could move it. No, I don't see a particular reason. It was merely based on the idea that BR2_EXTERNAL "adds" more packages to the set of packages provided by Buildroot, so it felt logical to include the BR2_EXTERNAL stuff *after* the BR packages. But I don't see anything that prevents the BR2_EXTERNAL stuff from being moved before the Buildroot packages inclusions. And Yann has already submitted a patch that does this. > I also feel that the way the opengl stuff is handled now is a bit > hacky, but I don't have any better ideas. Huh? Can you be more specific in what you find hacky? The way the OpenGL stuff is handled today is kind of becoming the norm to handle virtual packages, so it'd be good to understand what you think is hacky in this implementation. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-12 22:13 ` Thomas Petazzoni @ 2013-12-12 23:08 ` Arnout Vandecappelle 2013-12-17 6:11 ` Thomas Petazzoni 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2013-12-12 23:08 UTC (permalink / raw) To: buildroot On 12/12/13 23:13, Thomas Petazzoni wrote: >> > I also feel that the way the opengl stuff is handled now is a bit >> >hacky, but I don't have any better ideas. > Huh? Can you be more specific in what you find hacky? The way the > OpenGL stuff is handled today is kind of becoming the norm to handle > virtual packages, so it'd be good to understand what you think is hacky > in this implementation. It's hacky because you have double binding between opengl/libgles and the gles suppliers: opengl/libgles/libgles.mk enumerates all possible suppliers, and the suppliers select BR2_PACKAGE_HAS_OPENGL_ES. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-12 23:08 ` Arnout Vandecappelle @ 2013-12-17 6:11 ` Thomas Petazzoni 2013-12-17 7:58 ` Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Thomas Petazzoni @ 2013-12-17 6:11 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Fri, 13 Dec 2013 00:08:46 +0100, Arnout Vandecappelle wrote: > > Huh? Can you be more specific in what you find hacky? The way the > > OpenGL stuff is handled today is kind of becoming the norm to handle > > virtual packages, so it'd be good to understand what you think is > > hacky in this implementation. > > It's hacky because you have double binding between opengl/libgles > and the gles suppliers: opengl/libgles/libgles.mk enumerates all > possible suppliers, and the suppliers select > BR2_PACKAGE_HAS_OPENGL_ES. Ok, I understand. Even though I don't think it's really a major issue, I believe there are two possible directions to fix this: 1. Since the .mk part is centralized in opengl/libgles, but the Config.in is not (spread in each OpenGL implementation doing the select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL as something like: config BR2_PACKAGE_HAS_OPENGL_ES bool default y if BR2_PACKAGE_RPI_FIRMWARE default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION default y if BR2_PACKAGE_... 2. Or, we can take the opposite route by pushing the currently centralized libgles.mk logic that adds each OpenGL implementation in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk file. But that requires a late evaluation of $(generic-package), so that all OpenGL implementations can be registered in LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk is evaluated. This would require something like Yann's patch. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-17 6:11 ` Thomas Petazzoni @ 2013-12-17 7:58 ` Yann E. MORIN 2013-12-17 9:04 ` Thomas Petazzoni 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2013-12-17 7:58 UTC (permalink / raw) To: buildroot Thomas, All, On Tuesday 17 December 2013 07:11:00 Thomas Petazzoni wrote: > On Fri, 13 Dec 2013 00:08:46 +0100, Arnout Vandecappelle wrote: > > > Huh? Can you be more specific in what you find hacky? The way the > > > OpenGL stuff is handled today is kind of becoming the norm to handle > > > virtual packages, so it'd be good to understand what you think is > > > hacky in this implementation. > > > > It's hacky because you have double binding between opengl/libgles > > and the gles suppliers: opengl/libgles/libgles.mk enumerates all > > possible suppliers, and the suppliers select > > BR2_PACKAGE_HAS_OPENGL_ES. > > Ok, I understand. Even though I don't think it's really a major issue, I > believe there are two possible directions to fix this: > > 1. Since the .mk part is centralized in opengl/libgles, but the > Config.in is not (spread in each OpenGL implementation doing the > select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the Config.in > logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" in each > OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL as > something like: > > config BR2_PACKAGE_HAS_OPENGL_ES > bool > default y if BR2_PACKAGE_RPI_FIRMWARE > default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION > default y if BR2_PACKAGE_... With this first proposal, it becomes a bit more complex to implement providers in BR2_EXTERNAL. > 2. Or, we can take the opposite route by pushing the currently > centralized libgles.mk logic that adds each OpenGL implementation > in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk > file. But that requires a late evaluation of $(generic-package), so > that all OpenGL implementations can be registered in > LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk > is evaluated. This would require something like Yann's patch. Needless to say I would highly prefer this second solution. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. | '------------------------------'-------'------------------'--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-17 7:58 ` Yann E. MORIN @ 2013-12-17 9:04 ` Thomas Petazzoni 2013-12-17 22:07 ` Yann E. MORIN 2013-12-17 22:20 ` Arnout Vandecappelle 0 siblings, 2 replies; 18+ messages in thread From: Thomas Petazzoni @ 2013-12-17 9:04 UTC (permalink / raw) To: buildroot Dear Yann E. MORIN, On Tue, 17 Dec 2013 08:58:13 +0100, Yann E. MORIN wrote: > > 1. Since the .mk part is centralized in opengl/libgles, but the > > Config.in is not (spread in each OpenGL implementation doing the > > select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the > > Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" > > in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL > > as something like: > > > > config BR2_PACKAGE_HAS_OPENGL_ES > > bool > > default y if BR2_PACKAGE_RPI_FIRMWARE > > default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION > > default y if BR2_PACKAGE_... > > With this first proposal, it becomes a bit more complex to > implement providers in BR2_EXTERNAL. Ah, true. > > 2. Or, we can take the opposite route by pushing the currently > > centralized libgles.mk logic that adds each OpenGL > > implementation in LIBGLES_DEPENDENCIES down into each OpenGL > > implementation .mk file. But that requires a late evaluation of > > $(generic-package), so that all OpenGL implementations can be > > registered in LIBGLES_DEPENDENCIES before the generic-package macro > > of libgles.mk is evaluated. This would require something like > > Yann's patch. > > Needless to say I would highly prefer this second solution. Right. In principle, I have nothing against this solution. It's just that I am not sure to fully grasp the consequences of the change you're proposing. I'm a bit worried about "weird" consequences that we may not be thinking of at this time. But maybe we should simply apply the patch, and see if it causes problems for some specific use cases. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-17 9:04 ` Thomas Petazzoni @ 2013-12-17 22:07 ` Yann E. MORIN 2013-12-17 22:20 ` Arnout Vandecappelle 1 sibling, 0 replies; 18+ messages in thread From: Yann E. MORIN @ 2013-12-17 22:07 UTC (permalink / raw) To: buildroot Thomas, All, On 2013-12-17 10:04 +0100, Thomas Petazzoni spake thusly: > On Tue, 17 Dec 2013 08:58:13 +0100, Yann E. MORIN wrote: [--SNIP--] > > > 2. Or, we can take the opposite route by pushing the currently > > > centralized libgles.mk logic that adds each OpenGL > > > implementation in LIBGLES_DEPENDENCIES down into each OpenGL > > > implementation .mk file. But that requires a late evaluation of > > > $(generic-package), so that all OpenGL implementations can be > > > registered in LIBGLES_DEPENDENCIES before the generic-package macro > > > of libgles.mk is evaluated. This would require something like > > > Yann's patch. > > > > Needless to say I would highly prefer this second solution. > > Right. In principle, I have nothing against this solution. It's just > that I am not sure to fully grasp the consequences of the change you're > proposing. I'm a bit worried about "weird" consequences that we may not > be thinking of at this time. But maybe we should simply apply the > patch, and see if it causes problems for some specific use cases. OK, so we should apply it soon, since the holidays season is approaching pretty fast now, and it would be nive to be able to react quickly in case anything goes south... Peter, care to have a look at it and comment (or apply it), please? ;-) http://patchwork.ozlabs.org/patch/301874/ Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-17 9:04 ` Thomas Petazzoni 2013-12-17 22:07 ` Yann E. MORIN @ 2013-12-17 22:20 ` Arnout Vandecappelle 2013-12-17 22:35 ` Yann E. MORIN 1 sibling, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2013-12-17 22:20 UTC (permalink / raw) To: buildroot On 17/12/13 10:04, Thomas Petazzoni wrote: > Dear Yann E. MORIN, > > On Tue, 17 Dec 2013 08:58:13 +0100, Yann E. MORIN wrote: > >>> 1. Since the .mk part is centralized in opengl/libgles, but the >>> Config.in is not (spread in each OpenGL implementation doing the >>> select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the >>> Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" >>> in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL >>> as something like: >>> >>> config BR2_PACKAGE_HAS_OPENGL_ES >>> bool >>> default y if BR2_PACKAGE_RPI_FIRMWARE >>> default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION >>> default y if BR2_PACKAGE_... >> >> With this first proposal, it becomes a bit more complex to >> implement providers in BR2_EXTERNAL. > > Ah, true. Also it feels inconvenient to me that the virtual package should "know" about all its providers. > >>> 2. Or, we can take the opposite route by pushing the currently >>> centralized libgles.mk logic that adds each OpenGL >>> implementation in LIBGLES_DEPENDENCIES down into each OpenGL >>> implementation .mk file. But that requires a late evaluation of >>> $(generic-package), so that all OpenGL implementations can be >>> registered in LIBGLES_DEPENDENCIES before the generic-package macro >>> of libgles.mk is evaluated. This would require something like >>> Yann's patch. >> >> Needless to say I would highly prefer this second solution. > > Right. In principle, I have nothing against this solution. It's just > that I am not sure to fully grasp the consequences of the change you're > proposing. I'm a bit worried about "weird" consequences that we may not > be thinking of at this time. But maybe we should simply apply the > patch, and see if it causes problems for some specific use cases. I'm also a bit afraid of the consequences. It also makes make processing, which is already difficult to understand, even more obfuscated. Here's a wild idea... In rpi-userland/Config.in: if BR2_PACKAGE_RPI_USERLAND config BR2_PACKAGE_LIBEGL_PROVIDER string default "rpi-userland" endif In opengl/libegl/libegl.mk: LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER)) It's still hackish of course, because: - rpi-userland/Config.in defines a symbol "belonging" to the libegl package; - only one provider can be defined, Kconfig will scream if it's defined twice; - it may not work at all :-). Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-17 22:20 ` Arnout Vandecappelle @ 2013-12-17 22:35 ` Yann E. MORIN 2013-12-19 16:58 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2013-12-17 22:35 UTC (permalink / raw) To: buildroot Arnout, All, On 2013-12-17 23:20 +0100, Arnout Vandecappelle spake thusly: > On 17/12/13 10:04, Thomas Petazzoni wrote: > >Dear Yann E. MORIN, > > > >On Tue, 17 Dec 2013 08:58:13 +0100, Yann E. MORIN wrote: > > > >>> 1. Since the .mk part is centralized in opengl/libgles, but the > >>> Config.in is not (spread in each OpenGL implementation doing the > >>> select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the > >>>Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" > >>>in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL > >>>as something like: > >>> > >>>config BR2_PACKAGE_HAS_OPENGL_ES > >>> bool > >>> default y if BR2_PACKAGE_RPI_FIRMWARE > >>> default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION > >>> default y if BR2_PACKAGE_... > >> > >>With this first proposal, it becomes a bit more complex to > >>implement providers in BR2_EXTERNAL. > > > >Ah, true. > > Also it feels inconvenient to me that the virtual package should "know" > about all its providers. Agreed. > >>> 2. Or, we can take the opposite route by pushing the currently > >>> centralized libgles.mk logic that adds each OpenGL > >>>implementation in LIBGLES_DEPENDENCIES down into each OpenGL > >>>implementation .mk file. But that requires a late evaluation of > >>>$(generic-package), so that all OpenGL implementations can be > >>>registered in LIBGLES_DEPENDENCIES before the generic-package macro > >>>of libgles.mk is evaluated. This would require something like > >>>Yann's patch. > >> > >>Needless to say I would highly prefer this second solution. > > > >Right. In principle, I have nothing against this solution. It's just > >that I am not sure to fully grasp the consequences of the change you're > >proposing. I'm a bit worried about "weird" consequences that we may not > >be thinking of at this time. But maybe we should simply apply the > >patch, and see if it causes problems for some specific use cases. > > I'm also a bit afraid of the consequences. It also makes make processing, > which is already difficult to understand, even more obfuscated. > > > Here's a wild idea... > > In rpi-userland/Config.in: > > if BR2_PACKAGE_RPI_USERLAND > config BR2_PACKAGE_LIBEGL_PROVIDER > string > default "rpi-userland" > endif > > In opengl/libegl/libegl.mk: > > LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER)) > That's about what I am experimenting right now! :-p But I've done it slightly differently: package/opengl/libegl/Config.in: config BR2_LIBEGL_PROVIDER string package/rpi-userland/Config.in: config BR2_LIBEGL_PROVIDER default "rpi-userland" if BR2_PACKAGE_RPI_USERLAND And the same .mk fragment you suggested for libegl. My solution is a little bit more compact, and since it does not use a package-named variable, we can say that packages do not step on one-another's feet. Yet, a bit hackish, I have to concede... > > It's still hackish of course, because: > > - rpi-userland/Config.in defines a symbol "belonging" to the libegl package; > > - only one provider can be defined, Kconfig will scream if it's defined > twice; Is it even valid to have two providers of the same functioanlity? What would happen: what libEGL.so would be used? Probably the last one installed, ie. the one from the alphabetically-last provider. > - it may not work at all :-). I'll tell you when I'm done with my checks... ;-p Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-17 22:35 ` Yann E. MORIN @ 2013-12-19 16:58 ` Arnout Vandecappelle 2013-12-19 20:43 ` Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2013-12-19 16:58 UTC (permalink / raw) To: buildroot On 17/12/13 23:35, Yann E. MORIN wrote: > Arnout, All, > > On 2013-12-17 23:20 +0100, Arnout Vandecappelle spake thusly: [snip] >> Here's a wild idea... >> >> In rpi-userland/Config.in: >> >> if BR2_PACKAGE_RPI_USERLAND >> config BR2_PACKAGE_LIBEGL_PROVIDER >> string >> default "rpi-userland" >> endif >> >> In opengl/libegl/libegl.mk: >> >> LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER)) >> > > That's about what I am experimenting right now! :-p > > But I've done it slightly differently: > > package/opengl/libegl/Config.in: > config BR2_LIBEGL_PROVIDER > string > > package/rpi-userland/Config.in: > config BR2_LIBEGL_PROVIDER > default "rpi-userland" if BR2_PACKAGE_RPI_USERLAND > > And the same .mk fragment you suggested for libegl. Nice! I'm all for it! I didn't know it was allowed in Kconfig to define the same symbol twice. But indeed, we already do that in arch/ > My solution is a little bit more compact, and since it does not use a > package-named variable, we can say that packages do not step on > one-another's feet. Yet, a bit hackish, I have to concede... > >> >> It's still hackish of course, because: >> >> - rpi-userland/Config.in defines a symbol "belonging" to the libegl package; >> >> - only one provider can be defined, Kconfig will scream if it's defined >> twice; > > Is it even valid to have two providers of the same functioanlity? What > would happen: what libEGL.so would be used? Probably the last one > installed, ie. the one from the alphabetically-last provider. Completely true. With your construct, if somehow two providers are selected, Kconfig will probably just give you the first-sourced provider. Regards, Arnout > >> - it may not work at all :-). > > I'll tell you when I'm done with my checks... ;-p > > Regards, > Yann E. MORIN. > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider 2013-12-19 16:58 ` Arnout Vandecappelle @ 2013-12-19 20:43 ` Yann E. MORIN 0 siblings, 0 replies; 18+ messages in thread From: Yann E. MORIN @ 2013-12-19 20:43 UTC (permalink / raw) To: buildroot Arnout, All, On 2013-12-19 17:58 +0100, Arnout Vandecappelle spake thusly: > On 17/12/13 23:35, Yann E. MORIN wrote: > >Arnout, All, > > > >On 2013-12-17 23:20 +0100, Arnout Vandecappelle spake thusly: > [snip] > >> Here's a wild idea... > >> > >>In rpi-userland/Config.in: > >> > >>if BR2_PACKAGE_RPI_USERLAND > >>config BR2_PACKAGE_LIBEGL_PROVIDER > >> string > >> default "rpi-userland" > >>endif > >> > >>In opengl/libegl/libegl.mk: > >> > >>LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER)) > >> > > > >That's about what I am experimenting right now! :-p > > > >But I've done it slightly differently: > > > >package/opengl/libegl/Config.in: > > config BR2_LIBEGL_PROVIDER > > string > > > >package/rpi-userland/Config.in: > > config BR2_LIBEGL_PROVIDER > > default "rpi-userland" if BR2_PACKAGE_RPI_USERLAND > > > >And the same .mk fragment you suggested for libegl. > > Nice! I'm all for it! I didn't know it was allowed in Kconfig to define the > same symbol twice. But indeed, we already do that in arch/ In fact, you can define a symbol only once: the moment you give it a type is when the symbol is actually 'defined'. You can however use the symbol in different places, to set a default value or other properties (depends, selecti, options...) There are a few properties of a symbol that can only be set once: - the type (obviously) - the prompt, even if it is conditional - the help text > >My solution is a little bit more compact, and since it does not use a > >package-named variable, we can say that packages do not step on > >one-another's feet. Yet, a bit hackish, I have to concede... > > > >> > >> It's still hackish of course, because: > >> > >>- rpi-userland/Config.in defines a symbol "belonging" to the libegl package; > >> > >>- only one provider can be defined, Kconfig will scream if it's defined > >>twice; > > > >Is it even valid to have two providers of the same functioanlity? What > >would happen: what libEGL.so would be used? Probably the last one > >installed, ie. the one from the alphabetically-last provider. > > Completely true. With your construct, if somehow two providers are > selected, Kconfig will probably just give you the first-sourced provider. No, we can't know which one is used: the symbols are stored in buckets, indexed by the hash of each symbol. So, there is no (simple) way to know what symbols takes precedence, since we can't easily predict what bucket they'll end up, so what symbol will be hit first/last. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-12-19 20:43 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-10 15:18 [Buildroot] [BR2_EXTERNAL] Ability to specify regular packages behaviour from external.mk David Corvoysier 2013-12-10 19:07 ` [Buildroot] [PATH 0/1] Fix GLES when a provider is defined in BR2_EXTERNAL Yann E. MORIN 2013-12-10 19:07 ` [Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider Yann E. MORIN 2013-12-11 10:46 ` Arnout Vandecappelle 2013-12-11 12:25 ` Yann E. MORIN 2013-12-11 13:03 ` David Corvoysier 2013-12-11 14:05 ` David Corvoysier 2013-12-12 22:00 ` Arnout Vandecappelle 2013-12-12 22:13 ` Thomas Petazzoni 2013-12-12 23:08 ` Arnout Vandecappelle 2013-12-17 6:11 ` Thomas Petazzoni 2013-12-17 7:58 ` Yann E. MORIN 2013-12-17 9:04 ` Thomas Petazzoni 2013-12-17 22:07 ` Yann E. MORIN 2013-12-17 22:20 ` Arnout Vandecappelle 2013-12-17 22:35 ` Yann E. MORIN 2013-12-19 16:58 ` Arnout Vandecappelle 2013-12-19 20:43 ` Yann E. MORIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox