phosek added a comment. In D110663#3041379 <https://reviews.llvm.org/D110663#3041379>, @MaskRay wrote:
> In D110663#3029577 <https://reviews.llvm.org/D110663#3029577>, @phosek wrote: > >> This is going to break Fuchsia as implemented. We assume that >> `{x86_64,aarch64}-unknown-fuchsia` and `{x86_64,aarch64}-fuchsia` behave >> identically and developers are allowed to use whichever spelling they >> prefer. With this change that's no longer true. This may break other >> platforms that make similar assumptions. > > Are Fuchsia developers specifying `--target=` explicitly? I think that's the > direction we don't want to support. Within Fuchsia source tree, we're trying use normalized triple (that is `${arch}-unknown-fuchsia`) but I'm aware of other projects that target Fuchsia and use different spellings. For example, Rust uses `${arch}-fuchsia`, but they also use `${arch}-unknown-linux-gnu` (rather than `${arch}-linux-gnu`). > I can special case Fuchsia to use the normalized triple, but that's code that > I want to avoid. I don't think this issue is specific to just Fuchsia. Rather it seems to me like the problem is the inconsistent handling of triples on Linux and I'd like to avoid introducing workarounds for other platforms. > From my understanding of D110900 <https://reviews.llvm.org/D110900>, if a > Linux distro prefers `*-linux` to `*-linux-gnu`, we should drop `--target=` > normalization to make this available. > > --- > > I think clang driver does normalization so that OS and environment checks can > work , otherwise the constructor `Triple::Triple` can be fooled to use > `unknown`. > This does not mean that we should use normalized paths for include and > library paths that users don't explicitly specify. > > Some ideas that normalization may not be great. Different platforms may > prefer different normalization styles. For example, llvm-project's old > `config.guess` may prefer the `unknown` vendor while newer `config.guess` > prefers the `pc` vendor. redhat may prefer `*-linux` instead of > `*-linux-gnu`. If we need to do normalization for include and library paths, > we need to encode many rules. If we avoid normalization we can save much code > and be less surprising. That's why I'd prefer the idea I implemented in D101194 <https://reviews.llvm.org/D101194> where we let each driver handle the normalization rather than trying to come with a single universal way that apparently doesn't exist. We would also provide a default that would be `llvm::Triple::normalize` so only the platforms that want to deviate from that would need to implement a custom logic. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110663/new/ https://reviews.llvm.org/D110663 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
