<div dir="ltr">For the benefit of continuity in conversation, here is what you had to say about it before:<div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">> 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>

> 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.  [bits deleted]

> 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.</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">I'd like feedback from others on this.  Is this something we want to consider doing?</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">From my perspective, this seems reasonable to look into doing if we:</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">(a) have the service code available, and</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">(b) if we so choose, we can readily have the script hit another server (so that a consumer can have the entire setup on an internal network), and</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">(c: option 1) be able to fall back to generate with swig locally as we do now in the event that we can't hit the server</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">(c: option 2) <span style="font-family:arial,sans-serif">rather than fall back to swig generation, use swig generation as primary (as it is now) but, if a swig is not found, then do the get-bindings-as-a-service flow.</span></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">This does open up multiple ways to do something, but I think we need to avoid a failure mode that says "Oops, you can't hit the network.  Sorry, no lldb build for you."</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Reasoning:</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">For (a): just so we all know what we're using.</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">For (b): I can envision production build flows that will not want to be hitting a third-party server.  We shouldn't require that. </pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">For (c): we don't want to prevent building in scenarios that can't hit a network during the build.</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">-Todd</pre></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Zachary,<div><br></div><div><div>I think the time pressure has gotten the better of me, so I want to apologize for getting snippy about the static bindings of late.  I am confident we will get to a good solution for removing that dependency, but I can certainly wait for a solution (using an alternate approach in our branch) until we arrive at something more palatable to everyone.</div><div><br></div><div>Regarding the bindings as service idea:</div></div><div><br></div><div>How quickly do you think you could flesh out the bindings as a service idea?  With a relatively strong dislike for the static approach I'm taking, I can back off that and just use my current code here in a downstream branch for now.  Ultimately I want to remove the requirement for swig, but I can probably achieve that without doing it in upstream if we're going to have some solution there at some point ideally sooner than later.</div><div><br></div><div>Also - I think you were going to send me a swig 3.x binding to try out (I'd need the LLDBWrapPythoh.cpp and the lldb.py, and you'd just need to let me know if it still needs to be post-processed or it would need to be done).  Can we shoot for trying that out maybe tomorrow?</div><div><br></div></div></blockquote><div><br></div></span><div>Hey I got these, Zachary.  They just didn't go in my inbox.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><div>-- <br></div><div><div><div dir="ltr">-Todd</div></div>
</div></font></span></font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>