Re: [AD] What to do about gl

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 <siegelordex@xxxxxxxxxx> 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@xxxxxxxxxx
https://mail.gna.org/listinfo/allegro-developers