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

[Zachary Turner via lldb-commits]

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?  You said

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

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.

I mentioned earlier that one way there would be a definite tangible benefit
is if we could use these static bindings in conjunction with a swig bot
that would automatically generate swig on a remote server and send you back
the result.  This way we could remove one item from the configuration
matrix, which I think we all agree is a good thing based on the fact that
the original idea was to get everyone on 1.3x (which isn't possible since
it doesn't work well with Python 3.5).  Compare:

Platforms: Windows, Linux, FreeBSD, OSX, 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

with

Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
Python version: None, 2.7, 3.x (in progress)

The latter is much better, right?  Can we discuss whether this swig server
is a viable solution for getting to a single system that works for
everyone?  Again, I'm willing to do the brunt of the work getting it up and
running if it is (I can probably reuse the portion of work you've already
done related to running swig on the input files)

If the goal is just some kind of cleanup where it would be nice to not have
to install swig, I'm specifically arguing against that, because I don't
think that's a strong enough case to add one item to the configuration
matrix.

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