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

[SiegeLord <siegelordex@xxxxxxxxxx>]

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.

-SL

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.
>
>     -SL
>
>     _______________________________________________
>     Allegro-developers mailing list
>     Allegro-developers@xxxxxxxxxx <mailto:Allegro-developers@xxxxxxxxxx>
>     https://mail.gna.org/listinfo/allegro-developers
>     <https://mail.gna.org/listinfo/allegro-developers>
>
>
>
>
> _______________________________________________
> Allegro-developers mailing list
> Allegro-developers@xxxxxxxxxx
> https://mail.gna.org/listinfo/allegro-developers