> On Aug 5, 2016, at 10:28 AM, Jim Ingham via swift-lldb-dev > <[email protected]> wrote: > > The SWIG Python bindings need to be updated. Sean added an API to the SB > API's which is used in this test. That's what the SetREPLMode attribute > error - we're calling a method on a class that isn't present in the Python > representation of the class. > > In OS X builds, for instance, a change in the SB API's would cause the SWIG > bindings to get regenerated, and everything would be fine. But we decided > not to require the linux builders to have SWIG, so for that environment the > bindings need to be manually updated. For now, this is a by hand type thing, > and a job Todd has up to now done. >
Huh, that’s weird. I answered this from my [email protected] <mailto:[email protected]> account while away on vacation, but I’m not seeing it show up on this thread. I’ll have to track that down. I have a task on my plate to automate this step. Up until now, I generally am doing the merges that bring over SBAPI changes, and I generally update the static bindings at that time. I think the static bindings get used on macOS in some places as well - machines using public macOS don’t have a version of swig on them by default, and I think several of our CI are configured this way. > When we were originally dealing with what to do about building lldb on > platforms that didn't have SWIG installed, we suggested that the result of > running SWIG be a file that is checked in to lldb and not rebuilt by default. > Then we would have the SWIG step be a maintainer-mode operation that you > would do whenever you updated any of the SB API's, checking in the result > along with the SB API changes. But for some reason that was never clear to > me, folks at Google were strongly opposed to this, so we ended up in this ad > hoc arrangement for the Linux CI's instead. > > I actually don't know what Todd does to get this updated file onto the Linux > builders. If nobody else knows, I'll find out from him when he gets back on > Monday so we have a couple of people who know the incantation. > The steps are pretty simple: 1. Do a build on a machine with swig 1.3.40 installed. 2. Copy the LLDBWrapPython.cpp and lldb.py from the build directory into {lldb-source-root}/scripts/Python/static-binding. 3. Check those in. The files in that directory are used if (1) swig can’t be found and (2) a flag is specified which says that it is okay to use static bindings. The Swift build-script-based builds specify that flag, as does the Xcode-driven build, so we’ll use the static bindings from the scripts/Python/static-binding dir in that case. > Note, we added this new SB API way of running REPL tests because the other > way of testing them - feeding text at the REPL as a sub-process directly and > using pexpect to handle the traffic - was failing intermittently. Seems > pexpect is actually a poor substitute for expect, doesn't work at all on > Windows, and is flakey on Linux. It actually seems pretty solid on OS X, > which I guess is yay for us, but doesn't help with the Linux CI's... > > I see you reverted the test back to this flakey but xfailed state. If it > stays that way till Todd gets back on Monday, that won't do any harm. > I’ll go ahead and update these for GitHub swift-lldb/master later this morning. -Todd > Jim > > >> On Aug 4, 2016, at 9:56 PM, Douglas Gregor via swift-lldb-dev >> <[email protected]> wrote: >> >> Anyone know what’s going on here? There’s very little information in the log >> from >> >> >> https://ci.swift.org/job/swift-PR-Linux-smoke-test/565/consoleFull#-161933955fca400bf-2f4a-462e-b517-e058d770b2d7 >> >> it’s been failing consistently on Linux since this went in earlier today: >> >> >> https://github.com/apple/swift-lldb/commit/119fcb317c16ec30c20b63a1838da39302317352 >> >> making smoke testing mostly useless. >> >> - Doug >> >> ====================================================================== >> ERROR: test_with_dwarf (lldbsuite.test.lldbtest.TestREPLThrowReturn) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", >> line 129, in __test_with_dwarf >> self.do_test() >> File >> "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", >> line 154, in do_test >> parser.handle_breakpoint(self, thread, breakpoint_id) >> File >> "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", >> line 65, in handle_breakpoint >> options.SetREPLMode(True) >> File >> "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/lldb-linux-x86_64/lib/python2.7/site-packages/lldb/__init__.py", >> line 3987, in <lambda> >> __getattr__ = lambda self, name: _swig_getattr(self, SBExpressionOptions, >> name) >> File >> "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/lldb-linux-x86_64/lib/python2.7/site-packages/lldb/__init__.py", >> line 79, in _swig_getattr >> raise AttributeError(name) >> AttributeError: SetREPLMode >> Config=x86_64-/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9 >> ---------------------------------------------------------------------- >> Ran 1 test in 2.985s >> >> RESULT: FAILED (0 passes, 0 failures, 1 errors, 0 skipped, 0 expected >> failures, 0 unexpected successes) >> Session logs for test failures/errors/unexpected successes can be found in >> directory '2016-08-04-23_42_49' >> _______________________________________________ >> swift-lldb-dev mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-lldb-dev > > _______________________________________________ > swift-lldb-dev mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-lldb-dev
_______________________________________________ swift-lldb-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-lldb-dev
