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

Wed Nov 18 11:07:30 PST 2015

> On Nov 18, 2015, at 10:34 AM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala <todd.fiala at gmail.com <mailto: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?

CMake vends binary packages on OS X, along with installation instructions, so actually, you don’t need hombrew to get CMake on OS X. On my work machines, I actually don’t have it installed at all.

>  
>  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)
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151118/5faea896/attachment.html>