[Buildroot] [BR2_EXTERNAL] Ability to specify regular packages behaviour from external.mk

[Buildroot] [BR2_EXTERNAL] Ability to specify regular packages behaviour from external.mk

[David Corvoysier]

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

[Buildroot] [PATH 0/1] Fix GLES when a provider is defined in BR2_EXTERNAL

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Yann E. MORIN]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Yann E. MORIN]

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.  |
'------------------------------'-------'------------------'--------------------'

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[David Corvoysier]

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.
>

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[David Corvoysier]

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
>

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Thomas Petazzoni]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Thomas Petazzoni]

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
 

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Yann E. MORIN]

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.  |
'------------------------------'-------'------------------'--------------------'

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Thomas Petazzoni]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'