Re: [lldb-dev] [Openmp-dev] [4.0.0 Release] Release Candidate 2 has been tagged
Hi, I've built, uploaded and partially tested rc2. Looks ok. I'll post if anything crops up. 78afc4479ee0f121ba3080cb04547572 clang+llvm-4.0.0-rc2-mipsel-linux-gnu.tar.xz 9d0aba409e80500224583a6baed6b945 clang+llvm-4.0.0-rc2-mips-linux-gnu.tar.xz c654db0e66231e2c72c2fcc426e843e5 clang+llvm-4.0.0-rc2-x86_64-linux-gnu-debian8.tar.xz Thanks, Simon > -Original Message- > From: Openmp-dev [mailto:openmp-dev-boun...@lists.llvm.org] On Behalf > Of Hans Wennborg via Openmp-dev > Sent: 09 February 2017 00:34 > To: Release-testers > Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev > Subject: [Openmp-dev] [4.0.0 Release] Release Candidate 2 has been tagged > > Hello testers, > > 4.0.0-rc2 was just tagged from the branch at r294535. > > There are still open relase blocking bugs and merge requests, so this will not > be the last release candidate, but we've had a lot of merges since the last > one, and I'd like to see what the testing looks like. > > The test-release.sh script was updated to also include lld. Make sure you're > using the latest version of the script (ideally from the branch, but the trunk > version is identical), and if lld causes any problems, pass the "-no-lld" > flag. > > Please build, test, and upload binaries to the sftp. Let me know what comes > up, and I'll publish your binaries plus source and docs when they're ready. > > Thanks, > Hans > ___ > Openmp-dev mailing list > openmp-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [4.0.0 Release] Release Candidate 1 source and binaries available
Source, binaries and docs for LLVM-4.0.0-rc2 are now available at http://www.llvm.org/pre-releases/4.0.0/#rc2 Please try it out, run tests, build your favourite projects and file bugs about anything that needs to be fixed, marking them as blockers of http://llvm.org/pr31622. Many things have been fixed since RC1, but there are still open issues so we will need at least one more release candidate before the final release. Cheers, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [4.0.0 Release] Release Candidate 2 source and binaries available
Apologies, the subject should say Release Candidate *2* is now availalble. On Tue, Feb 14, 2017 at 11:56 AM, Hans Wennborg wrote: > Source, binaries and docs for LLVM-4.0.0-rc2 are now available at > http://www.llvm.org/pre-releases/4.0.0/#rc2 > > Please try it out, run tests, build your favourite projects and file > bugs about anything that needs to be fixed, marking them as blockers > of http://llvm.org/pr31622. > > Many things have been fixed since RC1, but there are still open issues > so we will need at least one more release candidate before the final > release. > > Cheers, > Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] About lldbHost
After https://reviews.llvm.org/D29964, we finally have a starting point at which we can begin unravelling the cross-project cyclic dependencies in LLDB. lldb/Utility now is very similar in spirit to llvm/Support. But llvmSupport goes one step further and includes what lldb would normally put under Host. I think this makes some sense. Practically all parts of a codebase have need of a single OS abstraction layer. So, I think that a lot of the functionality currently in lldbHost is in fact needed by the rest of LLDB. So, I wonder if it makes sense to follow the path that LLVM has taken, and start moving some of this code from Host down to Utility. Doing so would allow us to break one of the biggest links in the dependency cycle in the entire codebase, which is that Host depends on everything, and everything depends on Host. Of course, it can't just be a straight move. Some things in Host interact with Target, with CommandInterpreter, and with many other things. And stuff going into Utility can't take a dependency. So there will be some splitting, some moving, some refactoring, etc. But to me tackling Host seems like the logical next step, in large part because Host is where FileSpec is, and it's going to be hard to break any dependencies without first addressing FileSpec. The way LLVM handles cross-platform differences in Support is that you include a single header and it does conditional includes into a platform specific subdirectory for the parts that differ. I'm thinking to follow the same pattern here in lldb/Utility, and begin looking for ways to get pieces of Host down into Utility this way, until ultimately I can get FileSpec down there. Thoughts? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
