<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Breaking out the binding generation into a separate step will also be important for a couple reasons:<div><br></div><div>* (from before) I want to eliminate the requirement for the vast majority of the builds to have a swig on their system, and</div><div><br></div><div>* (not stated before) we'd like to move away from swig for binding generation at some point.</div><div><br></div><div>-Todd</div></div></blockquote><div><br></div><div>Unless these plans (i.e. moving away from swig) are imminent, I would prefer to keep the binding generation step automatic so people can use whatever swig version is installed on their system.  I know there are pros and cons to each, but at the end of the day, we need various bugfixes from newer versions of SWIG for the Python 3 stuff, and if someone decides they want bindings for Go, or Rust, or some other languages, they too might need a different minimum SWIG version.  We could start checking in multiple sets of generated bindings, but then we start having multiple maintainers, and the checked in bindings become out of sync with each other, and it's more trouble than it's worth.</div><div><br></div><div>We have buildbots building and testing the various configurations, so if someone uses something that is incompatible we shoudl catch it.  And just yesterday I added some options to the @expectedFailure and @skipIf decorators that allow you to skip tests based on the SWIG version and/or python version.</div><div><br></div><div>Letting people using the SWIG on their system is the easiest way to ensure that everyone's needs are still met while still getting early notification when someone does something incompatible, and it can be fixed.</div><div><br></div></div></div>