<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 10:24 AM, 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 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,</div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>We do have the ability to post-process this any way we want after the swig generation.  I see no reason why we couldn't get move advanced with what we post-process, especially since that can be limited to the maintainer-mode-style "update the static checked-in product after generating the bindings" step).</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 class="gmail_extra"><div class="gmail_quote"><span class=""><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> 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></span><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><span class=""><div> </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"><span><div></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><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>* Clean up the swig generation scripts</div><div><br></div><div>These look to have been implemented as direct ports of the older OS X style bash scripts.  This Python script is very much the essence of using the paradigms of one language in another, and being the worse for it.  It implements features that are already present in the standard Python lib, and is more verbose than it needs to be.</div></div></blockquote></span><div>Ugh, +1000.  Every time I have to crack these files open my head explodes.  More than happy to help with whatever porting is necessary.</div><span><div> </div></span></div></div></blockquote><div><br></div></span><div>Haha that's exactly how I feel :-)</div><span class=""><div> </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"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Also, it is likely the script needs to be broken out into a few parts.  The scripts don't just generate the python binding using swig, they also setup (for OS X) some packaging and other bits.  Right now none of that is clearly broken out.  When we move to an explicit binding generation mode, this does need to be broken out better.</div><div><br></div><div><br></div><div>* Get OS X Xcode build using the same bindings machinery as others.</div></div></blockquote></span><div>Yay.</div><div><br></div></div></div>
</blockquote></span></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></div>