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

[Chia-I Wu]

On Tue, Feb 28, 2012 at 1:55 AM, Ian Romanick <idr at freedesktop.org> wrote:
> 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.
It was checked in because other generated files in glapi/ did too.  At
one point, a desktop-GL-only build did not require python.  But that
might not be the case for quite a while now.

On the other hand, IIRC, GLES code/headers were generated on-the-fly
before I started working on them.  I followed that, which was also my
preference, when adding those headers for GLES.

As for what {gl,es1,es2}api/glapi_mapi_tmp.h are for, they are used so
that libGL.so/libGLESv1_CM.so/libGLESv2.so call into the shared
libglapi.so, instead of embedding their own copies of glapi.  Thus
glapi/glapi_map_tmp.h is used only when --enable-shared-glapi is
specified.

>
> 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.



-- 
olv at LunarG.com