[PATCH] D86313: [runtimes] Allow LLVM_BUILTIN_TARGETS to include Darwin

[Shoaib Meenai via Phabricator via llvm-commits]

smeenai added a comment.

Okay, I would argue that this version of the change is much better than the current situation. In particular, it disallows the loophole of specifying a triple for a particular platform instead of "darwin", and it forces users of "darwin" to acknowledge they understand how the Darwin compiler-rt build works by setting a particular variable (and it still disallows multiple Darwin triples). Lemme know what you think.

Should this be enforced for LLVM_RUNTIME_TARGETS in addition to LLVM_BUILTIN_TARGETS?

In D86313#2229269 <https://reviews.llvm.org/D86313#2229269>, @phosek wrote:

> I agree that the current situation is not optimal, I was never happy with the `default` case which is confusing for a lot of people I talked to. I would like to come up with a better solution, but I'm not sure if special casing the `x86_64-apple-darwin` is sufficient though. With Apple Silicon, I assume we're going to be building runtimes as universal binaries that target multiple architectures.
>
> We could consider completely decoupling runtimes from targets. Originally, each runtime build was identified only by its target, so you'd use `RUNTIMES_${target}_${variable}` to set target-specific variables. That became insufficient when we introduced the support for multilib, so now you also have a name and you can use `RUNTIMES_${target}+${name}_${variable}`. We could switch to `RUNTIMES_${name}_${variable}` and it'd be the responsibility of the user to set the target explicitly if they want it (FWIW it's something we already have to do in our build <https://github.com/llvm/llvm-project/blob/master/clang/cmake/caches/Fuchsia-stage2.cmake#L101> anyway because of Windows where the CMake behavior when you set `CMAKE_${LANG}_COMPILER_TARGET` breaks the build). If not, they get the default behavior, matching the `default` case today. What do you think?

To clarify, what would be setting `${name}` in this scenario?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86313/new/

https://reviews.llvm.org/D86313