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

[Ian Romanick]

On 04/02/2014 05:21 AM, Jose Fonseca wrote:
> ----- 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.

I agree.  I hate all the C pre-processor madness.  We used to commit the
generated files to CVS, so the generated file had to work in all
configurations.  Now that the files are gererated during the build, that
should be tractible.

Dylan Baker suggested to me that we use Mako (Python template library
used in piglit) to help clean up the code generators.  This also seems
like a good idea.  Would adding a Mako dependency in Mesa be okay?

> Jose