On Wed, Nov 18, 2015 at 12:53 PM, Todd Fiala <todd.fi...@gmail.com> wrote:
> > > On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner <ztur...@google.com> > wrote: > >> >> >> On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala <todd.fi...@gmail.com> wrote: >> >>> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner <ztur...@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
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
