choice of TARGET_CC or HOST_CC does not seem consistent

Hello! So I do a lot of cross compiling. In one case, on Linux x86_64, I need to cross compile for Linux x86_64 (no typo), as I need to 1) use a very specific compiler and 2) have a sysroot I need to use as it has a very specific (and old) version of glibc (from CentOS 6). Notably, I am striving for reproducible builds, something I was having no problems with until I started linking against a rust library :(. (In specific, the library I'm using depends on ring, which has some native code.)

So, the way I'd expect HOST_CC and TARGET_CC to work is that there are essentially two levels of build: there's stuff being built to be used by the build, and then there's stuff being built to be deployed after the build; everything in the former category should use HOST_CC, and everything in the latter category should use TARGET_CC. This is, for example, how other build systems--such as autotools--handles choosing compilers (at worst they print an awkward warning).

Now, with Cargo, when I compile on a macOS machine, I use TARGET_CC to specify my very specific Linux x86_64 compiler, and this works "as expected": any code that is supposed to be run on macOS uses HOST_CC and any code that is supposed to be deployed is built using TARGET_CC. However, when I compile on a Linux x86_64 system, this doesn't happen: instead, as far as I can tell, everything uses HOST_CC always, even stuff that is going to be deployed :(.

I figure the logic here is "I'm on a Linux x86_64 system, and I just need any compiler, right? so why can't I just use the HOST_CC here?", but again: the issue is that I might have some very "good" reason for having different compilers that goes beyond "does it run?" and moves into the world of "does it provide bit-for-bit identical results with some other machine that is also building this code because I want to reproduce that build" or "I have weird glibc requirements".

(This might be related in some way to #3349, btw; but, while I am not entirely sure what build-script-build is, it sounds like that bug is more from long enough ago that TARGET_CC might simply not have existed, and so the issue was more that there was no way to specify this at all, as opposed to that it was being selected in weird ways? FWIW, I don't feel a need for anything lower-level than TARGET_CC: I just want TARGET_CC to always be used as the target cc ;P.)

(FWIW, in this case, I feel like I'm going to be able to come up with a messy workaround for this wherein I detect cases where I think the wrong variable will be used and pass HOST_CC instead, but that isn't viable in the general case: as an example, maybe I want to compile to target some newer platform version than the one I'm currently running on using some version variant switch, in which case the TARGET_CC might generate object files that are invalid on my host system.)

Maybe put most simply: my assertion is that the choice of HOST_CC or TARGET_CC should be based on what I'm intending to do with the thing being compiled, as opposed to what amounts to an unpredictable decision based upon whether the host and target happen to share a triple (which is by no means a guarantee of full compatibility, whether practically or conceptually); the host and target are semantically different from each other in ways unrelated to their platform.

(Note: it is totally possible that this is some issue specific to ring, but I couldn't find any mention of TARGET_CC in their code so I got the impression that they were just asking Cargo to build stuff Cargo was taking care of it; but I also don't know how Cargo packages are formatted and so haven't dug into ring to determine exactly how this is all specified either. So, if this isn't even an issue in Cargo and this is actually an issue with ring, I'm super sorry for wasting your time.)

Start by reproducing the HOST_CC and TARGET_CC behavior for the macOS and Linux x86_64 cases described, including the ring native-code dependency. Read Cargo's compiler-selection handling and compare it with the related discussion in issue #3349. Done means the intended host-versus-target behavior is established and covered by regression tests.