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
