when cross-compiling, look for RUSTFLAGS_HOST for rustc flags of build scripts

[RalfJung]

Fixes #4423

This does not fix the inconsistency around what is considered a host vs. target build, but instead just uses the existing classification and makes it possible to still set flags for all compiler invocations.

If this approach is acceptable, I can edit environment-variables.md to mention the new variables. Also, if setting target.*.rustflags in ~/.cargo/... is documented anywhere, that documentation should also be amended.

[rust-highfive]

r? @matklad

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

r? @alexcrichton

[alexcrichton]

Thanks for the PR @RalfJung!

The PR itself looks fine to me (although it'd be good to update src/doc as well), but I hesitate in the sense that I don't think there's a lot of precedent here. I think _HOST is fine for small use cases but there's others where it may not always quite work out. For example gcc-rs has variables like CC_x86_64-unknown-linux-gnu for full disambiguation, which is often required for environments where a few targets are being produced.

In that sense there's I think a bit of design to happen here which we may want to not do in an ad-hoc fashion over time. I don't know precisely where we want to end up with this though.

[RalfJung]

I don't see how having such env vars even helps. What I am looking for is setting a finite number of vars such that every build performed by cargo gets the flags from one of the vars. I actually thought this is so trivial that I was shocked to learn that it is not already the case. Having to know the full list of possible targets because we need to set CC_<target> for every one of them sounds like a huge hassle.

More concretely, notice that such target-specific env vars would probably only make sense for the artifact we are building, right? RUSTFLAGS_x86_64-unknown-linux-gnu would be used for --target x86_64-unknown-linux-gnu, and so on. There, we already apply RUSTFLAGS today. This PR, in contrast, is about all the other things that are built -- things that are built on the host no matter the target architecture; namely, build scripts and plugins. So while maybe there's a point in refining RUSTFLAGS as used for the artifact, this PR is about having any variable to control flags for stuff that's not the artifact.

And finally, having target-specific flags is already possible with target-specific selectors in the global cargo config file. Having flags for build scripts / plugins is outright impossible currently.

[RalfJung]

Btw, the issue I am trying to solve here is japaric/xargo#162.

[bors]

☔ The latest upstream changes (presumably #4531) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

Rebased onto current master.

[bors]

☔ The latest upstream changes (presumably #4314) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Ok I'm gonna close this due to inactivity, but it can of course be resubmitted!

[RalfJung]

How is resubmitting going to be helpful? From all I know, this is not blocked by me, is it?

[alexcrichton]

Resubmitting often helps bump priority and/or get attention, something which has sat inert for 6+ months is unlikely to make any progress without changing something.

[RalfJung]

The trouble is that I have no idea what I am supposed to change. :)

Also, the original issue I was trying to work around was fixed, so I don't really have a use-case motivating this change any more (other than "that issue could come back any time"). I guess I'll just hope the entire cross-compilation/build scripts situation will be improved some day ;)

[voltagex]

Hey uh, I still need this.