|Re: [AD] What to do about gl_ext.h|
[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
- To: allegro-developers@xxxxxxxxxx
- Subject: Re: [AD] What to do about gl_ext.h
- From: SiegeLord <siegelordex@xxxxxxxxxx>
- Date: Mon, 17 Oct 2016 19:49:25 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=jadmh01KuOt/vp69ndEmyRO0X5IVYzoXYrb+rgWB0cE=; b=e2crcHmYzg6/EFqLALmOaC88G0Z/V/QkjbMBEMRBSJHuhBtaMSI3KIdVATrvfLmORh VdpsYOb10T3UXxqBIWDauYMp7T6oIWMIgNTJ8pwT+gN1lmcHgNFKHNYX4sGIbYj9JkZy iHorCvUT/TPrz0FpmXtWtZxgrmYiUzqOBfXnHqafD92thR+Uz7SuAtmV0wCF6MII0aCL 7+zWsenzMJc0RE6m6J8Y1lhIF1Ze6ruD0yy9ITAVW7iPzIneLChR6T1QraDvhp6TV48w 2NzfFMQ5QMmlYjgVAm4dsAa0CdM78tZJjSZcBbGLdbCgPpO85Jyw6WYq6pwmx4goGNN7 vrxg==
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
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 mailing list