[Nix-dev] Mesa-9.2

[Baptist BENOIST]

>> When I build mesa_noglu, in include/GL/glext.h I can clearly see in the
>> top level that the macro gets defined (line 3451):
> Note that:
> - one can find similar definitions even in our version in master (9.1.6)
> - this shouldn't be HW-dependent, all pkgs use the same headers from 
> mesa, regardless which GL driver is used in the end

You are right include/GL/glext is defining this macro, I wrongly said that because of the error which was occurring.

In fact the problem comes from a combination of the -Werror -Wundef flags and of the fact that Qt now uses its own glext header.

With Qt and when building with opengl (not opengl es2), the following occurs:

== QtGui/qopengl.h ==
// Described as the only solution to prevent GL/glext.h to be defined in GL/gl.h
#define GL_GLEXT_LEGACY

#include <GL/gl.h>
#include <QtGui/qopenglext.h>

== GL/gl.h ==
#ifdef GL_GLEXT_LEGACY
// Do nothing at all
#else
// The GL_ARB_shader_objects is defined in this file whis is not included when defining the GL_GLEXT_LEGACY_MACRO
# include <GL/glext.h>
#endif
// Later in this file the GL_ARB_shader_objects macro is used without taking care of whether it has been defined or not
// This is the line which produces the undefined macro warning/error because it is normally defined in the GL/glext.h file.
#if GL_ARB_shader_objects

I am currently working on finding the cleanest way to solve this problem, here are the options I am now considering:
 - Rely on the OpenGL ES2 specification instead of the full OpenGL one by using "-opengl es2" configure flag and enabling its support in mesa. The ArchLinux maintainer(s) chosed this solution. This seems to have the side effect of requiring OpenGL ES2 to be enabled on the mesa derivation used by X.
 - Fix the qtopengl.h code by removing the qopenglext.h file and respecting the new OpenGL implementation (the GL_GLEXT_LEGACY has legacy in its name).
 - Fix the qtopengl.h code by copying the GL/gl.h file into Qt (like what has been done for GL/glext.h).

Currently, I think that the second solution is the one to prefer but I am still searching for potential bad consequences (on other platforms and especially the ones which pushed Qt developers to make such a thing) before investing some time on it.

Thanks again for your efforts which were very appreciated :-D