<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 17, 2015 at 8:03 PM 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">Nothing concrete at the moment; however, it could be interesting to look at the clang community and see what could be done for llvm-based language implementations.  The angle that I think would be interesting would be if we can generate bindings more effectively based on the in-depth understanding of the language that is afforded by languages built on top of LLVM.  This is probably less interesting for Python (particularly since we have a functioning solution) and more interesting for languages built on LLVM or clang.<div><br></div><div>Honestly, though, I haven't spent much time on that.</div><div><br></div><div>For the time being, I am going to not change the path for everyone on swig, and only use a static binding if swig cannot be found.  This will be minimal impact for everyone and doesn't interfere with anyone using a specific version of swig.  We can revisit larger questions about who/what/when on static bindings after we gain some experience with enabling them for those who don't have swig.  We can review and adjust based on our collective experience.  The two files this seems like it will be are the LLDBWrapPython.cpp and the lldb.py file that comes out of python.  I hope to have this working in the next day or so.</div></div></blockquote><div>To try this another way, I really would like to voice my opinion very very strongly for moving away from having different ways of doing things for different platforms / build configurations / etc unless it is *required* to support a hard requirement of someone's environment.</div><div><br></div><div>Here's our current configuration matrix.</div><div><br></div><div>Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)</div><div>Build Systems: CMake, Xcode</div><div>SWIG version: 1.3x, latest</div><div>Python version: None, 2.7, 3.x (in progress)</div><div>SWIG Binding Generation: on-the-fly, static (proposed)</div><div><br></div><div>In all of these cases (except the proposed), the matrix choices are justifiable because they are there to support a hard requirement of someone's environment, and I do not think we should grow for anything that is not also a hard requirement of someone's environment.  We definitely should not grow it out of convenience, and *especially* not if it's only a minor convenience.  So I still am looking for a clear answer regarding what problem this is solving.  Is not having a swig binary on every machine a hard requirement?  You said</div><div><br></div><div>> We can revisit larger questions about who/what/when on static bindings after we gain some experience with enabling them <b>for those who don't have swig</b>"</div><div><br></div><div>And my question is, who doesn't have swig?  Maybe there is a legitimate use case, I just want to understand what that is before we add more different ways of building.</div><div><br></div><div>I mentioned earlier that one way there would be a definite tangible benefit is if we could use these static bindings in conjunction with a swig bot that would automatically generate swig on a remote server and send you back the result.  This way we could remove one item from the configuration matrix, which I think we all agree is a good thing based on the fact that the original idea was to get everyone on 1.3x (which isn't possible since it doesn't work well with Python 3.5).  Compare:</div><div><br></div><div><div>Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)</div><div>Build Systems: CMake, Xcode</div><div>SWIG version: 1.3x, latest</div><div>Python version: None, 2.7, 3.x (in progress)</div><div>SWIG Binding Generation: on-the-fly, static</div></div><div><br></div><div>with</div><div><br></div><div><div>Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)</div><div>Build Systems: CMake, Xcode</div><div>Python version: None, 2.7, 3.x (in progress)<br></div><div><br></div></div><div>The latter is much better, right?  Can we discuss whether this swig server is a viable solution for getting to a single system that works for everyone?  Again, I'm willing to do the brunt of the work getting it up and running if it is (I can probably reuse the portion of work you've already done related to running swig on the input files)</div><div><br></div><div>If the goal is just some kind of cleanup where it would be nice to not have to install swig, I'm specifically arguing against that, because I don't think that's a strong enough case to add one item to the configuration matrix.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">
</div></blockquote></div></div>