Ensure that cross compiler info is passed to GYP correctly

[mcoffin]

Right now, libuv will always be built for the host system (at least when building on OSX) because the information about the cross compiler is never actually passed to GYP. I don't know how anybody has been managing to build cross compilers with this.

Note that, at least on OSX, there is a bug in GYP that will send clang flags to non-clang compilers and it will still attempt to use Xcode's libtool, so this doesn't completely fix the problem of cross-compiling on an OSX host, but it's a start.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

[mcoffin]

On second thought, it might be easier to switch over to using the autotools build system with something like this:
$(S)src/libuv/configure --disable-shared --enable-static --host=$(1) --disable-dtrace

Thoughts?

[alexcrichton]

We currently don't want to pick up a dependency on autotools, and libuv doesn't check in the configure script by default.

I'm curious, but what makes you think that libuv is always build for the host architecture? We have a number of cross-compiling bots which cross architectures quite frequently (even to android!). Is that because we "cross compile" with -m32 and -m64?

[mcoffin]

Well, when I did configure with --target=arm-unknown-linux-gnueabi, then run a make, in the $BUILD_DIR/arm-unknown-linux-gnueabi/rt/libuv folder, in libuv.target.mk, CC.target = clang and CXX.target = clang++. After this edit, it correctly sets CC.target and CXX.target without harming CC.host and CXX.host.

EDIT: My host system is OSX, hence clang on the host, but my arm-linux-gnueabi toolchain is GNU.

[alexcrichton]

Ah interesting! Sounds good to me then, thanks!

[bors]

saw approval from alexcrichton
at mcoffin@bcc4ee0