Perl OpenGL 0.56

Bob Free bfree at graphcomp.com
Wed Oct 31 15:52:27 UTC 2007


> Now that I've looked into it, the build system makes it a bit difficult
> to build a distribution-wide binary package. The code in Makefile.PL
> tries to ask the local X server for the GL extension it supports.

I had added this to support older systems with header files that included 
APIs not supported by the user's installed card - which caused run-time 
segfaults.  I can add a build flag that skips glversion tests and forces the 
use of local header files.


> Even if it did, we don't want the list of supported GL extensions to be
> based on the X server of the user building the package; that might be on
> another host with another operating system / version entirely.

Note: by using GL header files from your build machine, you will be tying 
the binary to the OpenGL version and extensions supported by the header 
files your build machine (Mesa's, for Debian).  This was an issue with 0.54.

I'm not advocating Microsoft's approach here (I prefer OpenGL performance on 
Linux), but Windows got around this issue by forcing developers to use their 
WGL interface, which dynamically loads GL entrypoints at runtime.

The closest thing to that on Linux is Mesa - however, Mesa's GL header file 
only supports up to OpenGL 1.3, and lacks support for most of the extensions 
supported by Perl OpenGL.  If users installs a recent (eg. 1yr old) GPU, 
they won't be able to use all the features on that card, including common 
features such as Frame Buffer Objects (FBOs).

I'm still trying to figure out a portable way to address this issue.  The 
only short-term solution I can think of is to limit the opengl-perl package 
to Mesa support (which provides _some_ hardware support) - and let users do 
source builds if they want the latest GPU features.  The long term solution 
would be to create a shared lib that abstracts support for OpenGL extensions 
like Windows' WGL.  Thoughts?


> I see that when GLUT is not installed, there's a fallback for building
> without -DHAVE_VER. It would be nice to have an option to disable this
> part even when GLUT is installed. For now, I have patched Makefile.PL
> for this.

Send me your patch - I'll include it in the next release.


> We also want to build with the system GL headers, not the ones distributed
> with the OpenGL-0.56 tarball. This is pretty much working when building
> without -DHAVE_VER; the only problem I have found is in glut_util.h,
> which unconditionally includes "./include/GL/glut.h". This should probably
> look at HAVE_VER too.

See my comments on system headers above.  I'll look into fixing the 
glut_util.h issue.

Regarding glut.h, I have been considering switching from GLUT to FreeGLUT.


> Details can be found in Debian bug #368560:
> http://bugs.debian.org/368560

Thanks!  With ARB's updated releases of OpenGL 3.0, there may now be 
unrestricted GL header files available (which are necessary to dynamically 
load extensions).  I will keep you posted on this.


> Is there any chance that you could distribute a tarball without these
> header files? They weren't present in 0.54.

I had originally provided the GL headers as a separate download - I could go 
back to that approach for future releases.


> Since they are separated upstream, it makes sense to provide them in
> separate Debian packages too. I'll file an ITP (Intent To Package)
> on libopengl-image-perl and libopengl-shader-perl soon and prepare the
> packages (unless somebody else beats me to it.)

Excellent.  These don't have the system dependencies like the main module.

Note: OpenGL::Image works best when ImageMagick 6.3.5 is installed.  I 
believe the latest ImageMagick Debian package is 6.2.x


> One more thing: in case you'd like to receive Debian bug reports and
> notifications of updates to the package, you can subscribe to the package
> information at <http://packages.qa.debian.org/libopengl-perl>. Of course,
> we will forward any bug reports not related to the Debian packaging
> itself in any case.

Thanks! - and thanks for your excellent feedback/suggestions - I really 
appreciate anything that helps make Perl OpenGL more useful/available to 
developers/users.

- Bob




More information about the pkg-perl-maintainers mailing list