[Mesa-dev] [PATCH] mesa: Remove the generated glapi from source control, and just build it.

[Eric Anholt]

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.
> 
> <broken_record>
> 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
8d09f4d0cc8d2ac5398c8b26638d5659429a4280.

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

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
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120524/860e9636/attachment.pgp>