...this is really more for IOhannes,
...we've been having lotsa problems with people compiling GEMglBindBufferARB, with glBindProgramARB() being undeclared...this should be included via GL/glext.h, which is included in GEM via GemBase.h...
...but, GemBase.h:34 has a conditional define for INCLUDE_GLEXT, and this actually turns up in two other files: GemMan.cpp:44 and GemPixUtil.h:37 and configNT.h...but I can't find where it is -D'ed? Is this done in the configure process? Is there any real reason to #ifdef it out of the compile process?
thanx, jamie
Zitiere james tittle tigital@mac.com:
...this is really more for IOhannes,
...we've been having lotsa problems with people compiling GEMglBindBufferARB, with glBindProgramARB() being undeclared...this should be included via GL/glext.h, which is included in GEM via GemBase.h...
...but, GemBase.h:34 has a conditional define for INCLUDE_GLEXT, and this actually turns up in two other files: GemMan.cpp:44 and GemPixUtil.h:37 and configNT.h...but I can't find where it is -D'ed? Is this done in the configure process? Is there any real reason to #ifdef it out of the compile process?
yes very simple: glext.h only exists on windows machines if you have the correct headers installed (e.g. nvidia's headers include glext.h, normal vc6 does not ship with them)
so we would need something like "configure" for windows, to check what is there and what not
mfg.a.sdr IOhannes
thanx, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Feb 4, 2005, at 3:00 PM, zmoelnig@iem.at wrote:
Zitiere james tittle tigital@mac.com:
...this is really more for IOhannes,
...we've been having lotsa problems with people compiling GEMglBindBufferARB, with glBindProgramARB() being undeclared...this should be included via GL/glext.h, which is included in GEM via GemBase.h...
...but, GemBase.h:34 has a conditional define for INCLUDE_GLEXT, and this actually turns up in two other files: GemMan.cpp:44 and GemPixUtil.h:37 and configNT.h...but I can't find where it is -D'ed? Is this done in the configure process? Is there any real reason to #ifdef it out of the compile process?
yes very simple: glext.h only exists on windows machines if you have the correct headers installed (e.g. nvidia's headers include glext.h, normal vc6 does not ship with them)
so we would need something like "configure" for windows, to check what is there and what not
...but the problems people currently seeing are occuring on linux machines, not windows machines: are you saying that linux doesn't have a glext.h? That doesn't seem likely...
...from GemBase.h:
#ifdef __APPLE__ #include <OpenGL/gl.h> #include <OpenGL/glext.h> #else #include "config.h" #include <GL/gl.h> # ifdef INCLUDE_GLEXT # include <GL/glext.h> # endif #endif // __APPLE__
...this says that if you aren't osx, go ahead and include gl.h, but then only include glext.h if this other thing is defined...maybe that's a good thing for windows (?), but it seems like it's crippling some linux users: where is this INCLUDE_GLEXT defined in the configure process?
l8r, jamie
Zitiere james tittle tigital@mac.com:
...but the problems people currently seeing are occuring on linux machines, not windows machines: are you saying that linux doesn't have
a glext.h? That doesn't seem likely...
no of course not, glext.h is on every linux system that has openGL-dev installed.
the problem is, that i had to make some mechanism, that glext.h is included only when it is there.
it went to and fro and finally it seemed to work everywhere. the current working version seems to be in vertex_array rather than HEAD (i jsut browsed the CVS on sourceforge via the webinterface as my dev-machine is currently in an exhibition)
...from GemBase.h:
#ifdef __APPLE__ #include <OpenGL/gl.h> #include <OpenGL/glext.h> #else #include "config.h" #include <GL/gl.h> # ifdef INCLUDE_GLEXT # include <GL/glext.h> # endif #endif // __APPLE__
...this says that if you aren't osx, go ahead and include gl.h, but then only include glext.h if this other thing is defined...maybe that's
a good thing for windows (?), but it seems like it's crippling some linux users: where is this INCLUDE_GLEXT defined in the configure process?
the snippet in revision 1.12.2.2 is:
<snip> #ifdef __APPLE__ # include <OpenGL/gl.h> # include <OpenGL/glext.h> #else # include "config.h" # define GL_GLEXT_LEGACY # include <GL/gl.h> # if defined INCLUDE_GLEXT || defined __linux__
// stupid hack, as nvidia has erroneous glext-headers! # define boolean GLboolean
# define GL_GLEXT_PROTOTYPES 1 # include <GL/glext.h>
# endif /* GLEXT */ #endif // __APPLE__ </snip>
(which seems weird too, now that i look at it)
anyhow, #include "config.h" should be _before_ the OS-specific defines (and thus be included for __APPLE__ too!)
mfg.ase.r IOhannes
zmoelnig@iem.at wrote:
(which seems weird too, now that i look at it)
ok, i hope i have made it a bit cleaner (with DONT_INCLUDE_GLEXT) which is defined (or not) in configNT.h, so only OSs that might not have glext have to bother whether they want to include it.
and the glu-headers are included too, so now everything should work (tested a fesh check-out of HEAD on linux and it works, with all GL-headers i have access too, and also with excluding glext)
mfg.a.sdr IOhannes