[ruby-opengl-devel] ruby-opengl: Initial check-in complete

peter mclain peter.mclain at gmail.com
Fri Aug 25 14:17:57 EDT 2006


Hi,

I have a few question about the source (rev. 4) :
> - how does mkmf manage to know that we have to build a shared library
> (i.e. the bundle for the moment) ?


mkmf is a ruby module that is specifically designed to create platform
specific Makefiles for building ruby extensions.  Part of its service is to
know that it should build a .bundle on Mac OS X and a .so on Linux.  I.e.,
we use it precisely because it knows to make a bundle on OSX.

- why are there glut_*.i ? is it because those functions are to
> specific for having SWIG to handle them automatically ?


 There are a couple of reasons the SWIG files contain hand-coded functions.

A: This project is a follow-on to the older ruby-opengl project from several
years ago.  The author of that project decided to add un-typed versions of
several of the OpenGL functions, since that was more in keeping with ruby
philosophy.  E.g., OpenGL has glVertex2d, glVertex2f, glVertex3i, etc.  The
difference amongst them is simply the type and number of the parameters (two
doubles, two floats, three ints).  So they added a glVertex function (no
trailing '2d' or '3i') that examines the number of arguments passed to it
and calls an appropriate version of the glVertexXX.  This value added
service is what gl_untyped.i provides.  So the ruby code "glVertex( 0, 0, 0
)" gets mapped, eventually, to the OpenGL call "glVertex3d(0.0, 0.0, 0.0)".
The SWIG wrappers still retain all of the type-specific calls, so you could
*also* do this in your ruby code "glVertex3d( 0.0, 0.0, 0.0 )".

B: SWIG does not natively handle registering callbacks from C back into your
ruby code.  The GLUT library allows the developer to register functions for
display, keyboard, reshape, etc.  The glut_callbacks.i file provides some
macros that manage the mechanism to track and define the callbacks and a way
that you can then define a Proc in ruby that can be used as the GLUT
callback.  Take a look at the ruby "tests" for how this works.

C: There are some cantankerous functions that just need a little help for
one reason or another.  E.g. glutInit wants to control argc/argv, so there
is a glut_init.i that passes ARGV into glutInit, which passes back a
possibly modified set of args.

This project is still in a very early stage, and our knowledge of SWIG is
not that mature yet, so I'm sure there is room for improvement etc.  Much of
what is in the *.i files comes from the previous ruby-opengl, with tweaks to
get it to work with SWIG.  The idea is to keep the *.i files OS/Arch
independent if possible, and let mkmf and the build process build
appropriate extensions for each OS/Arch.

- what's the purpose of the 'branches' and 'tags' subdirectories ?


I just created the standard subversion trio of top level directories.
Briefly, subversion doesn't have a native idea of tags and branches.
Everything is a copy (a very efficient copy...).  All main line work is done
on the trunk, and typically, you could just check out the trunk and be
fine.  If you need to make a tag, you'd do an svn copy of the trunk over to,
e.g., tags/Release_1.  Read the subversion documentation for more insight
http://svnbook.red-bean.com/.

-- 
Peter McLain
peter.mclain at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20060825/50e5df68/attachment.html 


More information about the ruby-opengl-devel mailing list