<div dir="ltr">> <span style="font-size:13px">On OS X, it is a pain to get unless you install homebrew/macports/fink. On Linux, you'll need to do an apt-get or yum install.</span><div><br></div><div>And I should add that installing home-brew (the most common way of picking up extra goodies, as I know I do it on home machines) is also one of the most common ways to prevent lldb from building correctly and usably on OS X. (Particularly with the way its introduction of an alternative python and its placement on the lookup path will totally bork a system or hand-built lldb).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 18, 2015 at 10:00 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">Checking in the static bindings is no different than projects checking in autoconf config baked scripts so that the vast majority of people don't need to run autoconf just to get a setup that rarely changes. There is precedent for this going back a long way on open source projects.<div><br></div><div>I'm backing off having anyone else use them if they don't want, and we (Apple) will keep those up to date. Nobody else will use them. Totally fine.</div><div><br></div><div>On the swig-as-a-service front, I think the idea is interesting but there are several practical holes with that:</div><div><br></div><div>* What does one do when the server is unavailable? Needs to be a local-only backup. So whatever service that provides isn't a guaranteed working solution (think on an airplane, network outage, other server outage, etc.)</div><div><br></div><div>* Security: building code that has other code injected in it by another server. Safe? Attack vector? I could argue so is a git/svn repo susceptible to this, so maybe this isn't a huge deal, but it's big enough and smells enough like "introduce random unvetted code that can't be reviewed as easily as a VCS tag" that I doubt we would ever use this in practice.</div><div><br></div><div>* Security 2: what is the service really running? Not obvious on the build machine accessing the service.</div><span class=""><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. </div><div><br></div></span><div>I'm going to call that overreaching. We are not in the business of dictating that one of the developers of the code "should not do something unless there is a hard requirement." Apple wants to eliminate the need for people to *require* swig. The goal there is reducing the build requirements for the average person building lldb, not growing it.</div><div><br></div><div>Saying that "you hit a server for bindings as part of the build" is way different and more onerous than saying "hey we don't want you to *require* to have swig to build lldb." Those are miles apart.</div><span class=""><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></span><div>Swig is not a component that comes pre-installed on most public systems. Almost nobody has it unless something they do says "you need to have this." So for a casual developer who is not a hardcore lldb developer, on a new system/VM, they are not going to just have swig. On OS X, it is a pain to get unless you install homebrew/macports/fink. On Linux, you'll need to do an apt-get or yum install.</div><div><br></div><div>So I would flip that question around and say "who has swig unless something requires it?" And I'm creating a way to not require it. That sounds a lot more like a reduction in requirements for most build scenarios and most people who would download and build lldb.</div><div><br></div><div>So for the more common, casual lldb build environment where the developer is not touching SB API, help me understand how reducing the need for swig (without introducing the need for hitting another server) is increasing the requirement load? (Especially if we --- our local dev group sitting by me --- maintains those static bindings)?</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Nov 18, 2015 at 1:24 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 November 2015 at 09:02, Zachary Turner via lldb-dev<br>
<div><div><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>> wrote:<br>
>><br>
>> Nothing concrete at the moment; however, it could be interesting to look<br>
>> at the clang community and see what could be done for llvm-based language<br>
>> implementations. The angle that I think would be interesting would be if we<br>
>> can generate bindings more effectively based on the in-depth understanding<br>
>> of the language that is afforded by languages built on top of LLVM. This is<br>
>> probably less interesting for Python (particularly since we have a<br>
>> functioning solution) and more interesting for languages built on LLVM or<br>
>> clang.<br>
>><br>
>> Honestly, though, I haven't spent much time on that.<br>
>><br>
>> For the time being, I am going to not change the path for everyone on<br>
>> swig, and only use a static binding if swig cannot be found. This will be<br>
>> minimal impact for everyone and doesn't interfere with anyone using a<br>
>> specific version of swig. We can revisit larger questions about<br>
>> who/what/when on static bindings after we gain some experience with enabling<br>
>> them for those who don't have swig. We can review and adjust based on our<br>
>> collective experience. The two files this seems like it will be are the<br>
>> LLDBWrapPython.cpp and the lldb.py file that comes out of python. I hope to<br>
>> have this working in the next day or so.<br>
><br>
> To try this another way, I really would like to voice my opinion very very<br>
> strongly for moving away from having different ways of doing things for<br>
> different platforms / build configurations / etc unless it is *required* to<br>
> support a hard requirement of someone's environment.<br>
><br>
> Here's our current configuration matrix.<br>
><br>
> Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)<br>
> Build Systems: CMake, Xcode<br>
> SWIG version: 1.3x, latest<br>
> Python version: None, 2.7, 3.x (in progress)<br>
> SWIG Binding Generation: on-the-fly, static (proposed)<br>
><br>
> In all of these cases (except the proposed), the matrix choices are<br>
> justifiable because they are there to support a hard requirement of<br>
> someone's environment, and I do not think we should grow for anything that<br>
> is not also a hard requirement of someone's environment. We definitely<br>
> should not grow it out of convenience, and *especially* not if it's only a<br>
> minor convenience. So I still am looking for a clear answer regarding what<br>
> problem this is solving. Is not having a swig binary on every machine a<br>
> hard requirement?<br>
<br>
</div></div>+1<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>