GIR for java-gnome: update week 34
The Google Summer of Code is ending in a month and it is time to make things stable, to do some polishing and to write documentation.
The goal of the week 34 was to improve some parts of the code that I have done so far to make them less cumbersome and more maintainable. I have started with a couple of code cleanup and by adding some comments where they were needed. After that I have worked on a piece of code that bothered me for some time now : guessing the C type to give to the code generator based for a return value or parameter. You may remember the ugly method that I have written about 3 weeks ago. It is now removed to be replaced by two methods which do the work in a better way starting from this commit. The idea behind these two methods is: taking an XML element (a return-value or a parameter element) and scanning it to find a type and the modifiers applied to it (const for example) and then generate a string that our code generator can understand (const-GList-GtkWindow* for example). This code is still depending on an hard-coded list of modules that we handle. I need to modify this to make it dynamic and retrieve modules' C identifier prefixes with the c:identifier-prefixes attribute of a namespace element.
The second part of the week has been used to write test cases to validate that the Introspection parser is working properly. It tests that we are creating Block elements properly and also that they contain the needed data to generate the code without any troubles. To make this possible I had to change the input of the IntrospectionParser to make it able to parse files but also strings.
Eventually, I have dedicated the end of the week to modify the output of the IntrospectionParser. Starting from this commit the parser now outputs a map of Block arrays which are identified by strings. I have made the following change to change the behavior of the code that override or add data thanks to the .defs files. This operation is now done right from the BindingGenerator class instead of doing the Block change inside the DefsFile class. I have made this choice because I believed that a DefsFile object should not be modified after being created. So now we have a code generator working like this:
Like a said last week, java-gnome using GIR data is now compiling and passing all the tests suite without any problems. There is still some code to improve to be able to remove some ugly hard coded things such as headers files to import (we probably need a keyword in the types.list file for example). For the end of this GSoC I plan to add the coverage of another library and to write a how-to for the interested (or future) java-gnome's hackers.