Re: [AD] What to do about gl_ext.h

[ Thread Index | Date Index | More Archives ]

There are two issues.

First, as it stands now, if you add a new extension/api, it inserts a field in the middle of types like ALLEGRO_OGL_EXT_LIST, which breaks the al_get_opengl_extension_list ABI. This is fixable through the use of a python generator of some sort which would always add new things at the end of that struct (which is fine).

The second issue are macros like _ALLEGRO_GL_EXT_direct_state_access inside gl_ext_api.h and others. Depending on whether they are defined or not, you again get insertions in the middle of the ALLEGRO_OGL_EXT_LIST struct, but even worse, you randomly get additional exported symbols for the global OpenGL API aliases we provide. These macros depend on the contents of the system OpenGL headers, which means that I don't think we can guarantee their presence (if we could, then we'd just require their presence at configuration time, which I think would be an interesting solution). An alternate solution would be to remove the macros, but only populate the API/extensions that are actually detected. Both solutions seem a bit of a pain to implement.


On 10/16/2016 01:58 PM, Elias Pschernig wrote:
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
<mailto: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.


    Allegro-developers mailing list
    Allegro-developers@xxxxxxxxxx <mailto:Allegro-developers@xxxxxxxxxx>

Allegro-developers mailing list

Mail converted by MHonArc 2.6.19+