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

[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