Some times ago I noticed that the Tao website was revamped under Rob care to a new Drupal-based plateform which is actually cleaner and more « professional » than the plain Mediawiki-based wiki.

This lead me to the news of the Tao 2.0 RC2 release that I « quickly » downloaded. « Quickly » because even in the tar.gz package, which is supposed to be more for UNIX folks, Tao devs put every Win32 DLLs dependencies that they could find for Tao and moreover in two different places (14 Mo for nothing) ! (They were also OSX deps).

But well I’m not writing this post to complain on Tao strange relationship with dependencies . Instead I want to point out several problems of Tao under Linux. As you (should) know Tao is P/Invoke wrapper around several multimedia-related libraries like OpenGL, OpenAL, GLFW, SDL etc… . It’s notorious that under Linux there has been always some problems. mine were almost always related to double-freed pointers or corrupted memory. Moreover there are always been some inconsistency in method prototype (bad parameter type generally). In fact only the Tao.OpenGL wrapper is generated automatically via a spec parser, that’s fine because OpenGL is a standard and under the governance of big companies (ATI, NVidia …) that’s why stuff are well done and why there is such thing as a spec file describing every function, enum, typedef and even vendor-specific extensions. But other projects don’t have the time, resources, or just the will to do such a thing. That’s why I had the idea to create a P/Invoke generator that would take a .h file and produce the corresponding P/Invoke .cs file. There is already a tool which do things like this : Swing but the problem is that it force to create c wrappers whereas the P/Invoke system is precisely designed to avoid such things.

Since I didn’t want to create a full-featured C parser in C# I had three possibilities :

• Use some well crafted and illegible Regex to fetch function prototype and struct scheme. The main problem is that they are complicated stuff to look for, like typedef and #define directives.
• Use the same process that before but on a preprocessed source file thus eliminating some difficulties. Problem : the typedef case stays the same.
• Use a dedicated compiler which produce something readable instead of machine code. Fortunately there is a tool out there which do just that : GCC-XML. GCC-XML is a full featured gcc compiler that output XML representing the internal of GCC during the compilation (the GIMPLE tree I think). Personal problem : even if I can use the big facilities of the .NET framework regarding XML support, the output of GCC-XML is still, hum, barely readable for a limited human being like me . But since the common good is more important I decided to go with this solution .

If you are curious here is a sample code that I use like a test for the parser, and here is the result returned by GCC-XML (without options). As you can see there are all possible informations in the XML file like the length of the structure, the alignment, the offset …

I have started to write the XML parser right now so let’s see if the result will be convincing. Stay tuned .