OpenGL headers fight

Hi Julian !

I have a feature request to add in the big Juce Todo list !
I will be very glad if you take some time to do it one day.
Here it is:

Could you please encapsulate platform OpenGL headers inclusion in Juce private implementation ?
Today, you do it very well for operating systems headers.
It could be great that juce_opengl.h do not include gl.h and co...

Why doing that ?
- Save some compilation time for Juce client applications.
- Save some old C macro and namespace pollution for Juce client applications.
- And first of all, saving some tricky compilation problems:

My software uses Glew (http://glew.sourceforge.net/) and Glew do not like that gl.h was include before glew.h. (#error is generated)
Of course, including glew.h before juce_opengl.h solve this issue.
But this fix introduces new issues when using GLEW_MX compilation flag (for multi OpenGL context support).
In this case glew.h defines macros with OpenGL function names (like glActiveTexture...)
and those macros are expended in JUCE_GL_EXTENSION_FUNCTIONS macro. (who is defined in juce_OpenGLExtensions.h (also included juce_opengl.h)).
This behavior introduces compilation errors.

By letting JUCE_GL_EXTENSION_FUNCTIONS machinery be internal to Juce's cpp files, this would solve all macros header fighting problems.

I hope this change make sense for other project mixing Juce and other OpenGL dependent libraries.
Thanks in advance for your concern about this.

 

Thanks - I can't make it work like that by default because it'd break people's code, but it could be made possible to disable it with a flag. (Although TBH I can't remember whether there might be some things in the juce headers that do rely on GL definitions - that's a possibility)

Hi

I understand your concern about retro-compatibility issues.

In my case, the flag solution could be perfect.

It seems that the only Juce's header dependency on OpenGL is

struct OpenGLExtensionFunctions used in class OpenGLContext.

 

Thanks for your answer.