On 04/07/2016 06:17 AM, Rogovin, Kevin wrote: > Hello, > >> typo -> ...query (same goes for patch 1/2) > > I hate typos. Thanks for pointing it out. > >> Please correct me if I'm wrong, but I think we cannot unalias functions once >> they're in. >> It will break the backwards compatibility we're trying to manage with glapi. >> If we want to >> retain it we should opt for the least likely to hit solution ? > > I confess I do not understand. What exactly is being compatible with what?
libGL and the drivers. A driver built without this patch will not work with a libGL built with this patch, and vice versa. It is only in fairly extreme situations that we intentionally break that compatibility. The last time that we did it was to unalias GL_EXT_framebuffer_object and GL_ARB_framebuffer_object functions. It was a pretty big deal when that happened. >> Either I'm misreading the comment above the function or this doesn't belong >> here. > > If I understood the code correctly, that is setting up a function table for > when GL state is in a glBegin/glEnd pair. I added the ARB function because > the non-ARB one was there already. > > -Kevin > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
