release/22.x: [openmp] Allow testing OpenMP in runtimes builds without a full clang build tree

[mstorsjo]

Having a build tree with "not" and "FileCheck" is still required, but if Clang/Flang isn't configured in that build, run the tests with the same compiler CMake uses. This is how testing worked in the standalone build configurations that now have been removed.

This is a manually adapted backport of 48a5119 / #182470 to the 22.x release branch.

This allows testing OpenMP in the same way on both git main and the 22.x release branch.

[Meinersbur]

I expected this to be mostly a backport of #182470. What are the changes to omptest for?

Consider writing a summary.

[mstorsjo]

I expected this to be mostly a backport of #182470.

Yeah; this is an adapted backport of that one, plus a straight cherrypick of d5fea7e.

What are the changes to omptest for?

It's for getting this snippet:

# Only support OpenMP runtime 'bootstrap' build mode.
# Check as seen in 'runtimes/CMakeLists.txt', due to passing HAVE_LLVM_LIT to
# llvm_ExternalProject_Add() only.
if (NOT HAVE_LLVM_LIT)
  message(STATUS "Skipping omptest build. Reason: Only supported in bootstrap"
                 " build mode of OpenMP runtime.")
  return()
endif()

Without that, testing fails in the runtimes builds, if OMPT is supported, with this error:

ninja: error: '/home/martin/code/llvm-project/llvm/build-testtools-only/lib/libllvm_gtest.a', needed by 'openmp/tools/omptest/libomptest.so', missing and no known rule to make it

Consider writing a summary.

Ok, will do. (PRs to release branches aren't squashed, but the individual commits of the PR are preserved as such, so the final merged form of the PR is seen in the individual commits. But I'll summarize the reasoning in the PR description.

[mstorsjo]

@Meinersbur While this also is pending a release manager to approve/merge, I don't think they'll look at it until it is approved by you (or someone else) first.

[Meinersbur]

I think this should be two different PRs. While personally I do not care, but I think it makes it easier to not lose track of what has been backported, but I don't know how important it is to the release manager.

See the workflow described at https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches.

[mstorsjo]

I think this should be two different PRs. While personally I do not care, but I think it makes it easier to not lose track of what has been backported, but I don't know how important it is to the release manager.

Ok, fair enough.

See the workflow described at https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches.

Yes, I'm aware of that workflow. That's easy for the patches that apply cleanly, but for backporting my commit, it won't apply as is due to standalone builds still being supported in 22.x, so I'll have to do that one as a custom PR (like this one).

[mstorsjo]

I split off the other change into its own backport PR, #183775, and updated this one to only be a backport of #182470.

[mstorsjo]

Ping @Meinersbur - can you ack this backport now?

[Meinersbur]

LGTM

[dyung]

I split off the other change into its own backport PR, #183775, and updated this one to only be a backport of #182470.

Do these changes need to go in together, and/or in a certain order? I can merge this change in, but the other needs manual intervention at the moment since it is an llvmbot branch and I'm having issues force-pushing to those branches.

[mstorsjo]

I split off the other change into its own backport PR, #183775, and updated this one to only be a backport of #182470.

Do these changes need to go in together, and/or in a certain order? I can merge this change in, but the other needs manual intervention at the moment since it is an llvmbot branch and I'm having issues force-pushing to those branches.

No, they're independent and can be merged in any order.