[Mesa-dev] [PATCH] mesa: Remove the generated glapi from source control, and just build it.
eric at anholt.net
Thu May 24 11:44:36 PDT 2012
On Wed, 23 May 2012 13:33:35 -0700, Ian Romanick <idr at freedesktop.org> wrote:
> On 05/23/2012 12:45 PM, Eric Anholt wrote:
> > Mesa already always depends on python to build. The checked in
> > changes are not reviewed (because any trivial change rewrites the
> > world). We also have been pushing commits between xml change and
> > regen where at-build-time xml-generated code disagrees with committed
> > xml-generated code. And worst of all, sometimes we ("I") check in
> > *stale* xml-generated code.
> Though the person making the changes will typically review them. I
> renew my objection that making tiny changes to the generator scripts can
> result in catastrophic changes in the generated code. We've encountered
> several situations where changing one part of the generator causes sizes
> of broad categories of GLX protocol messages to be miscalculated.
> git-diff makes this easy to notice. "Wait, why did indirect_size.c
> change at all? That has nothing to do with the change I intended."
You're counting the cost of making this change, and discounting the cost
to everyone else that isn't changing the generator scripts. Try
maintaining a patch series where you modify glapi xml more than once
over the course of building it.
And I didn't even bring up the breakage because of people checking in
changes to built files instead of generators. See
> Note also that some of the generated code is platform-specific and gets
> little testing. How often does anyone test the C-based dispatch code?
> Or the SPARC dispatch code? Or even the 32-bit x86 dispatch code?
That's a testing issue. I'll buy you lunch if you reviewed my last
diffs that modified the sparc dispatch code.
> I know Paul asserts people can diff the files by hand. I assert that,
> while they can, nobody will do that ever. People will look for changes
> in the files that they expected to change. Given the size of the
> potential set of changed files, I expect that change in unexpected files
> will go unnoticed.
When changing Paul's test generators the second time, I diffed the whole
build tree. So not "nobody will do that ever". That said, when doing
so, I caught a bug from my first time when I didn't diff. I do
acknowledge that there will be downsides to our untested code.
> Nobody runs indirect rendering tests. Therefore we have no testing of
> code that we might not even notice we were changing. That seems just
> about as awful as possible.
Yeah, and also nobody* intentionally runs indirect rendering for usage
either because it's garbage -- stuck back in the fixed function days
with no sign of ever changing. (*OK, so I'm sure there actually are some
crazies still using it)
Sadly, the glx spec mandates indirect rendering contexts, so we can't
conformantly just rip it out and replace it with a direct implementation
because it would break cross-process context sharing. I still think
we'd be doing our users a favor to just throw BadAlloc when asked for
But hey. If we actually cared about indirect GLX working, we should
just have piglit rerun some of piglit/general under indirect. That
would be a lot more reliable than eyeballing diffs, whether or not you
check them in.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the mesa-dev