[Mesa-dev] glproto changes

[Jeremy Huddleston]

Yeah... so considering the comments in mesa-dev earlier today, I was really surprised to see that glproto and dri2proto were tagged today.  I think we need to brownbag retract and rethink this.

These changes break API.  I'm all for fixing the structs, but anything that breaks API (or worse, protocol) certainly warrants much more than the +0.0.1 version bump.  This also makes it impossible to build the current dev and current stable with the same protos installed.  I haven't looked at the details specifically, but I suspect that it also changes what is on the wire, meaning clients and the server may disagree depending on which glproto version they were using.  Is that the case?  If not, can't we solve this with some creative union{}ing?

Either way, I think we should retract the glproto 1.4.13 release until we can get this straightened out.

On May 4, 2011, at 18:17, Dave Airlie wrote:

> So I wasn't watching and glproto broke its interface, and I think its bad.
> 
> Why?
> 
> You can no longer bisect things across this point without now moving glproto.
> glxproto.h:xGLXBufferSwapComplete was a released header file
> definition, you cannot go back and change history.
> 
> This should have been handled with xGLXBufferSwapComplete2 struct that
> newer mesa and X server could would use
> instead of the older code. Old code would build against the old broken
> defintion but since its broken it wouldn't matter,
> and new code would build against the new fixed definition.
> 
> This doesn't address the I need the latest glproto to build mesa and
> my distro doesn't have which concerns me less
> than the I can't bisect anymore and I fully agree with Jesse that the
> last time we tried using #ifdef for this sort of thing it led
> to a number of untested combos resulting in impossible to debug issues.
> 
> Dave.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>