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

[Todd Fiala via lldb-dev]

On Wed, Nov 18, 2015 at 12:53 PM, Todd Fiala <todd.fiala at gmail.com> wrote:

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

But more importantly, swig has never been easy to get on OS X except via
macports/fink.  Apple's internal toolchain has an ancient swig available
that we use, but we don't distribute that one.


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



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