Support a convention for specifying more paths to toolchain binaries

[luser]

Currently cargo supports setting linker and ar in a config file, which is useful but is not always sufficient for cross-compiling crates that build native libraries.

While cross-compiling Servo I found that I had to specify quite a few extra tools to get everything to compile:
https://gist.github.com/luser/a33e5070d1c55a7d2c46fe763a9d1543#file-servo-cross-mac-L59

This was mostly because various crates used different build systems for building native libraries--autotools, cmake, etc. I think it'd be useful if the gcc crate supported a convention for specifying more tools in .cargo/config so that common crates for building native libraries (like cmake) could use that support to drive their builds.

Specifically, I think it would be useful if it allowed at least setting cc, cxx, ranlib, and exposed those values through its API.

[luser]

Interestingly, AFAICT cargo does not expose the values of linker or ar from .cargo/config to build scripts even if they're set.

[alexcrichton]

Yeah currently Cargo doesn't expose linker and/or ar to build scripts, but that probably wouldn't push this over the finish line either as you probably also want to at least read cxx (if not cc before linker). At the very least it'd be good to canonicalize this information all into one location, however, even if Cargo isn't passing the information.

It's probably worth at least doing some parsing of .cargo/config to learn information like this. I'd need to double check to ensure a build script can figure out what directory it was invoked from, however. I forget if that's passed through or not...

[GlenDC]

I'd need to double check to ensure a build script can figure out what directory it was invoked from

That depends on the user. I think you can specify the linker just by giving the name, in case it is in your environment PATH. Personally I don't have it in the path and just gave the full (absolute) location to the file, which would be enough to get the directory, as all the different tools can find in the same directory as the linker.

But even if the user doesn't give the full path, we should be able to get the directory of the executable on all development OS's, no? I know on Unix based systems it's possible with tools like whereis/which, and I suppose Windows has its own system call to get it as well.

[jdub]

I just noticed that gcc doesn't take advantage of the standard-ish TOOLPREFIX or CROSS_COMPILE environment variables in HOST != TARGET scenarios. Would you accept a change to use these when available?

[alexcrichton]

@jdub certainly! I hadn't heard of those before but if they're commonly in use I'd love to have support for them.

[jdub]

I might stick to CROSS_COMPILE for now, as it's unclear if TOOLPREFIX and TOOLCHAIN_PREFIX are sufficiently standard-ish. CROSS_COMPILE appears in Linux, musl, etc. as the binary name plus a hyphen, such that you can use it and get a valid binary name even if it's not set, e.g.

CC := $(CCACHE) $(CROSS_COMPILE)gcc
CXX := $(CCACHE) $(CROSS_COMPILE)g++
AR := $(CROSS_COMPILE)ar

[alexcrichton]

Ok sounds good to me!