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

[Todd Fiala via lldb-dev]

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

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

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



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