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

[Ian Romanick]

On 02/23/2012 11:52 AM, Chad Versace wrote:
> On 02/23/2012 12:52 AM, Ian Romanick wrote:
>> 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:
>>>>> 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.
>
> Thanks for taking the time to expound on the reasons. I agree now see that this situation is different from the yacc situation, that "outputs from things like lex and yacc are very different from generated code". If having the headers tracked by git has proven itself over the years to prevent subtle breakage, I drop my objection.
>
> But this brings up another issue. Why is src/mapi/glapi/mapi_glapi_tmp.h checked into git, but following generated headers are not:
>    src/mapi/es1api/glapi_mapi_tmp.h
>    src/es2api/glapi_mapi_tmp.h
>    src/shared-glapi/glapi_mapi_tmp.h
> I'm genuinely asking and would like to know.

Because I had nothing to do with those files.  I don't even know what 
they are, to be honest.  My guess is that the content of these files may 
depend on options selected at configure time.  I think Chia-I added 
them, so perhaps he will know more.

I think a reasonable compromise is to track the files in GIT *and* build 
them.  That prevents the situation that Paul hit (not knowing that he 
need to build and commit the files) and still gives the benefits of 
tracking.