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

[Pavel Labath via lldb-commits]

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