[Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

Wed Nov 18 10:00:44 PST 2015

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.

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.

On the swig-as-a-service front, I think the idea is interesting but there
are several practical holes with that:

* 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.)

* 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.

* Security 2: what is the service really running?  Not obvious on the build
machine accessing the service.

> 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.

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.

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.

> 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.

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.

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.

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)?

On Wed, Nov 18, 2015 at 1:24 AM, Pavel Labath <labath at google.com> wrote:

> On 18 November 2015 at 09:02, Zachary Turner via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> > On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala <todd.fiala at gmail.com> wrote:
> >>
> >> 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.
> >>
> >> Honestly, though, I haven't spent much time on that.
> >>
> >> 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.
> >
> > 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.
> >
> > Here's our current configuration matrix.
> >
> > Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)
> > Build Systems: CMake, Xcode
> > SWIG version: 1.3x, latest
> > Python version: None, 2.7, 3.x (in progress)
> > SWIG Binding Generation: on-the-fly, static (proposed)
> >
> > 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?
>
> +1
>

-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151118/43136815/attachment-0001.html>