On 13 January 2012 17:53, Daniel Espinosa wrote:
>
>
> 2012/1/13 Vivien Malerba
>
>>
>>
>> On 13 January 2012 00:51, Daniel Espinosa 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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
