Re: [gnome-db] GDA as Gee.Collection Reched Milestone 1

[Vivien Malerba <vmalerba gmail com>]

On 13 January 2012 17:53, Daniel Espinosa <esodan gmail com> wrote:

2012/1/13 Vivien Malerba <vmalerba gmail com>

On 13 January 2012 00:51, Daniel Espinosa <esodan gmail com> wrote:

Here is what I propose to you:

• remove the generated files from git
  

• add to git the "reference" of these files along with a test script (sh, python, perl, ...) which can then compare (or other) the generated files with the expected "reference" files to enable you to detect any problem.

The advantage of having a script to detect problems is that it can be documented (in its header for example) and run by anybody who thinks there is a problem.

for example copy Gda-5.0.gir to libgda/gir ? And then a script to check diffs?

Yes, for example create a libgda/girtest to store the expected GIR file (managed using git), let the build mechanism create the GIR file in libgda/, and then have a script in libgda/girtest (also managed by git) which compares (or does other tests) the two GIR files after compilation (maybe executed when "make check" is run).

This could be Ok if you always know the file format and what contents might be in. GIR format is undocumented and in GDA depends on API additions or minor improvements.

One of the "aditional goals" of GObject Introspectio is API verification, I would like to try on GDA and get a first hit. I filed bug 667837 to notify API break in GDA-5.0.gir generated by GI master, the problem comes when check Vala extensions and fails to find a function on Gda.DataProxy.

As explained on GI website, we could hold GIR versions for each release, not each time we compile, because the resulting GIR could include API breaks that must be fixed before release. To deal with bug 667837, I can make use on Vala of custom code or metadata, but on Python or _javascript_, witch depends directly on GIR, I can't do that.

Another is to autogenerate GIR files but not install them. Instead we can send a patch to Vala or fix our code to make sure we will get not API break but API additions and improvements. When a new release is ready, we can check for API breaks by manually or include Unit Tests cases for the whole API in Python.

Ok, I see it's a bit more complicated than I had anticipated. Then I'll let you do what you think is the best.

However please add some doc (even as a README.GIR file for example) to tell how and when GIR files are generated, checked, updated, validated, whatever, so that other developers can understand what's going on.

Thanks,

Vivien