[lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.
Todd Fiala via lldb-dev
lldb-dev at lists.llvm.org
Wed Nov 18 12:54:54 PST 2015
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>
>> 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>
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev