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.&nbsp; Part of its service is to know that it should build a .bundle on Mac OS X and a .so on Linux.&nbsp; 
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>&nbsp;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.&nbsp; 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.&nbsp; 
E.g., OpenGL has glVertex2d, glVertex2f, glVertex3i, etc.&nbsp; The difference amongst them is simply the type and number of the parameters (two doubles, two floats, three ints).&nbsp; 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.&nbsp; This value added service is what gl_untyped.i provides.&nbsp; So the ruby code &quot;glVertex( 0, 0, 0 )&quot; gets mapped, eventually, to the OpenGL call &quot;glVertex3d(
0.0, 0.0, 0.0)&quot;.&nbsp; The SWIG wrappers still retain all of the type-specific calls, so you could *also* do this in your ruby code &quot;glVertex3d( 0.0, 0.0, 0.0 )&quot;.<br><br>B: SWIG does not natively handle registering callbacks from C back into your ruby code.&nbsp; The GLUT library allows the developer to register functions for display, keyboard, reshape, etc.&nbsp; 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.&nbsp; Take a look at the ruby &quot;tests&quot; for how this works.
<br><br>C: There are some cantankerous functions that just need a little help for one reason or another.&nbsp; 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.&nbsp; Much of what is in the *.i files comes from the previous ruby-opengl, with tweaks to get it to work with SWIG.&nbsp; 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.&nbsp; 
<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.&nbsp; Everything is a copy (a very efficient copy...).&nbsp; All main line work is done on the trunk, and typically, you could just check out the trunk and be fine.&nbsp; If you need to make a tag, you'd do an svn copy of the trunk over to, 
e.g., tags/Release_1.&nbsp; Read the subversion documentation for more insight <a href="http://svnbook.red-bean.com/">http://svnbook.red-bean.com/</a>.&nbsp; <br></div></div><br>-- <br>Peter McLain<br><a href="mailto:peter.mclain@gmail.com">
peter.mclain@gmail.com</a>