Hi,<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have a few question about the source (rev. 4) :<br>- how does mkmf manage to know that we have to build a shared library
<br>(i.e. the bundle for the moment) ?</blockquote><div><br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- why are there glut_*.i ? is it because those functions are to
<br>specific for having SWIG to handle them automatically ?</blockquote><div><br> There are a couple of reasons the SWIG files contain hand-coded functions.<br><br>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 )".<br><br>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.
<br><br>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.
<br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- what's the purpose of the 'branches' and 'tags' subdirectories ?</blockquote>
<div><br>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 <a href="http://svnbook.red-bean.com/">http://svnbook.red-bean.com/</a>. <br></div></div><br>-- <br>Peter McLain<br><a href="mailto:peter.mclain@gmail.com">
peter.mclain@gmail.com</a>