Support for generating bindings for specifications which describe multiple APIs (OpenGL + OpenGL ES)

[andesyv]

Hello!,

I was working on a project which requires switching between OpenGL and OpenGL ES bindings on runtime and I was struggling to find a library that could support this. I was using both glbinding and glesbinding, but they clash on compiling/linking as they expose the same symbols. However, I noticed that they could probably be combined somehow. So I've done some "hacks" to combine them for these binding generator scripts and I've been testing it out in this fork: andesyv/glmixedbinding

Combining the symbols from OpenGL and OpenGL ES created another issue however, in that types from OpenGL ES bleed into the type declarations for OpenGL Core/Compatibility (specifically the EGL related type declarations included in the OpenGL ES standard). So I've attempted to solve this by additionally stripping down the types exposed in the versioned headers (glbinding/gl33/types.h, glbinding/gl43ext/types.h, glbinding/gles31/types.h, e.t.c.). But for safety or compatibility with current projects relying on glbinding, I've set this "type stripping" configurable with a stripFeatureHeaders field in the profile JSON.

Hopefully this (at least partially) closes #6.

[scheibel]

Thanks for opening this PR.
Your PR seems to introduce some general code improvements in addition to the actual implemented feature: generating multiple APIs into one binding project.

I see you're also referencing an earlier issue we opened. I cannot recall our intent to open this issue anymore and unfortunately, I haven't added rationale, approach or general documentation to the issue.
But some time ago, I also tried to add support for multiple APIs to allow for more heterogeneous setups. There, I resorted to an integration of multiple, independently generated APIs.
For example, I implemented a demonstrator that switches OpenGL and OpenGL ES contexts at run time:

• https://github.com/scheibel/graphics-api-test/
  In a similar sense, we provide OpenGL ES demos within glbinding:
• https://github.com/cginternals/glbinding/tree/master/source/examples

Regarding your chosen approach to make your changes effective during parsing and generation, you adopted a predefined profile instead of adding a new one.
Can you adjust your PR, such that the already existing profiles will not result in different generated APIs and you add another profile for your application case (such as gl+gles.json)?