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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
