[clang] [llvm] Disable compiling and testing Flang on Clang changes (PR #92740)
Mehdi Amini via llvm-commits
llvm-commits at lists.llvm.org
Mon May 20 10:03:34 PDT 2024
================
@@ -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
More information about the llvm-commits
mailing list