Thanks for following up with this, Stefan. I'll apply the patch to the git version, check things out here and announce when I've pushed to the git repository at sf.net for more general testing and after to a developers release of OpenGL.
Assuming things go well at that point a new official release of OpenGL will follow. --Chris Stefan Evert wrote: > Hi everybody! > > I just wanted to summarise the current state of the discussion. I > think I exchanged a few mails with Chris that didn't make it to the > list, and we were a bit out of sync at times. > >> Yes, this sort of thing is one reason I had not expected POGL >> to work on Mac OS X initially. As with most ports of OpenGL, >> the key is working out the correct set of include, compile, and >> link lines. Once those are sorted out, say starting with the >> glversion compile, then the same setting should work to build >> the module bindings to OpenGL. > >> As far as I know (a non-Mac user/owner), Xcode is the default >> development environment for Mac OS X. My understanding is that >> they have hooks in the compiler to look in the right places >> for things. If you just use <GLUT/glut.h> and <OpenGL/gl.h>... >> can you get glversion.c to compile? > > > glversion builds fine if we use the appropriate include directives for > the Apple frameworks, in this case > > #include <GLUT/glut.h> > > No special "-I" or "-F" flags are necessary, just link against system > frameworks with "-framework". Nice. > > The only gripe with my current patch is that it uses > > #ifdef __APPLE__ > > to select which header to include, which assumes that the build always > uses Apple's OpenGL frameworks on a Mac and may collect incorrect > information if somebody tries to build with X11 OpenGL or FreeGLUT. > > > If I use similar patches for the main code of the OpenGL module (no "- > I" flags, conditional includes to get header files from Apple > frameworks), the build appears to work and passes all tests. However, > it turned out that -- presumably due to a typo -- the file "gl_util.h" > always includes its own internal copy of "gl.h" (probably taken from > Win32), while "glu.h" and "glut.h" are taken from the standard system > locations. > >>> PS: I'll send a patch for the messy version (GLU and GLUT from >>> frameworks, local gl.h header) off list. It compiles and passes all >>> tests on my machine, but I'm still worried about not using a system >>> header file! >> Does it work if you change the INCLUDE_LOCAL_HEADER so that it >> is true only for win32? I'm not afraid of trying things out >> via a developer's release to CPAN but it would be nice to check >> things out on a number of platforms first to prevent gratuitous >> breakage.... > > > Fixing this typo, so that on Macs we have > > #include <OpenGL/gl.h> > > breaks the compilation because "glext_procs.h" redefines many symbols > that are already in Apple's "gl.h" (plus some other redefinitions in > other files). > > > In short, we can now build on Mac OS X without X11 installed (I tested > this by temporarily making the X11 includes inaccessible), but only if > we use an _incorrect_ internal copy of "gl.h" instead of the one from > Apple's OpenGL framework. > > Chris suggestion, to which I agree wholeheartedly, is: > >> Definitely patience. The key is not to mix incompatible sets of >> includes. For example, glext_procs.h looks like it is a combination >> of glext.h and glprocs.h but I'm not sure what is what. > >> Now that that is basically working, I would like to revisit the >> build process for OpenGL bindings. Along with that would come >> continuing code cleanup as problems or potential problems are >> discovered. > > So, if Chris accepts my patch, we _do_ have a working OpenGL module on > Macs that does no longer depend on X11 headers and passes tests (at > least on my system). We'd like to revisit the build process and make > sure that correct headers are used (to avoid potential > incompatibilities that may bite us in the future), but this won't be > trivial and should be done with patience -- as long as the current > version works for everyone, we're in no particular hurry. > > > All the best, > Stefan _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
