similar to: RFC: End-to-end testing

> I have a bit of concern about this sort of thing - worrying it'll lead to > people being less cautious about writing the more isolated tests. > I have the same concern. I really believe we need to be careful about testing at the right granularity to keep things both modular and the testing maintainable (for instance checking vectorized ASM from a C++ source through clang has always

On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Renato Golin via Openmp-dev <openmp-dev at lists.llvm.org> writes: > > > But if we have some consensus on doing a clean job, then I would > > actually like to have that kind of intermediary check (diagnostics, > > warnings, etc) on most test-suite tests, which would

On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Renato Golin via Openmp-dev <openmp-dev at lists.llvm.org> writes: > > > But if we have some consensus on doing a clean job, then I would > > actually like to have that kind of intermediary check (diagnostics, > > warnings, etc) on most test-suite tests, which would

On Wed, Oct 9, 2019 at 8:12 AM David Greene <dag at cray.com> wrote: > Mehdi AMINI via cfe-dev <cfe-dev at lists.llvm.org> writes: > > >> I have a bit of concern about this sort of thing - worrying it'll lead > to > >> people being less cautious about writing the more isolated tests. > >> > > > > I have the same concern. I really

On Fri, 11 Oct 2019 at 18:02, David Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> We have to support many different systems and those systems are always > >> changing (new processors, new BIOS, new OS, etc.). Performance can vary > >> widely day to day from factors completely outside the compiler's > >> control. As the performance

On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this! > > Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side). > As such I don't

Renato Golin via Openmp-dev <openmp-dev at lists.llvm.org> writes: > We already have tests in clang that check for diagnostics, IR and > other things. Expanding those can handle 99.9% of what Clang could > possibly do without descending into assembly. I agree that for a great many things this is sufficient. > Assembly errors are more complicated than just "not generating

Here's another question about the current status of this. It's close to two months after the official monorepo was supposed to be published. Can someone give an update? Is this on hold indefinitely? Are there concrete issues that people are working on and this will happen as soon as those are resolved? At the least, I'm assuming the "SVN will shut down 1 year from now"

Building on the great work that James Knight did on migrate-downstream-fork.py (Thanks, James!) [1], I've created a simple tool to take migrated downstream fork branches and zip them into a single history given a history containing submodule updates of subprojects [2]. With migrate-downstream-fork.py, one is left with a set of unrelated histories, one per subproject: llvm

Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff

He all, I've updated the downstream fork zipping tool that I posted about last November [1]. It is much improved in every way. The most important enhancements are: - Does a better job of simplifying history - Handles nested submodules - Will put non-submodule-update content in a subdirectory of the monorepo - Updates tags In addition there are plenty of the requisite bug fixes. The

> On Jul 28, 2016, at 10:53 AM, Justin Lebar <jlebar at google.com> wrote: > > Thanks again for your thoughts, Chris. > >> As a straw man I would suggest the following criteria for inclusion into the mono-repo: >> >> (1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo > > I'm fine

> On Jul 28, 2016, at 12:05 PM, Justin Lebar <jlebar at google.com> wrote: > >>> The decision of whether or not to include these projects >>> affects only read-write consumers of these projects -- of which there >>> are relatively few people. >> >> Maybe there are few, but the impact is non-insignificant. Also I think the opinions of the

Hi, > On Sep 7, 2016, at 10:30 AM, dag at cray.com wrote: > > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Right, we actually have a proposal to take what is in the current SVN >> repo here: http://llvm.org/svn/llvm-project/ and migrate this to a >> single repository. >> I was not sure if you were referring to this proposal

Hi folks, Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets some flags

> 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

Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> writes: > I'd recommend trying to move any e2e tests into the test-suite and > make it easier to run, and leave specific tests only in the repo (to > guarantee independence of components). That would be a shame. Where is test-suite run right now? Are there bots? How are regressions reported? > The last thing we want

Hi Mehdi, I really like your idea of having a few "projected" git repositories (i.e. capture all commits that touch llvm/ into llvm.git, all that touch clang/ to clang.git etc.). I think it should solve our problem of llvm-forks-with-downstream changes very nicely (I think we won't have to do anything, as you said). I still want to sleep on it to see if I can spot any issues.

> 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

Hi, all. I feel like we've strayed pretty far from the question originally posed in this thread. One of the pieces of feedback I got before I started this thread was that many people felt that, the last time the question of multiple repos vs. monorepo was discussed, it was interspersed with other topics, making it difficult for some people to weigh in appropriately (or even to be aware that