bob.wilson added a comment. 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.
When dealing with a cross compiler, there is a need to distinguish the "target" where the compiler will run (which as you point out is typically referred to as the "host") from the "target" code produced by that cross compiler. There are two points in time: (1) when compiling the cross compiler, and (2) when running the cross compiler. In step (1), the compiler will be invoked with a "-target" option that specifies the "host". The preprocessor checks are compile-time checks, so there no way that one of these macros in the source code of the compiler itself could be referring to the target in step (2). The compiler option name will be "-target" regardless. Using "target" names in the macros is consistent with that compiler option name. When dealing with anything other than a cross compiler (or similar cross-target development tool), the "host" terminology is not commonly used. The obvious connection between these macros and the value specified by the "-target" option would be lost. I really don't think this is a good alternative. Repository: rC Clang https://reviews.llvm.org/D44753 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
