On Wed, 23 May 2012 13:33:35 -0700, Ian Romanick <[email protected]> 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.
pgpfBB64rPmoC.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
