similar to: Mono-repo Git porposal?

> -----Original Message----- > From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] > Sent: Thursday, July 21, 2016 3:16 PM > To: Robinson, Paul > Cc: Renato Golin; Justin Lebar; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > > > On Jul 21, 2016, at 2:33 PM, Robinson, Paul via llvm-dev <llvm- > dev at

Dear all, In the official document <https://llvm.org/docs/CompileCudaWithLLVM.html>, it is mentioned that CUDA compilation is supported on Windows as of 2017-01-05. I used msys2 to install clang 5.0.1. Then I installed cuda 8.0. However, I basically could not compile any code of cuda by the prescribed setting. I wounder if anyone can successfully compile cuda code by the clang on Windows.

> Which projects do we put under this monolithic repository? The proposal at the moment is to include llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt, openmp, and parallel-libs. This is the set {llvm} plus the transitive closure of "projects that are version-locked to a project in the set", where the closure is taken over the set of all active LLVM

On Wed, Jul 20, 2016 at 5:02 PM Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> writes: > > I would like to (re-)open a discussion on the following specific > question: > > > > Assuming we are moving the llvm project to git, should we > > a) use multiple git repositories, linked

On 27 October 2016 at 19:02, Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, it looks like you're compiling CUDA for an ARM host? This is not > a configuration we have tested, nor is it something we have the > capability of testing at the moment. Hi Justin, NVidia TX1 is the AArch64 Jetson board with proper GPU (we use those). > You may be able to

> On 21 July 2016 at 18:12, Justin Lebar <jlebar at google.com> wrote: > > llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt, > > openmp, and parallel-libs. > > I really, *really* would like to see libc++ / abi / unwind. :) > > My reason is that, when building toolchains, the C++ ABI and unwinding > are fundamental parts of the run-time

> NVidia TX1 is the AArch64 Jetson board with proper GPU (we use those). Sure, I believe that others use this configuration. I was saying, "we", being, myself and those whom I work closely with, do not. Sorry if that wasn't precise. It is still not clear to me if the original poster is compiling for ARM or not. But it sounds like you're going to help them get this

> Today I *can* checkout only LLVM and Clang. On a single Git repo I can't. This is true if you s/checkout/clone/. With a single repo, you must clone (download) everything (*), but after you've done so you can use sparse checkouts to check out (create a working copy of) only llvm and clang. So you should only notice the fact that there exist things other than llvm and clang when you

By the way, I've been using the existing read-only monorepo [1] for a few days now. The intent is to commit via the script I put together [2], although I haven't committed anything other than a testing commit [3]. All I can say is, *wow* is it nice. I hid everything I don't care about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5] [6], ycm [7]) suddenly work better

> Running the same 'git checkout' commands on multiple repos has always been sufficient to manage the multiple repos so far Huh. It definitely hasn't worked well for me. Here's the issue I face every day. I may be working on (unrelated) changes to clang and llvm. I update my llvm tree (say I checked in a patch, or I want to pull in changes someone else has checked in). Now

Can you please clarify your use of “cost” (bandwidth, disk space, extra command to type initially?), Developer time, barrier to entry for new contributors. Getting the sparse-checkout business right looks like it is actually non-trivial and not recommended for the git novice. *Changing* the sparse-checkout configuration later appears to be fraught with peril (easy to get wrong). The claim is

On Wed, Jul 20, 2016 at 6:26 PM, Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Justin Lebar <jlebar at google.com> writes: > >> Running the same 'git checkout' commands on multiple repos has > >> always been sufficient to manage the multiple repos so far > > > > Huh. It definitely hasn't worked well for me. > >

> The only thing a monorepo gets you that strictly isn’t possible without > it is the ability to commit to multiple projects in a single commit. > Personally I don’t think that is a big enough justification, but that is > my opinion, not a fact. Okay, I just bumped into r277008, in which commits to llvm, clang, and clang-tools-extra all have the same SVN revision number. I don't

Hi Justin, Firstly I really appreciate you taking the mantle and pushing this forward! Like Justin B I'll be bowing out after this. I thought it important because I don't believe you'll build consensus in this thread. I think the best that can be hoped for is opposition to give up fighting; advantages are to be had on both sides by different types of user and we've seen that many

Maybe we can hit the pause button on this issue of a survey vs consensus-building. I think it's a distraction from the main issue here, and it makes it harder for everyone else to participate in the thread. That said, I really do think that perspectives like Justin B's below are important. That is, if people have a problem with the monorepo, it is useful they can join the thread and say

Hi Justin, Thanks for your response! The clang & llvm I'm using was built from source. Below is the output of compiling with -v. Any suggestions would be appreciated! *clang version 3.9.0 (trunk 270145) (llvm/trunk 270133)* *Target: x86_64-unknown-linux-gnu* *Thread model: posix* *InstalledDir: /usr/local/bin* *Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8*

OK, I see the problem. You were right that we weren't picking up libdevice. CUDA 7.0 only ships with the following libdevice binaries (found /path/to/cuda/nvvm/libdevice): libdevice.compute_20.10.bc libdevice.compute_30.10.bc libdevice.compute_35.10.bc If you ask for sm_50 with cuda 7.0, clang can't find a matching libdevice binary, and it will apparently silently give up and try to

> On Jul 27, 2016, at 11:38 AM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Justin, > > Firstly I really appreciate you taking the mantle and pushing this forward! Like Justin B I'll be bowing out after this. > > I thought it important because I don't believe you'll build consensus in this threathese thred. Is it possible to

> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. This is an *extremely important* point to understand, so let me try to be really clear about the current state of the world and the state of the world under the two "move to git" proposals. Today, all commits ultimately end up in SVN. Our SVN is a effectively a

> On Jul 20, 2016, at 5:56 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 21 July 2016 at 01:39, Justin Lebar <jlebar at google.com> wrote: >> This is true if you s/checkout/clone/. With a single repo, you must >> clone (download) everything (*), but after you've done so you can use >> sparse checkouts to check out (create a