+1<br><br>I don't think we should keep any of the generated stuff just because of the buildbot. All of the builders should be capable to generate the bindings as part of the build steps. Only the path to the swig executable should be detected/specified. The Windows buildslaves are OK in this regard.<br>
<br>Best regards<br><br>Tamas<br><br><br><br><div class="gmail_quote">2009/5/12 Howard Butler <span dir="ltr"><<a href="mailto:hobu.inc@gmail.com">hobu.inc@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear SWIG bindings devs,<br>
<br>
I would like to propose the following motions for the upcoming 1.7 GDAL release:<br>
<br>
1) All swig bindings will be regenerated as part of the release process.<br>
2) We will move up to SWIG 1.3.39 by for the release generation.<br>
<br>
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).<br>
<br>
Howard<br>
<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br>