[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