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

Wed Nov 18 10:34:10 PST 2015

On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala <todd.fiala at gmail.com> wrote:

> 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.
>
The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py
that you check into the repo.  You still have a chance to diff this source
code against the repository's copy before committing, same as you would if
you had swig locally.  Vast majority of changes to SB interfaces are going
to be the addition of a couple methods, or maybe a class, and the diff
should be very easy to look at and understand.

>
> > 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."
>
I'm not saying you shouldn't do *anything* if there's not a hard
requirement.  I agree that's overreaching.  I'm saying we should not
increase the number of ways of doing *the same thing* unless there is a
hard requirement.  Especially if one of the ways of doing the same thing
exists solely to save someone from running one command to install the
package (sorry if I'm not doing justice to how difficult it is on OSX, the
last time I did something on OSX it seemed fairly easy to install macports,
and I thought it's a wildly common thing for people to already have
installed).  For example, wouldn't people need to already have macports in
order to install CMake -- a necessary component of building LLVM?

>  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.
>
I agree, which is why it is so important to keep the number of different
ways of building to a minimum.  It's the same reason that the autoconf
build is being removed wholesale from LLVM and people have decided that
CMake is the one true way.  Because even if it isn't perfect for everyone,
it works for everyone.  And there is inherent simplicity in having fewer
ways to do things, as well as reducing maintenance cost.

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

Well, we would need to disable static bindings on the OSX buildbots for
starters, otherwise when someone not using static bindings makes a change,
the buildbots break, and we cannot leave buildbots in a broken state.  So I
assume that will still be possible.  So now you don't have a buildbot
testing the static binding configuration.

Secondly, LLDB already has a problem (IMHO) of having too many things that
only work for a few people, instead of having things that work for
everyone.  It's gotten better, and even your work right now to port the
Xcode build over to these new python scripts is helping to make that
better.  So regardless of the outcome here, the end result will still be an
improvement over before when Xcode build was using the shells cripts and
CMake build was using python scripts.

But I still think it's important to take a hardline against introducing new
build configurations.  Static vs on-the-fly bindings are going to need
different logic for getting the resulting code into the place where it can
be compiled / imported, different logic for creating the symlinks, etc.
And now we're duplicating effort when one person changes the logic on their
side but not the other side.

I guess if this entire thing is hidden away in the Xcode build and everyone
using the Xcode build wants things to work this way then I can't really
argue with that, but I don't think we should provide the option to use
static bindings in the CMake build.  (If anyone who uses the CMake build
disagrees though, please speak up)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151118/de66d393/attachment.html>