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

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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]