Planet SoC

Hmmm, this blog hasn’t been used so far as I intended. Time to recommit to writing in this now that I am back from my wonderful birthday trip!
I suppose my first milestone can be considered “mostly there”. Doxygen comments DO happily reside in the parse tree, but the Java module’s means of generating the proxy file isn’t simple in the least- and it seems like in order to place all of the “raw” doxygen blobs into the java file I would have to make a lot of effort in several places only to have to change it once I finish the Doxygen->Target Language convertor. I am thinking that I will need to write a method that combs through the finished proxy file and inserts the comments in the proper place rather than attempt to inject them in the right place to begin with. On the nice side, I also experimented with adding Doxygen Comments as a seperate node into the parse tree with success (I think they are better suited to be a feature of another entity, though)- but at least I also have that option open to me. Even though side-comments are going to prove to be annoying and difficult, I’m going to have to find a way to deal with them, since they are fairly ubiquitous. It was a very slow start, but I finally feel like I’m over the understanding barrier and that i really “get” the SWIG process (or at least the parts I need to ;) ). So morale is high in the SWIG bunker.

I have been spending my more recent time writing a hand-parser for doxygen blurbs, such as:
//! A normal member taking two arguments and returning an integer value.
/*!
\param a an integer argument.
\param s a constant character pointer.
\return The test results
\sa Test(), ~Test(), testMeToo() and publicVar()
*/
Even though it is tedious, I feel like it will benefit me in the end (and even if I wasn’t writing it myself the task would be just as tedious, simply because Doxygen has a wealth of commands http://www.stack.nl/~dimitri/doxygen/commands.html, most of which will need to be dealt with case by case ) The parsing builds a data structure consisting of all the possible entities (brief description, long description, various commands) that can be found in a Doxygen blob and the pieces they come as. IE one node may contain a command- “param”, a name-“x”, and a description for x. This might be a little clunky, but I feel like it is an intuitive design that will lend itself more easily to being extended to more documentation languages. Furthermore depending on how I implement side-comments (Such as x //the variable) inserting into this node structure isn’t difficult at all- and it lends itself to being able to be sorted by type (JavaDoc, for example, has a specified order for all tags) JavaDoc (as I had stated earlier, my first goal) also has a very small set of tags compared to Doxygen’s 100ish commands…