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

[Ian Romanick]

On 02/22/2012 04:06 PM, Chad Versace wrote:
> On 02/22/2012 02:22 PM, Ian Romanick wrote:
>> 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:
>
> I really want to see all *build* artifacts removed from Mesa's *source* control. I recall the
> pain of having the bison and flex output managed by git, and I don't like continuing that fallacy.

Outputs from things like lex and yacc are very different from generated 
code.  There is a 1:1 (or 1:very few) relationship with input code and 
generated files, and nobody on this project changes the generator.  The 
lex and yacc generated files were especially bad because different 
versions of the tools generated slightly different code.  As a result, 
changing the yacc source could result in lots of unrelated changes to 
the generated C source.  That was a total disaster, but it's a very 
different situation.

Almost all of the problems I am concerned about potentially occur when 
changes are made to the generator scripts.  All of the problems that I 
am concerned about have been encountered while working on these very 
generator scripts.

I've been reading a book about code generation, and the author suggests 
keeping a (simple) set of inputs and known good outputs for detecting 
bad or surprising changes in generated code.  We could add something 
like that, but it would be a lot of work at this point,  It would also 
put more build artifacts in source control.  The author flat out tells 
you to put generated code in source control.

>> 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.
>
> Wouldn't `git log *.xml *.py` also alert you that the generated headers have changed?

How does that tell me that the generated src/glx/indirect.c changed when 
there should not have been any protocol changes?  How does that tell me 
that the generated src/mapi/glapi/glapi_x86.S is now empty (but I'm 
building on x86-64)?  *Both* of these situations have happened over the 
years.

>> 2. Changes to the XML files frequently precipitate changes to files in the xserver.  There's no way to automatically handle that.
>
> I don't understand how 2 affects this discussion. Is it that the xserver build relies on these generated headers? If so, then
> we can move the generated headers to the xserver repo and merrily remove these build artifacts from Mesa's source control.
> Afterwards, it would be the xserver's devs responsibility to manually update their headers, or fix their makefiles to gen them
> at build time.

Scripts in Mesa generate GLX protocol code (C source files) in the 
xserver.  Look at src/mapi/glapi/gen/Makefile.

>> 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.
>
> $ cd src/mapi/glapi/gen
> $ make mesa
> real	0m5.634s
>
> I don't think an adding 5 seconds to a clean build is cause for concern if the addition allows us
> to remove build artifacts from source control.

Hmm... I'm able to reproduce that result.  I'd swear that there was at 
least one of the scripts took well over a minute.  I suppose it's 
possible that CPUs (and Python) got 20x faster since the last time I did 
any major work on the generators.  It has been a few years.  Either that 
or my Python code was crap, and somebody fixed it.  Or some combination 
of the two.  *shrug*