similar to: Monorepo Updates Behind?

Anton has fixed it. 2018年8月30日(木) 17:23 Martin Storsjö via llvm-dev <llvm-dev at lists.llvm.org>: > On Thu, 30 Aug 2018, Dean Michael Berris via llvm-dev wrote: > > > The monorepo updates seem to have been stuck for an hour now. > > > > Is this expected? > > It seems like the regular per-project git repos also are stuck right now - > which probably

Possibly unrelated but since someone asked, I wonder why we don’t have monorepo for releases? For example a .tar.s containing all LLVM6.0 components placed at correct location Zhang > 在 2018年8月30日，18:16，Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > Thanks! >> On Thu, Aug 30, 2018 at 7:31 PM NAKAMURA Takumi <geek4civic at gmail.com> wrote:

The monorepo prototype at https://github.com/llvm-project/llvm-project-20170507 is currently 9 hours behind. I forget who’s responsible for the script(s) updating the monorepo(s), and it would be great if we can inform them of the state of the monorepo. Cheers -- Dean

On Sun, May 13, 2018 at 8:48 PM Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I recommend using https://github.com/llvm-project/llvm-project-20170507 if you can spare 1.1 GB of disk and bandwidth for the initial checkout and git repo itself. > It's just a few minutes behind the svn master copies. I don't know of a better monorepo at present. > Although

> On 29 Jul 2016, at 19:19, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream

Another option is just to run corresponding script from *https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/ <https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/>* in empty directory. On Thu, Aug 30, 2018 at 5:00 AM Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Dean, > > I've not done this

Hi llvm-dev, I'm trying to reproduce an msan failure in one of the bots, but I can't seem to get the right incantation of building LLVM with msan. Here's what I've been doing: 1) Build the toolchain in one build directory, including `compiler-rt`. 2) Build the toolchain again with the just built toolchain in step 1, but this time with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`. I

Thanks Dean and Bruce. 1.1GB is a "lot" smaller than I expected, my worry was that it might be >60GB with the entire change histories to v1.0. Disk space is not a problem (at ~€80 per TB) just ISP download caps and 1.1GB is well under the radar :-) I will get Phabricator set up for collaboration. Thanks again for your help, MartinO -----Original Message----- From: Dean Michael

Aside: would it be useful to execute a build of the libc++/libc++abi with msan normally during release, and change the driver to look for these msan-built C++ libs when "-fsanitize=memory"? That would drastically cut down on the complexity of using msan. On Fri, Aug 31, 2018 at 5:43 AM Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks Vitaly and

On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> wrote: > > I understand this, but why isn't "the repo you're interested in" just the megarepo (or monorepo) where every LLVM project resides? Your assumption is a downstream user of LLVM. As previously pointed out, we have downstream users of libc++ and the sanitizer runtimes who compile with

> On 29 Jul 2016, at 21:58, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote: > > On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> wrote: >> >> I understand this, but why isn't "the repo you're interested in" just the megarepo (or monorepo) where every LLVM project resides? > > Your assumption is a downstream

Hi Anton, Forgive me for the potentially dumb question -- but how do I do that myself? The monorepo doesn't contain the website source(s) and it's unclear how I can do that myself... I'd love to do it myself but I'm a little lost on how to do it. Help? On Tue, Feb 20, 2018 at 9:18 PM Anton Korobeynikov <anton at korobeynikov.info> wrote: > Dean, > > Please add

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Dean > Michael Berris via llvm-dev > Sent: Friday, July 29, 2016 5:04 AM > To: David Chisnall > Cc: LLVM Developers; Bruce Hoult > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > > > On 29 Jul 2016, at 21:58, David Chisnall <david.chisnall at

Isn’t the checkout a local operation that should not involved GitHub ? Did you mean the clone operation ? And about sparse-checkout, I though they require a full clone of the repository anyway. Is there a way to do a partial clone only ? Note: If you don’t need the whole history local, you may perform a swallow clone (using —depth 1). > Le 9 nov. 2018 à 01:02, Anton Korobeynikov via llvm-dev

If I read this correctly, there isn't much opposition to landing the gn files as long as it's very clear that regular devs aren't supposed to update them and that it's clear that they're experimental The main concerns I've heard so far: - Having two build systems is confusing. I can see this, but I think putting the gn files below llvm/experimental/gn (instead of right

Dean, Please add this to OpenProjects page. On Tue, Feb 20, 2018 at 6:49 AM, Dean Michael Berris via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Hi Tanya, > > Is it too late to get some smaller projects for XRay in there? > > Here's two: > > XRay Function Coverage Mode: Implementing an XRay mode to gather function > call coverage information. This will be

I'm still somewhat unclear about what you mean by "metadata record entry at the beginning of the block". I understand that I can make a MetadataRecord that contains the pid/tid since a metadata record contains 16 bytes. However, I don't understand what do you mean by the "beginning of the block". Do you mean right after the file header? My understanding is that at

The value in having them somewhere in-tree is that it's easier for people collaborate on these files, and it's way lower setup overhead if someone wants to try it out. If people prefer llvm/util over llvm/experimental, that's fine with me. There would only be a single directory that will contain build files for all of llvm, clang, lld, etc. The build files would be in

I would be happy to help. Could you send me the example patch? Where would I submit my patch to be reviewed? Thanks, Henry On Mon, Jun 11, 2018 at 8:31 PM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > > On 12 Jun 2018, at 07:49, Henry Zhu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > > > I’ve

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >