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

[Zachary Turner via lldb-dev]

Moving this back over to the list since I'm sure others have some input
here.  Also +lldb-dev since it has more visibility than lldb-commits.


On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner <zturner at google.com> wrote:

> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> Breaking out the binding generation into a separate step will also be
>> important for a couple reasons:
>>
>> * (from before) I want to eliminate the requirement for the vast majority
>> of the builds to have a swig on their system, and
>>
>> * (not stated before) we'd like to move away from swig for binding
>> generation at some point.
>>
>> -Todd
>>
>
> Unless these plans (i.e. moving away from swig) are imminent, I would
> prefer to keep the binding generation step automatic so people can use
> whatever swig version is installed on their system.  I know there are pros
> and cons to each, but at the end of the day, we need various bugfixes from
> newer versions of SWIG for the Python 3 stuff, and if someone decides they
> want bindings for Go, or Rust, or some other languages, they too might need
> a different minimum SWIG version.  We could start checking in multiple sets
> of generated bindings, but then we start having multiple maintainers, and
> the checked in bindings become out of sync with each other, and it's more
> trouble than it's worth.
>
> We have buildbots building and testing the various configurations, so if
> someone uses something that is incompatible we shoudl catch it.  And just
> yesterday I added some options to the @expectedFailure and @skipIf
> decorators that allow you to skip tests based on the SWIG version and/or
> python version.
>
> Letting people using the SWIG on their system is the easiest way to ensure
> that everyone's needs are still met while still getting early notification
> when someone does something incompatible, and it can be fixed.
>
>
One possibility (which I mentioned to you offline, but I'll put it here for
others to see) is that we make a swig bot which is hosted in the cloud much
like our public build bots.  We provide a Python script that can be run on
your machine, which sends requests over to the swig bot to run swig and
send back the results.  Availability of the service would be governed by
the SLA of Google Compute Engine, viewable here:
https://cloud.google.com/compute/sla?hl=en

If we do something like this, it would allow us to raise the SWIG version
in the upstream, and at that point I can see some benefit in checking the
bindings in.  Short of that, I still dont' see the value proposition in
checking bindings in to the repo.  So far all I've heard is that it is so
that we don't need swig to be on everyone's machines, but I also don't see
the value proposition in that either, given that we already require many
other tools on peoples' machines.

If it means we can get off of SWIG 1.x in the upstream, I will do the work
to make remote swig generation service and get it up and running.  From the
user's perspective, it's already identical to what you're proposing.  No
swig executable on your machine (or anyone's machine for that matter), and
you run a simple script to generate bindings and check them in whenever you
make changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151118/aad8e2bf/attachment.html>