OK abandoning this too. Thanks for the extra info.

OK I'll close both backports.

Reading https://llvm.org/docs/DeveloperPolicy.html it looks like I need to submit an patch email? Is that true, or can/will someone with perms see the approval and eventually merge it from phabricator?

While I am fine making -fuse-ld=lld mean "use that lld driver most appropriate for the clang driver", in principle the clang driver and lld driver choices are orthogonal, and I'd want to expose that with something like -fuse-ld=ld.lld to compliment -fuse-ld=lld-link. How does that sound? Should we support -fuse-ld=ld.bfd and -fuse-ld=ld64.lld too?

I am curious, how did this work since there is no longer an lld-link2? Were these tests failing or not being run?

Split out some changes into other diffs. 1 we are stacked on, the other 2 are independent and not stacked on,

Bummer, I didn't realize this had already shipped.

OK I'll happily admit that Autoconf's choices of names is terrible, and that, yes, the names can be defined from two differing perspectives. And, I actually do believe the GCC build system is far inferior, too. But on other points I think we're all talking past each other.

@steven_wu Maybe there is something outside of "build" "host" or "target" that won't suffer from these problems of vantage point? __will_be_built_for_* for a very lengthy example, but hopefully something shorter too?

I'm sure I could fine a GCC example

@steven_wu but what you say is directly contradicted by the GHC example. I'm sure I could fine a GCC example too where some macro with "target" is in the name affects the target of the compiler being built. In the vast majority of programs, no more than one platform need affect preprocessing, but when multiple platforms affect preprocessing, they are *always* named from the perspective of the being-built tool being run.

One that that might make my position clearer is to substitute the name "build", "host", and "target" for "build", "run", and "emit". [A colleague of mine proposed these alternative names and I do think they are vastly more human friendly.]

In D44753#1044935, @bob.wilson wrote:

Sorry that I missed your earlier comment about this. The confusion could only arise in the context of a tool (like a compiler) that is being used for cross-compilation. That is a small fraction of the audience for Clang, and we should design this in a way that makes the most sense for the majority of users. If there's a naming scheme that is better for both, then we should do that, but I don't think this is it.