New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support a convention for specifying more paths to toolchain binaries #82

Open
luser opened this Issue Jun 22, 2016 · 7 comments

Comments

4 participants
@luser

luser commented Jun 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@luser

luser Jun 22, 2016

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

luser commented Jun 22, 2016

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 24, 2016

Owner

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...

Owner

alexcrichton commented Jun 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@GlenDC

GlenDC Jul 31, 2016

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.

GlenDC commented Jul 31, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jdub

jdub Oct 9, 2016

Contributor

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?

Contributor

jdub commented Oct 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 10, 2016

Owner

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

Owner

alexcrichton commented Oct 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jdub

jdub Oct 10, 2016

Contributor

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
Contributor

jdub commented Oct 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 10, 2016

Owner

Ok sounds good to me!

Owner

alexcrichton commented Oct 10, 2016

Ok sounds good to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment