Currently -opengl es2 builds result in the following:
- QT_OPENGL_ES and QT_OPENGL_ES_2 are defined
- qopengl.h includes GLES2/gl2.h
In order to be able to use some of the new features from GLES 3.0, for example glMapBufferRange which QOpenGLBuffer::map() could utilize, this needs to be enhanced as follows:
- a config test checks if GLES3/gl31.h is availale
- if yes, QT_OPENGL_ES_31, QT_OPENGL_ES_3, QT_OPENGL_ES_2 and QT_OPENGL_ES are defined and qopengl.h includes GLES3/gl31.h
- a config test checks if GLES3/gl3.h is available
- if yes, QT_OPENGL_ES_3, QT_OPENGL_ES_2 and QT_OPENGL_ES are defined and qopengl.h includes GLES3/gl3.h
Note that the config tests have to check if some GLES 3.0/3.1 functions are actually available (i.e. that linking succeeds), just checking for the headers is not sufficient since the presence of the headers does not necessarily mean that the vendor-specific libGLESv2 contains the 3.0+ entry points.
Since the headers are backwards compatible and are freely mixable (can be included on top of each other), including a newer GLES header presents no break to applications.
QOpenGLVertexArrayObject should be checked too. VAOs are available (but not mandatory) in GLES3 as part of the standard (not as an extension).