<div dir="ltr">Moving this back over to the list since I'm sure others have some input here.  Also +lldb-dev since it has more visibility than lldb-commits.<div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.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"><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" target="_blank">todd.fiala@gmail.com</a>> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_quote"><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></div><div dir="ltr"><div class="gmail_quote"><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></blockquote><div> </div><div>One possibility (which I mentioned to you offline, but I'll put it here for others to see) is that we make a swig bot which is hosted in the cloud much like our public build bots.  We provide a Python script that can be run on your machine, which sends requests over to the swig bot to run swig and send back the results.  Availability of the service would be governed by the SLA of Google Compute Engine, viewable here: <a href="https://cloud.google.com/compute/sla?hl=en">https://cloud.google.com/compute/sla?hl=en</a></div><div><br></div><div>If we do something like this, it would allow us to raise the SWIG version in the upstream, and at that point I can see some benefit in checking the bindings in.  Short of that, I still dont' see the value proposition in checking bindings in to the repo.  So far all I've heard is that it is so that we don't need swig to be on everyone's machines, but I also don't see the value proposition in that either, given that we already require many other tools on peoples' machines.</div><div><br></div><div>If it means we can get off of SWIG 1.x in the upstream, I will do the work to make remote swig generation service and get it up and running.  From the user's perspective, it's already identical to what you're proposing.  No swig executable on your machine (or anyone's machine for that matter), and you run a simple script to generate bindings and check them in whenever you make changes.</div></div></div></div>