This is an archive of the discontinued LLVM Phabricator instance.

[runtimes] Remove FOO_TARGET_TRIPLE, FOO_SYSROOT and FOO_GCC_TOOLCHAIN
ClosedPublic

Authored by ldionne on Oct 20 2021, 9:45 AM.

Details

Reviewers
phosek
compnerd
Group Reviewers
Restricted Project
Restricted Project
Restricted Project
Commits
rG3ee0cec88eff: [runtimes] Remove FOO_TARGET_TRIPLE, FOO_SYSROOT and FOO_GCC_TOOLCHAIN
Summary

Instead, folks can use the equivalent variables provided by CMake
to set those. This is an alternative to D111672.

Diff Detail

Event Timeline

ldionne created this revision.Oct 20 2021, 9:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2021, 9:45 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne requested review of this revision.Oct 20 2021, 9:45 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptOct 20 2021, 9:45 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript

I have the feeling that this is going to break people, but I'm investigating this patch as requested in D111672.

ldionne updated this revision to Diff 381005.Oct 20 2021, 9:47 AM

Rebase onto main

compnerd accepted this revision.Oct 26 2021, 11:11 AM
compnerd added a subscriber: compnerd.

I think that as long as the builders remain green, this is fine. Yes, this is very likely to break users. We should announce this change on llvm-dev at the very least, and you *could* possibly add a transition helper in the form of:

if(NOT CMAKE_SYSROOT AND LIBCXX_SYSROOT)
  message(SEND_WARNING "LIBCXX_SYSROOT is deprecated, please use CMAKE_SYSROOT")
  set(CMAKE_SYSROOT ${LIBCXX_SYSROOT} CACHE STRING "" FORCE)
endif()

I think that having a nice transition would be preferable, and we could drop it in the next release.

I went through my notes and the reason I introduced these flags was to support the scenario where you use LLVM_ENABLE_PROJECTS=clang;libcxx;... and you want to build libc++ (and other runtimes) for target other than host, so you cannot use CMAKE_CXX_COMPILER_TARGET or CMAKE_SYSROOT because that would also affect the tools build.

That predates the bootstrapping (née runtimes) build support and is very limited (you can only build runtimes for one target, you can only vary a few flags, you're still using the host compiler so you likely need a two-stage build) which is why we haven't used it ever since bootstrapping build became available.

I don't know if anyone still uses this support, but even if so we should steer them towards the bootstrapping build. I agree with @compnerd that providing a deprecation message for now and removing them in the next release might be preferable.

ldionne updated this revision to Diff 409304.Feb 16 2022, 9:47 AM

Rebase onto main after adding a deprecation message.

Thanks a lot for the discussion @compnerd and @phosek , and sorry this slept for so long. But I think we should be good to move forward with this now.

ldionne updated this revision to Diff 409396.Feb 16 2022, 1:40 PM

Fix ABI list issue.

ldionne accepted this revision as: Restricted Project.Feb 17 2022, 7:13 AM

@phosek Is this fine with you? And @compnerd is this still fine with you too?

If so, I'll check this in during the week of Feb 28 (when I return from vacation) so I can be available in case any issues come up.

This revision is now accepted and ready to land.Feb 17 2022, 7:13 AM
phosek accepted this revision.Feb 17 2022, 10:12 AM

LGTM

ldionne updated this revision to Diff 411892.Feb 28 2022, 2:02 PM

Poke CI after rebasing. I'll land this tomorrow if CI is green.

I'm going to land this now, however I'll use message(WARNING instead of message(FATAL_ERROR to avoid requiring a CMake cache rebuild for everyone.

simoll added a subscriber: simoll.Mar 2 2022, 2:02 AM

Remark: Targets need to specify CMAKE_ASM_COMPILER_TARGET or UnwindRegistersRestore|Save.S will be assembled for the default target, not the CMAKE_C|CXX_COMPILER_TARGET.
This caused the libunwind miscompile for the clang-ve-ninja bot: https://lab.llvm.org/buildbot/#/builders/91/builds/4728

Herald added a project: Restricted Project. · View Herald TranscriptMar 2 2022, 2:02 AM

Remark: Targets need to specify CMAKE_ASM_COMPILER_TARGET or UnwindRegistersRestore|Save.S will be assembled for the default target, not the CMAKE_C|CXX_COMPILER_TARGET.
This caused the libunwind miscompile for the clang-ve-ninja bot: https://lab.llvm.org/buildbot/#/builders/91/builds/4728

Damn, that is tricky. Thanks for the heads up. Do you think we should set CMAKE_ASM_COMPILER_TARGET to CMAKE_CXX_COMPILER_TARGET? Or perhaps we could do something like:

if (NOT CMAKE_ASM_COMPILER_TARGET STREQUAL CMAKE_CXX_COMPILER_TARGET)
  message(FATAL_ERROR "I'm sure this is an oversight!")
endif()

if (NOT CMAKE_C_COMPILER_TARGET STREQUAL CMAKE_CXX_COMPILER_TARGET)
  message(FATAL_ERROR "I'm sure this is an oversight!")
endif()

Anything to either avoid the miscompile would be better than the status quo, which is kind of a trap.

Remark: Targets need to specify CMAKE_ASM_COMPILER_TARGET or UnwindRegistersRestore|Save.S will be assembled for the default target, not the CMAKE_C|CXX_COMPILER_TARGET.
This caused the libunwind miscompile for the clang-ve-ninja bot: https://lab.llvm.org/buildbot/#/builders/91/builds/4728

Damn, that is tricky. Thanks for the heads up. Do you think we should set CMAKE_ASM_COMPILER_TARGET to CMAKE_CXX_COMPILER_TARGET? [..]
Or perhaps we could do something like:

if (NOT CMAKE_ASM_COMPILER_TARGET STREQUAL CMAKE_CXX_COMPILER_TARGET)
  message(FATAL_ERROR "I'm sure this is an oversight!")
endif()

if (NOT CMAKE_C_COMPILER_TARGET STREQUAL CMAKE_CXX_COMPILER_TARGET)
  message(FATAL_ERROR "I'm sure this is an oversight!")
endif()

Anything to either avoid the miscompile would be better than the status quo, which is kind of a trap.

Do we really know that the ASM target is always the same as the C|CXX target?
+1 for emitting a warning at least. FATAL_ERROR if we know for sure that these are always the same.