2012/1/13 Vivien Malerba <[email protected]> > > > On 13 January 2012 00:51, Daniel Espinosa <[email protected]> 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. -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)
_______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
