similar to: Flat Monorepo Prototype Not Updating

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:

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

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

The monorepo updates seem to have been stuck for an hour now. Is this expected? -- Dean

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

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

Hi folks, I recently started getting errors when I fetch from the github monorepo ( https://github.com/llvm-project/llvm-project-20170507). They look like this: $ git fetch error: cannot lock ref 'refs/tags/release_600': there is a non-empty directory '.git/refs/tags/release_600' blocking reference 'refs/tags/release_600' >From

> 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

Hi, I got a forced update when pulling today. If I merge master to a local branch, I get a bunch of add/add conflicts. This same commit exists under several hashes: https://github.com/llvm-project/llvm-project-20170507/commit/687841777ef505 https://github.com/llvm-project/llvm-project-20170507/commit/74725885552 Did someone push -f to the monorepo after doing branch surgery? Maybe there was a

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'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

On Sun, May 7, 2017 at 12:07 AM, NAKAMURA Takumi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I have done just now. 5 repos added including debuginfo-tests. > ATM, it includes 17 repos total. > > - Created the new repo; https://github.com/llvm- > project/llvm-project-20170507.git > Branches will come later. > - The previous repository has a merge commit that

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

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

Any easy way to do this as some kind of overlay, so they GN files wouldn't live in the LLVM repository, but in a separate one? (this might avoid some of the community discussion - though would perhaps still likely have the issue I see as most significant: With a sufficient number of developers using GN, the rate of build breaks due to those developers missing CMake file updates might rise to

> 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

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

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

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

Awesome. I'm happy with moving the .rst file into that directory and not have it on the public website. I'll try to make a patch that lands enough scaffolding to build `not` in the next few days, and then I'll land the other build files I have through the regular build process after that. Unless someone feels strongly, I'll go with Justin's suggestion of llvm/utils/gn/... On