[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Tue Dec 17 06:11:00 UTC 2013
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
More information about the buildroot
mailing list