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

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

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