[Mesa-dev] [PATCH 6/6] mesa: remove FEATURE_ES1 tests in enable.c code

Brian Paul brianp at vmware.com
Mon Sep 24 07:36:09 PDT 2012


On 09/23/2012 12:51 PM, Matt Turner wrote:
> On Sat, Sep 22, 2012 at 5:45 PM, Brian Paul<brian.e.paul at gmail.com>  wrote:
>> From: Brian Paul<brianp at vmware.com>
>>
>> ---
>>   src/mesa/main/enable.c |    6 ------
>>   1 files changed, 0 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
>> index 3643cfb..fe2870b 100644
>> --- a/src/mesa/main/enable.c
>> +++ b/src/mesa/main/enable.c
>> @@ -717,7 +717,6 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, GLboolean state)
>>            }
>>            break;
>>
>> -#if FEATURE_ES1
>>         case GL_TEXTURE_GEN_STR_OES:
>>           /* disable S, T, and R at the same time */
>>           {
>> @@ -738,7 +737,6 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, GLboolean state)
>>               }
>>            }
>>            break;
>> -#endif
>>
>>         /* client-side state */
>>         case GL_VERTEX_ARRAY:
>> @@ -1434,7 +1432,6 @@ _mesa_IsEnabled( GLenum cap )
>>               }
>>            }
>>            return GL_FALSE;
>> -#if FEATURE_ES1
>>         case GL_TEXTURE_GEN_STR_OES:
>>           {
>>               const struct gl_texture_unit *texUnit = get_texcoord_unit(ctx);
>> @@ -1447,7 +1444,6 @@ _mesa_IsEnabled( GLenum cap )
>>                     ? GL_TRUE : GL_FALSE;
>>               }
>>            }
>> -#endif
>>
>>         /* client-side state */
>>         case GL_VERTEX_ARRAY:
>> @@ -1485,12 +1481,10 @@ _mesa_IsEnabled( GLenum cap )
>>               goto invalid_enum_error;
>>            CHECK_EXTENSION(EXT_secondary_color);
>>            return (ctx->Array.ArrayObj->VertexAttrib[VERT_ATTRIB_COLOR1].Enabled != 0);
>> -#if FEATURE_ES
>
> So this is actually FEATURE_ES without the '1'. Just want to make sure
> you saw that.
>
> I guess I don't understand what the purpose of these patches is. We
> want people who aren't building Desktop GL/ES1/ES2 to get all the
> API-specific code? Why?

We're moving toward run-time API selection so all the compile-time 
stuff is just clutter.  The #ifdef tests for ES1/2 are spotty at best. 
  Finally, there's less chance of accidentally breaking ES paths if 
always compile that code.

-Brian


More information about the mesa-dev mailing list