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

[Daniel Espinosa <esodan gmail com>]

I've filed bug #668205 to track advances on documentation about GIR
generation.

2012/1/17 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


-- 
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)