================ @@ -68,7 +68,7 @@ function compute-projects-to-test() { done ;; clang) - for p in clang-tools-extra compiler-rt flang lldb cross-project-tests; do + for p in clang-tools-extra compiler-rt lldb cross-project-tests; do ---------------- joker-eph wrote:
> Can you point out where this is encoded in this file? I only see Flang > specified as a dependency of MLIR (not the other way round). This is what I mean: Flang is always test for all changes in MLIR, even when such change affect a subset of MLIR that Flang does not use. This is the analog situation with Clang where a change to Clang always trigger testing flang even when it touches the subset of Clang that can't impact Flang. > This approach is very expensive in practice. "Pre-merge testing is very expensive", yes... What can we say about changes to LLVM which triggers testing the entire monorepo (almost), even though a change to the PowerPC backend **cannot** possible fail a test in MLIR for example (unless you run the CI on a power-PC machine)? (and likely similarly can't fail a LLDB test, I'm not sure). But what are you arguing about here exactly? What is the core principle to use for testing the monorepo in a premerge context? Are you saying that there should be no dependency between the top-level projects at all for example? > I think this trivializes the current situation -- this is not "for the sake > of a problem on windows", this is for the sake of the entire community that > has been raising concerns with how unusable precommit CI has been for the > past ~six months. Sorry but you're again equating what I believe is a "windows problem" with "precommit CI" as a whole: 1) claim of "unstable" are dubious to me: this is vague and unspecified 2) The ci is very backed-up, and that's because Windows testing is slow. Someone proposed to remove windows from the pre-commit testing but I think you were the one opposing this. What I see on PRs on my side is that it always ends up with the Linux build completing while Windows waits for an agent for hours. Hence "it's a windows problem". So we're gonna be on the opposite side of who is trivializing he situation here! https://github.com/llvm/llvm-project/pull/92740 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits