================
@@ -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
