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

[Daniel Espinosa <esodan gmail com>]

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.

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