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).