[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