Stefan Evert wrote: > > However, there are a few drawbacks: > > 1. Everything breaks down because of zillions of conflicting > definitions. Almost everything in "glext_procs.h" is also defined in > Apple's <OpenGL/gl.h> (but doesn't seem to be in the X11 <GL/gl.h> > header); a notable exception is the GLAPI macro. Also, various > functions like glUniformMatrix2x3fv() (from "gl_util.h") are also > defined in <OpenGL/gl.h>.
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. > 2. This only works as long as people use the standard Perl and GCC that > come with Mac OS X. Antonio said he'd built his own Perl, and there's a > chance he picked up a gcc installed with Fink, which won't automatically > include the system frameworks (I think). Good point. > I suspect that problem 1 can be fixed, but it will probably take some > patience and a few rounds of trial and error. I don't understand enough > about OpenGL to know where all these macros and functions should be > declared. 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. > When trying to track down the header files, I got very confused because > the Perl build seemed to be picking up a <GL/gl.h> that it shouldn't be > able to see. It turned out that ON EVERY PLATFORM EXCEPT WINDOWS, the > local file "include/GL/gl.h" is used instead of the system headers, by > the following code on lines 16 .. 21 of "gl_util.h": > >> /* Provide GL header files for Windows */ >> #define INCLUDE_LOCAL_HEADER !defined(HAVE_W32API) >> #if INCLUDE_LOCAL_HEADER >> #include "./include/GL/gl.h" >> #else >> #include <GL/gl.h> >> #endif > > I can't believe this is intentional, as it does the exact opposite of > what the comment says. The strange thing is that the module builds > correctly without X11 if we include <OpenGL/glu.h> and <GLUT/glut.h> > from the frameworks, but use local "include/GL/gl.h" instead of the > system header. But isn't that inviting disaster? Can you be sure that > this local header file is compatible with the actual OpenGL libraries? The intention is that the platform specific includes should generally be used since there is a fair amount of flexibility in the details of OpenGL implementations allowed to platforms. As a result, not all sets of includes are the same, *but*, a given set for a platform should work together. The goal of the latest POGL release was to improve the robustness of the build across platforms and to support the new PDL TriD graphics refactoring and thanks to testing by win32 and mac folks we were able to get a release of both PDL and POGL that mostly works. 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. > Rather confusedly, > Stefan > > > 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.... Thanks for the feedback and debugging, Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
