Add support for thumbv4t-none-eabi target (arm-none-eabi tool prefix)

[LunarLambda]

Currently need to to pass .compiler("arm-none-eabi-gcc").archiver("arm-none-eabi-ar") to my Build as cc doesn't know the thumbv4t-none-eabi target, which uses the arm-none-eabi- tool prefix.

On that note, it'd be nice to be able to specify the prefix as a method on Build, rather than through the CROSS_COMPILE environment variable.

[dot-asm]

I don't quite follow. If CROSS_COMPILE is set, then you shouldn't have to .compiler().etc(). You can even set the variable directly in the build script. Prior creating the Build object of course. So why wouldn't that count as a way to specify the prefix?

Either way, I [for one] would argue that deriving the prefix from the linker name would be a better option, as in #685. Unfortunately, as it stands now, the referred #685 wouldn't do the trick for the target in question. Because the linker name is pre-compiled for the target in question and is not available for interrogation. (Making it available is suggested in #693.)

[LunarLambda]

Environment variables are terribly fickle and the crate documentation doesn't mention CROSS_COMPILE at all in any obvious place.

[dot-asm]

Environment variables are terribly fickle

Not if you set it in the build script :-) With std::env::set_var() that is. It affects only the build script [and its descendant processes]... As for it not being documented, well, what can I say... I'm just a cc-rs user too...

[LunarLambda]

I don't think using env::set_var is particularly intuitive or ergonomic, like if you're already suggesting setting it in-code it almost definitely should have a proper method, (even if, as a lazy solution, it did just set that variable).

It just seems strange to me personally to only expose a feature as an environment variable, unless it's the only reasonable way (i.e. RUST_BACKTRACE makes sense to me, but this doesn't)

[dot-asm]

I don't think using env::set_var is particularly intuitive or ergonomic,

Well, I didn't actually mean to say that it is. It's just something that is actually usable today. That's all :-)

[dot-asm]

Just in case to clarify/summarize. The subject is "add support for thumbv4t-none-eabi target." My position (expressed in #693) is that we would be better off if rustc/cargo provided enough information to derive the toolchain prefix. As opposed to solving it in cc-rs on per-target, or even per-build-script basis (as implied here). That's the key.

As for the reference to env::set_var("CROSS_COMPILE"), it's just a suggestion for how to get through the day in case you seek the kind of build predictability as I understand you do. I might be naturally wrong in my understanding :-)