[Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

[Ian Romanick]

On 02/22/2012 02:17 PM, Paul Berry wrote:
> On 22 February 2012 13:52, Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
>
>     On 02/22/2012 01:41 PM, Paul Berry wrote:
>
>           From
>         http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
>         <http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt>:
>
>              Accepted by the<cap>  parameter of Enable, Disable and
>         IsEnabled,
>              and by the<pname>  parameter of GetBooleanv, GetIntegerv,
>         GetFloatv
>              and GetDoublev:
>
>              TEXTURE_CUBE_MAP_SEAMLESS                   0x884F
>
>
>     Oops.  That was my typo.  You'll also have to regenerate the various
>     files that depend on the XML definitions.  I think this change
>     should only cause changes in src/mesa/main/enums.c.
>
>     Reviewed-by: Ian Romanick <ian.d.romanick at intel.com
>     <mailto:ian.d.romanick at intel.com>>
>
>
> Oops.  I didn't realize that those files weren't built automatically.
> I'll send an updated patch.

Dear god, no!  The patch will be huge.

> Is there any good reason why we don't automatically generate files like
> enum.c as part of the mesa build process?  The comment at the top of
> src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
> compilation since we don't want to require Python in order to compile
> Mesa."  But I don't think that makes sense anymore, because Python is
> required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
> as some files in src/glsl.
>
> In point of fact, it seems really strange that a file like
> src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
> process, but src/mesa/main/enums.c isn't, since both files are built
> from the same set of xml sources.

A couple reasons:

1. The generated files really, really, really should be in git so that 
accidental changes will be noticed.  This has bitten us a couple times.

2. Changes to the XML files frequently precipitate changes to files in 
the xserver.  There's no way to automatically handle that.

3. Several of the scripts take a really, really long time to run.  I'm 
not eager to add a few minutes to my clean-build times.