[Mesa-dev] [PATCH 0/6] Some glapi clean-up releated to GLES

[Jose Fonseca]

----- Original Message -----
> Tomorrow or Friday I'm going to send out the last of the
> GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
> out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
> is the GLES subset of the ARB extension.
> 
> In preparing for this new extension, I noticed the old problem that any
> extension function that aliases a core function (whether it is core in
> GLES or desktop GL) isn't hidden.  This series should fix that.
> 
> Longer term, I'd like to change the generation of libGL*.  Right now all
> the information describing the interfaces and the information selecting
> the exposed interfaces in combined in a single XML database.  As patch 4
> shows, that makes it impossible to have a single function that is
> exposed in one API but hidden in another.  I'd like to pull all the
> "offset", "static_dispatch", "glx_ignore", and "exec" information out
> into separate files.
> 
> This will mean that adding a new extension will require changes to
> multiple files.  The usual XML bits will need to be added.  Entries will
> need to be add to per-libGL* files, an "exec" file, and an "offsets".
> We can probably get rid of the offsets file since no functions will ever
> be added that have static offsets.

ABI details like symbol visibility can vary not only per API but also per platform, so having these ABI details seperate from the prototypes (which are cross-platform and cross-API) sounds a good idea to me.

On the topic of glapi cleanup, I noticed that a lot of glapi code ends up mixing scripted C code generation with C pre-processor macros. I'm sure there are historic reasons for it but this combination obfuscates the code. It would be better to use only one of the techniques; or more realistically, drop the macros and rely on code generation exclusively.  It would be much easier for humans to reason about the generated code then.

Jose