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<i...@freedesktop.org
<mailto:i...@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.roman...@intel.com
<mailto:ian.d.roman...@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*
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
