similar to: [LLVMdev] svn mirror git?

This has been discussed many times. Might want to take a look in the mailing list archives. :) cmake and autotools are on roughly equal footing at this point with chandler and I handling each of them respectively and fairly quickly. git vs. svn is a different story though. -eric On Thu, Nov 15, 2012 at 8:31 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Hi, > > Has there

> cmake and autotools are on roughly equal footing at this point with chandler > and I handling each of them respectively and fairly quickly. git vs. svn is > a different story though. Would you be willing to put this commitment to autotools in CODE_OWNERS.TXT? Sometimes I have needed to make changes to Makefiles and didn't know who was the right person to CC for it, so having an

David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > clock skew (which is easy to get in a VM) can confuse Ninja in a way > that doesn't give helpful errors. This is a significant issue. I would not want to transition to cmake+ninja before this is fixed. -David

>> clock skew (which is easy to get in a VM) can confuse Ninja in a way >> that doesn't give helpful errors. > >This is a significant issue. I would not want to transition to >cmake+ninja before this is fixed. Do you mean in the same way that clock skew would affect Make? Or just that Ninja doesn't provide that nice "clock skew detected" message that Make

I'm curious to know if the LLVM community is deeply split when it comes to version control. If you have a second, could you please vote? http://poll.pollcode.com/i597kq Thanks, Greg

On 15 Nov 2012, at 08:31, Greg Fitzgerald wrote: > Has there been discussion about having svn mirror git instead of vice versa? I've been happy with the git+cmake+ninja combo for a while now, but the online docs suggests this configuration is second-class to svn+autotools+make. Is the community transitioning to any particular configuration? I think svn works better than git as an

For starters, I hope the results of this poll can help guide how the GettingStarted page is written. http://llvm.org/docs/GettingStarted.html I'd imagine the most active contributors do not find themselves referencing this page too often, but as a newcomer, I feel it could use some work. Git is second class, CMake gets nothing but a passing reference, and Ninja is not even mentioned.

> I can't find any release_32 branch at http://llvm.org/git/llvm.git or http://llvm.org/git/clang.git. Unfortunately, this requires manual grafting, since git-svn does really bad job here. I'm going to work on this tonight. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Greg Fitzgerald <garious at gmail.com> writes: > I'm curious to know if the LLVM community is deeply split when it > comes to version control. If you have a second, could you please > vote? > > http://poll.pollcode.com/i597kq The result of this poll has little value in practice. In the past the project leader stated that the opinions of the most active contributors

> Note that ASan tests on Android require llvm-symbolizer binary. That's a really good point. And I see that llvm-symbolizer can't just be pulled into compiler-rt because it has dependencies on DebugInfo, Object, and Support libraries. This throws a big wrench in Alexey's plan to have the native compiler-rt build generate the cross-compiled binaries for all supported targets. We

Anton, please add release_32 also in; clang-tools-extra compiler-rt dragonegg libcxxabi lldb They have release_32 in svn. I don't know they might be released, though. And, could you suppress generating refs/heads/svn-tags and prune them for now? I am sure that orphan branches will stress the llvm.org server to begin git-pack-ing whole tree. ...Takumi 2012/11/15 Anton Korobeynikov

It does sound like Android is better suited for "honest" cross-compilation, rather than "build compiler-rt for all targets we can find" model. I'm still not convinced that we must require the "ninja install" step. Could we just "ninja clang" and then build the second stage against the first stage build directory? Will this "find_package" thing

Should be there. Please let me know if there are any problems with them On Wed, Nov 14, 2012 at 9:19 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> I can't find any release_32 branch at http://llvm.org/git/llvm.git or http://llvm.org/git/clang.git. > Unfortunately, this requires manual grafting, since git-svn does > really bad job here. > > I'm going

Hi Greg, On Wed, Apr 2, 2014 at 2:50 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Alexey, Evgeniy, > > I propose the following steps to unify multi-arch support in compiler-rt: > > 1) The compiler-rt test suite adds "-L${CMAKE_CURRENT_BINARY_DIR}/lib" > to its 'clang' variables. This way we can test the sanitizers without > installing any libs

> What is the exact line you use to configure build tree, and the output you see? cmake ../.. \ -G Ninja \ -DCMAKE_INSTALL_PREFIX=ship \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi \ -DLLVM_LIT_ARGS=-v ninja check-all

> Alexey's approach with CMake sub-projects. I prefer that direction as well, but what I've proposed is a solution that works today. To support cross-compilation, we'll need to loop over each supported arch (llvm-config --targets-built), then loop over each supported triple for each arch (hard-coded map?), and then pair up each triple with a sysroot (system paths provided by the

LLVM Community, > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html This was extraordinarily valuable in learning to understand the situation - thank you David Blaikie for pointing me to it. A few key snippets: "Because I optimize for the code reviewer, not the patch submitter," Chris Lattner "Forcing transitioning to git makes no sense for a lot of us - for

Hi Michael, > As for actually switching to git. I see no benefit to justify the cost > of switching unless we actually take advantage of git's features. And > I've yet to see anyone propose this. Then I'll be the first. :) The benefit is that the review process would require no file copies or email attachments, shorter email conversations, no copying code during reviews to

On 28 May 2014 17:44, Justin Bogner <mail at justinbogner.com> wrote: > In the autoconf system, I'm pretty sure compiler-rt's build is triggered > by a Makefile in clang, tools/clang/runtime/compiler-rt/Makefile. This > Makefile comments "We currently only try to generate runtime libraries > on x86", so I guess that's the place to start if you want to get it

Should be there On Fri, Nov 16, 2012 at 3:00 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Anton, please add release_32 also in; > > clang-tools-extra > compiler-rt > dragonegg > libcxxabi > lldb > > They have release_32 in svn. I don't know they might be released, though. > > And, could you suppress generating refs/heads/svn-tags and prune them