Skip to content

Add new virtual-package infrastructure

Eric Le Bihan buildroot 1 version New

Get series with b4
b4 am 20140307140052.GA5226@pc-eric

Versions newest first

  1. v2 Latest0 of 17 patches 0 repliesNew

Patches in v2 No applies recorded yet

None of the 17 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

Cover letter [Buildroot] [PATCH 0/17 v2] Add new virtual-package infrastructure

Hi!

Quoted 10 lines · Thomas Petazzoni

Dear Yann E. MORIN,

Quoted 5 lines · Yann E. MORIN

package/libgles: rename the _HAS and _PROVIDES variables package/libegl: rename the _HAS and _PROVIDES variables package/libopenmax: rename the _HAS and _PROVIDES variables package/libopenvg: rename the _HAS and _PROVIDES variables package/luainterpreter: rename the _HAS and _PROVIDES variables

Quoted 8 lines

I certainly agree to ensure that the kconfig symbol matches the package name. However, I am not sure the renaming of BR2_PACKAGE_HAS_OPENGL_ES to BR2_PACKAGE_HAS_LIBGLES is really nice. BR2_PACKAGE_HAS_OPENGL_ES had the merit of explicitly containing the word "OpenGL", while LIBGLES makes that a bit more cryptic. Do we want to instead rename the package to libopengl-es or some other variation on this?

A similar reflexion could be made on the naming of the libegl package.

The names defined by Khronos Group are "OpenGL ES" and "EGL". That would logically lead to:

- libopengl-es/BR2_PACKAGE_HAS_OPENGL_ES
- libegl/BR2_PACKAGE_HAS_EGL

But the names used for the libraries are libGLES and libEGL. Googling them leads to OpenGL related pages. Some GNU/Linux distros (Arch Linux, Debian) use them in package names.

IMHO, BR2_PACKAGE_HAS_LIBGLES and BR2_PACKAGE_HAS_LIBEGL, though not sticking with the official names, are not *that* cryptic.

Best regards,
ELB

Read the cover letter in its thread