[gdal-dev] SWIG bindings motions

Even Rouault even.rouault at mines-paris.org
Tue May 12 14:01:17 EDT 2009


Howard,

I have well understood that you suggest to refresh it always as part of the 
release process, so the following question only applies during development 
time.

If we keep the generated code in SVN for conveniency for buildbot, when are we 
supposed to refresh that generated code in SVN ?
- each time a .i is changed ? (This might not be sufficient, as changing 
some .h can also affect generated code, for enumerations for example)
- from time to time ?
- just before the release ?

My feeling is that if we don't refresh it regularly, the purpose of buildbot 
testing the "latest & greatest" is somehow defeated. I don't really know the 
difficulty of adding the swig generation as part of the buildbot tasks, but 
that would solve the above question.

Anyway, this is complementary to the mentions, for which I'm +1.

Le Tuesday 12 May 2009 17:39:31 Howard Butler, vous avez écrit :
> Dear SWIG bindings devs,
>
> I would like to propose the following motions for the upcoming 1.7
> GDAL release:
>
> 1) All swig bindings will be regenerated as part of the release process.
> 2) We will move up to SWIG 1.3.39 by for the release generation.
>
> As far as motion 1 is concerned, I would note that some of the
> generated code would need to stay in subversion because it is
> convenient and useful for things like the buildbot.  If we wanted to
> take things to the point of removing all of the generated code from
> subversion, I would be supportive of that, but it would take some
> infrastructure work.  We wouldn't have to remove the generated code
> from subversion as part of either of these motions, but I think we
> should remove the requirement of individual swig devs having to worry
> about updating bindings around release time (we already have removed
> this requirement for perl and .net, btw.  Now we would remove it for
> the others).
>
> Howard
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




More information about the gdal-dev mailing list