I've filed bug #668205 to track advances on documentation about GIR generation.
2012/1/17 Vivien Malerba <[email protected]> > > > On 13 January 2012 17:53, Daniel Espinosa <[email protected]> wrote: > >> >> >> 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. > > > 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 > > -- 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
