What exactly is the problem with the ABI there again? Each OpenGL extension
is basically a set of GL_* constants and a set of gl_* API entries. Since
those API entries are loaded at runtime, Allegro provides a function
pointer for each which is filled in when it loads them. Every time a new
extension is added, that adds additional function pointers.

Anyway, wrapping it in ALLEGRO_UNSTABLE sounds good enough to me.

On Sun, Oct 16, 2016 at 2:59 PM, SiegeLord <siegelor...@gmail.com> wrote:

> A little while ago I sent out a patch to revert Elias's addition of the
> various multisampling/depth buffer additions to gl_ext.h (and the
> associated headers) as it broke ABI compatibility. Those additions were
> obviously useful, and it'd be a terrible state of affairs if we couldn't
> ever add anything to gl_ext.h again due to the fear of breaking ABI
> compatibility. Initially, I thought that the macro magic we use to generate
> that API was at fault, so I had an idea to replace it with a Python
> generator script that would append things at the end of the
> ALLEGRO_OGL_EXT_LIST/ALLEGRO_OGL_EXT_API structs instead of in the very
> middle as is done today. Unfortunately, as I started working on it I
> realised that the source headers (e.g. gl_ext_alias.h) are full of macros.
> Depending on the platform details you compile Allegro in, you get a
> completely different API.
> That was disheartening, and I'm now leaning just wrapping the entirety of
> gl_ext.h inside ALLEGRO_UNSTABLE check and just punting the whole issue.
> Any opinions?
> Incidentally, once this issue is addressed, I'm thinking of releasing
> 5.2.2 soon, as we have updates to get things to compile on the new OSX as
> well as some significant Android-related changes.
> -SL
> _______________________________________________
> Allegro-developers mailing list
> Allegro-developers@gna.org
> https://mail.gna.org/listinfo/allegro-developers
Allegro-developers mailing list

Reply via email to