custom_build: map the CFLAGS and CC variables for HOST builds

[codyps]

If a build.rs script uses gcc-rs, CC and CFLAGS are used to find the
c compiler and flags. Often, host & target will have different flags
and compilers.

Without this mapping (which allows the use of HOST_CC and HOST_CFLAGS),
it was imposible to specify the compiler and cflags to use for the host
while doing cross builds, and gcc-rs would attempt to use the target
compiler and cflags, typically failing.

We preserve the previous behavoir when the HOST_CC and HOST_CFLAGS
variables are unset, though I'm not sure if this is a good idea unless
host happens to equal target. We may want to restrict the fallback in
the future.

[alexcrichton]

This is actually something I consider to be a fault of gcc-rs, not of Cargo. For example there's no particular reason that we single out CC/CFLAGS and not AR/CXX/CXXFLAGS/LD/etc. Would you be ok moving this logic (probably via CC_$triple) to gcc-rs?

[codyps]

Yep, it doesn't seem like quite the right thing to do, but it does get me my HOST/TARGET split without needing to be careful about triples :)

I'm okay with tweaking gcc-rs instead, but:

• creating env variables that contain '-' (as triples do) via the shell is not fun (have to use env or some other program to create them indirectly). I suppose we could do some s/-/_/.
• users need to know the triple rust is using for their system (not a problem for my use case as I'm generating all the triples, but for casual use this could be problematic).

[alexcrichton]

I was thinking that for example gcc-rs would look at CC_i686_unknown_linux_gnu and then CC to handle cross compiling. That way by default you wouldn't need to set anything in most cases (and never for the host platform), but you could override specifically for targets.

[steveklabnik]

This also seems to be gcc-rs's fault, not Cargo's fault.

[steveklabnik]

Also to me, that is. I need more coffee.

[codyps]

Closing in favor of gcc-rs pr.