[Buildroot] [PATCH] package/libgles: postpone the check for a missing GLES provider
Arnout Vandecappelle
arnout at mind.be
Tue Dec 17 22:20:38 UTC 2013
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
More information about the buildroot
mailing list