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