Enable MX option for EGL as well

[ao2]

Hi,

I am using glad2 and I found that the MX option available for the GL wrappers can also help in my specific case to avoid symbols collisions when linking to other components which also use glad, as an alternative to #198

Would it make sense for the MX option to also affect the EGL wrappers generation in a way similar to GL?

Thanks, Antonio

[Dav1dde]

As far as I am aware all the EGL functions are not tied to a context. The display argument is just there to correctly infer the maximum supported version. So API wise a MX option doesn't make sense.

For the vendoring usecase, it's probably still better to vendor the symbols (rename the prefix) or require the symbols to be linked in from the "user". The problem with MX is, it makes the code generation so much harder to maintain that I would not want to add it for something that can be solved with a sed one-liner.

[ao2]

My naive rationale was that the EGL functions are still loaded and so even if link-time symbols collision for the glad_* symbols can be solved with a custom prefix, there could still be runtime overrides of the egl* symbols if multiple components load them using glad independently, with different sets of extensions even.

In my mind #198 addresses a link-time problem, while the MX/GladGLContext mechanism addresses a run-time problem.

However I am not expert enough to insist on that 😄

[ao2]

Or were you suggesting to also prefix the egl* symbols for the vendoring usecase?

[Dav1dde]

All glad symbols are prefixed with glad_, so are the egl functions. The egl* functions you use are just a macro to glad_egl*, so you can just replace all occurences of glad_ with glad_mylib_.

E.g.:

GLAD_API_CALL PFNEGLCREATEWINDOWSURFACEPROC glad_eglCreateWindowSurface;
#define eglCreateWindowSurface glad_eglCreateWindowSurface

[ao2]

Ah, right the egl* symbols are only in the header file, I was overlooking this.
Thanks for clarifying.