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

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner <zturner at google.com> wrote:

>
>
> On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>>   Because even if it isn't perfect for everyone, it works for everyone.
>>>
>>
>> Unless you can't get swig on your system in a way that doesn't break
>> other items.  And then it doesn't work (as things stand now).
>>
> Is that a real issue that people on OSX are facing now?  Because I thought
> having SWIG installed on your system has been a requirement for the past N
> years.  Did something change  recently that now makes it impossible to
> install swig in a way that doesn't break something?
>
>

This is changing for a large class of people.


>
>>
>>> 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.
>>>
>>
>> I was actually going to add a verifier stage to the public OS X buildbot.
>>
> I'm not sure I follow this point.  What would your verifier stage do?  I'm
> imagining the following scenario:
>
> I check in some changes to SWIG interface files at like 10PM.  Ignoring
> the fact that you and Jason are usually up firing commits away until the
> wee hours of the morning, let's pretend nobody sees this until the
> morning.  So the build bot has been broken all night.  Is this something
> that is going to happen under this scenario?
>
>>
You can more or less ignore that point.

The intent is to alert those who update the static bindings (i.e. Apple
LLDB team) that the bindings generated and post processed from swig are not
matching the static ones.  This would just get sent to an internal group
over here since I'm not hearing definite resistance to moving to a
static-by-default model.  (If we had gone static-by-default, and made it
clean and explicit when modifying the SB API surface area by requiring an
update-the-binding step, there would have been no way to test the bindings
without having done the "update the bindings" step.  Since we won't be
doing that, then I need some way to ensure I know bindings are stale).

That's really a detail you won't need to worry about, though, since you
will not be using static bindings ever, and won't have to address any time
they go stale.  The fact that it happens on a public builder is not very
interesting either.  I worded it in a way that made it sound like others
externally would see the staleness alert, but that's not what I meant.

(I may automate that later, but not until I make sure it works manually up
front).
-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151118/ce33661e/attachment-0001.html>