Allow supplying arbitrary arguments to rust via the cargo's command line

[codyps]

This is useful for the case where we need to supply certain settings for (for example) a cross build to work properly.

Right now to supply linker & ar, one needs to generate a config file and hope that the project isn't already using the config file for something else. It would be much cleaner if cargo accepted arguments that overrode the contents of the config file.

As I expect we may end up with more cases than linker & ar, I'd prefer a more general interface (like the title of this issue proposes).

[steveklabnik]

This has already been explicitly rejected a number of times.

[codyps]

@steveklabnik the general (any argument) interface?

Then what about just the linker and ar? As long as cargo keeps adding/updating arguments to match what rustc expects, I've don't have a serious complaint (it just sounds like more work).

Edit: also, if you could supply the issue numbers for the previous rejections, that would be much appreciated.

[alexcrichton]

As @steveklabnik, this has been discussed before.

I'm going to close this as a dupe of #595 and #544. I expect the use cases here will fall under the umbrella of #595. We don't necessarily want to pollute the top-level command with every single flag possible, but we certainly want to allow this level of configuration!

[codyps]

In this particular case I'm asking about 2 options that we're already able to set via .cargo/config.

My primary complaint is that .cargo/config is a file that the developer may have checked in, which could complicate buildscripts generating their own.

On that note: Is the accepted practice to generate a .cargo/config file to set linker & ar?

I'm not seeing how subcommands solve anything, it just looks like an attempt to pretend we're isolating dependence on the compiler. It's unclear to me why having them is any better than allowing arbitrary flags to 'cargo build'

[alexcrichton]

The compiler itself tries very hard to prevent passing arbitrary flags to the linker for pretty much the same reasons that cargo tries hard to prevent passing arbitrary flags to the compiler itself. Various flags tend to interoperate in obscure ways which make future extensibility very tough to reason about. Cargo is explicitly avoiding the "just pass these 10 flags to compile my package" problem as much as possible (as is rustc itself).

If we were to allow arbitrary linker flags, then some things that could go awry are:

• The arbitrary flags may not handle dylibs vs staticlibs
• Cross compilation may not be handled by the arbitrary flags
• Cross-platform-ness are almost certainly not handled

These aspects are all handled by Cargo seamlessly today, and it should be able to do it into the future as well.

I'm not currently aware of whether many projects generate .cargo/config at this time, or whether they check it in. I would expect it to be somewhat common for top-level projects to have a top-level Makefile which does something like generate a .cargo/config, however, to tailor to the specific project's needs.

Essentially the goal of Cargo is for repeatable builds across all machines, platforms, and architectures, but we still want to allow configuration for the niche tasks that come up often. Right now Cargo just needs some improvement on the configuration aspect of things!