================
@@ -231,6 +245,10 @@ linux_projects_to_test=$(exclude-linux
$(compute-projects-to-test ${modified_pro
linux_check_targets=$(check-targets ${linux_projects_to_test} | sort | uniq)
linux_projects=$(add-dependencies ${linux_projects_to_test} | sort | uniq)
+linux_runtimes_to_test=$(compute-runtimes-to-test ${linux_projects_to_test})
----------------
joker-eph wrote:
> I believe Flang was tested on Clang changes to make sure Clang didn't make
> any incompatible changes to the driver, which Flang reuses. This is a
> different use case from testing Clang itself,
I see exactly the same kind of transitive dependency issue: one project depends
on another and running **all** the possible tests for the dependent project on
a change to the upstream project is deemed "not worth it".
> Additionally, "don't run those Clang tests if Clang is tested because of an
> LLVM change" kind of logic make it harder to reason about CI.
Referring to "clang CI" is a rather vague statement to me: testing in generally
goes into "tiers" and the "premerge" tiers is about tradeoff in terms of
value/cost, while you're making a completeness arguments. There are tons of
things that we don't test in pre-merge.
Also [the buildbot](https://lab.llvm.org/buildbot/#/builders/153) does not seem
to cover this, which is quite annoying because now pre-merge is broken (see
https://buildkite.com/llvm-project/github-pull-requests/builds/104995#019239b1-1aaa-411a-9fd2-9dcfdce25c3d
) by libcxx while the post merge is green, which should only ever happen if
the PR is responsible for the breakage.
https://github.com/llvm/llvm-project/pull/93318
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
