This is an archive of the discontinued LLVM Phabricator instance.

Honor COMPILER_RT_INCLUDE_TESTS when using LLVM_BUILD_EXTERNAL_COMPILER_RT=ON
AcceptedPublic

Authored by azharudd on Apr 26 2022, 1:03 PM.

Details

Summary

When building with LLVM_BUILD_EXTERNAL_COMPILER_RT=ON (where we build
compiler-rt with the just built clang), the compiler-rt tests are being
enabled based on LLVM_INCLUDE_TESTS and not COMPILER_RT_INCLUDE_TESTS,
thereby providing no way to disable just the compiler-rt tests.

This change makes the compiler-rt tests depend on COMPILER_RT_INCLUDE_TESTS
instead. The default value of COMPILER_RT_INCLUDE_TESTS is set to the
value of LLVM_INCLUDE_TESTS (this retains the existing behavior too).

Diff Detail

Event Timeline

azharudd created this revision.Apr 26 2022, 1:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2022, 1:03 PM
Herald added a subscriber: mgorny. · View Herald Transcript
azharudd requested review of this revision.Apr 26 2022, 1:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2022, 1:03 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
beanz added a comment.Apr 26 2022, 1:05 PM

I question whether we should be extending this or killing it off... Is there a reason you're using LLVM_BUILD_EXTERNAL_COMPILER_RT instead of LLVM_ENABLE_RUNTIMES=compiler-rt?

I question whether we should be extending this or killing it off... Is there a reason you're using LLVM_BUILD_EXTERNAL_COMPILER_RT instead of LLVM_ENABLE_RUNTIMES=compiler-rt?

In this case I'm just trying to make it work with existing build configurations where it is being used (for example Swift). We should definitely be moving away from LLVM_BUILD_EXTERNAL_COMPILER_RT in favor of LLVM_ENABLE_RUNTIMES eventually though.

beanz added a comment.Apr 26 2022, 2:04 PM

In this case I'm just trying to make it work with existing build configurations where it is being used (for example Swift). We should definitely be moving away from LLVM_BUILD_EXTERNAL_COMPILER_RT in favor of LLVM_ENABLE_RUNTIMES eventually though.

My point here is that maybe you should move away from the legacy way of building now rather than improving it... Not sure how @phosek feels about this. I would personally very much prefer if we only had one way to build compiler-rt instead of the half dozen we have today.

In this case I'm just trying to make it work with existing build configurations where it is being used (for example Swift). We should definitely be moving away from LLVM_BUILD_EXTERNAL_COMPILER_RT in favor of LLVM_ENABLE_RUNTIMES eventually though.

My point here is that maybe you should move away from the legacy way of building now rather than improving it... Not sure how @phosek feels about this. I would personally very much prefer if we only had one way to build compiler-rt instead of the half dozen we have today.

I'd definitely prefer moving towards LLVM_ENABLE_RUNTIMES. We already require LLVM_ENABLE_RUNTIMES for libc++, libc++abi and libunwind and I'm going to propose doing the same for compiler-rt as well.

In this case I'm just trying to make it work with existing build configurations where it is being used (for example Swift). We should definitely be moving away from LLVM_BUILD_EXTERNAL_COMPILER_RT in favor of LLVM_ENABLE_RUNTIMES eventually though.

My point here is that maybe you should move away from the legacy way of building now rather than improving it... Not sure how @phosek feels about this. I would personally very much prefer if we only had one way to build compiler-rt instead of the half dozen we have today.

I understand, and I agree there should be only one way to do it. I did think about it but it is more involved and I unfortunately don't have the time to commit to it right now. I'm hoping we can take care of it at some point (I'm tracking it), but until then this satisfies the immediate need.

beanz added subscribers: smeenai, ldionne, compnerd.

I don't want to roadblock or say "no we absolutely can't let this in", _but_... Apple Clang and Swift have long been the only reason we've kept this code alive. I didn't have the time to fix Apple Clang years ago, and nobody has made the effort since.

I'm very aware of the technical debt of build-script, and I don't want LLVM to be in a position where we need to continue supporting confusing build scenarios because the Swift build is too complex to fix.

I'll defer to whatever @phosek, @compnerd, @smeenai, and @ldionne feel is right here, but I do believe at some point in the future we should delete this code path, whether downstream users have migrated or not.

I'd definitely prefer moving towards LLVM_ENABLE_RUNTIMES. We already require LLVM_ENABLE_RUNTIMES for libc++, libc++abi and libunwind and I'm going to propose doing the same for compiler-rt as well.

+1 on this. Compiler-RT's CMake code is extremely and unnecessarily complicated because we support far too many exotic build configurations.

I don't want to roadblock or say "no we absolutely can't let this in", _but_... Apple Clang and Swift have long been the only reason we've kept this code alive. I didn't have the time to fix Apple Clang years ago, and nobody has made the effort since.

I'm going to approve because this change seems reasonable. However, I think we need to have a serious conversation about removing LLVM_BUILD_EXTERNAL_COMPILER_RT with an actual deadline so that we can make forward progress here. This review is probably the wrong place to have that discussion. We probably should have an RFC on the forums with the deprecation plan.

delcypher accepted this revision.Apr 26 2022, 4:52 PM

Change LGTM.

This revision is now accepted and ready to land.Apr 26 2022, 4:52 PM
beanz added a comment.Apr 27 2022, 1:51 PM

I posted a PR to swift that migrates build-script to use LLVM_ENABLE_RUNTIMES: https://github.com/apple/swift/pull/58465

Obviously I can't test this against your internal infrastructure, but the change here is pretty trivial.

ldionne resigned from this revision.Aug 31 2023, 8:57 AM