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

[SiegeLord]

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



___
Allegro-developers mailing list
Allegro-developers@gna.org
https://mail.gna.org/listinfo/allegro-developers

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

[Elias Pschernig]

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

[AD] What to do about gl_ext.h

[SiegeLord]

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