<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 13, 2015 at 10:24 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"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.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"><div class="gmail_quote"><span><div dir="ltr">On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</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">Hi all,<div><br></div><div>I'd like to do a few things with our swig generation and handling:</div><div><br></div><div>* Create a maintainer-mode style setup where the swig Python bindings are generated and checked into the repo (I'll call it the static python binding).</div><div><br></div><div>This will be used by default, removing the need for most people and all builders/bots from having swig on their system just for lldb.  In the event that Windows needs a different version (e.g. for, say, Python 3.5 support that is incompatible with the swig-1.3.40-generated bindings), we can support multiple source bindings, or we can post process the swig-1.3.x generated bindings.  We'll keep them by swig-{swig-major}-{swig-minor}.  Internally over at Apple, we will stick with the swig-1.x bindings.  I don't think we will care about the dot release (1.3.40 vs. 1.3.39, for example).  We'll just make sure to use the latest for a {swig-major}.{swig-minor}.  As always, SB API changes generated by swig need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of generating usable Python wrappers).</div></div></blockquote></span><div>I know you said you plan to stay on 1.x, but in this world of having SWIG bindings checked in, does that open the door to potentially moving beyond SWIG 1.x for the upstream?  I feel like the SWIG 1.x requirement holds the upstream back, because there are a lot of hacks to workaround bugs and limitations in SWIG, and it only understands the absolute most basic C / C++ language constructs.  So we end up being limited in how we can design SB APIs, all for reasons that having nothing to do with the upstream project requirements, which is kind of a bummer.  It seems like there could be a path here for the upstream to move forward, and anyone who is forced to stay on an earlier version of SWIG could maintain whatever changes are necessary to make this possible in a local repository.</div><span><div><br></div></span></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I may leave Greg to discuss that aspect (w/r/t using newer features).  The SB API itself is intended to be a very bare-bones linkage environment that does not break linkage requirements in ways that typical C++ binary libraries do (i.e. it does not use virtuals and follows a number of rules about data members so that it remains binary compatible across compiler/linker changes).</div></div></div></div></blockquote><div><br></div><div>There's a couple of examples that come to mind.  C++11 is completely out, for example.  In general this isn't a huge deal.  Nobody's going to be passing rvalue references through the SB API or anything.  But even simple things like enum classes are out.  1.x also doesn't support specifying the underlying type of an enum, because it can't parse it.  In other words, SWIG won't accept this:</div><div><br></div><div>enum Foo : unsigned {</div><div>};</div><div><br></div><div>This is actually important in MSVC because its algorithm for choosing the underlying type and size of the enum differs from other compilers.  We've got hundreds of warnings silenced in CMake because of this, and there's no solution except upgrade SWIG.</div><div><br></div><div>We're also forced to use the archaic "const char* str, int len" syntax for every single string, when we could be passing std strings or llvm StringRefs.  </div><div><br></div><div>No nested classes, namespace support doesn't work, and also missing out on a ton of bugfixes and performance improvements of generated code.  Many languages like Go aren't supported in 1.x, etc.  If I check the release notes I could probably come up with more examples.</div><div><br></div><div>I don't mean to say that we have to do this with haste or anything, but I think at some point there should probably be a path off of 1.x for the upstream</div></div></div>