Syntax of `rustc --cfg` with key and value is obscure.

[vext01]

Hi,

I was recently defeated by rustc --cfg.

rustc -h says:

--cfg SPEC      Configure the compilation environment

Hrm, well I know that stuff like --cfg var should work, but that I should also be able to assign a value:

$ rustc --cfg key=val -
error: invalid `--cfg` argument: `key=val` (expected `key` or `key="value"`)

$ rustc --cfg key="val" -
error: invalid `--cfg` argument: `key=val` (expected `key` or `key="value"`)

Eh? I passed exactly what the error asked. And obviously the backticks can't form the solution, as they'd open a sub-shell.

The solution is to use: rustc --cfg 'key="val"'

The quoting is very specific.

Swapping the single and double quotes won't work:

$ rustc --cfg "key='val'" -
error: character literal may only contain one codepoint
 --> <quote expansion>:1:5
  |
1 | key='val'
  |     ^^^^^
help: if you meant to write a `str` literal, use double quotes
  |
1 | key="val"
  |     ^^^^^

And oddly, quoting the value is ok, but not the key:

$ rustc --cfg '"key"="val"' -
error: invalid `--cfg` argument: `"key"="val"` (expected `key` or `key="value"`)

I find this wholly unexpected and I had to grep the source code to find out how to use the argument :(

So are the current limitations of the interface intentional?

If so, we should improve the -h doc and error message.

If not, what do we want? Should --cfg accept:

• key=val
• 'key="val"
• "key='val'"
• '"key"="val"'
• "key=val"

Thanks.

[ehuss]

It is key="val", or more specifically, the MetaNameValueStr grammar where it is IDENT=STRING where STRING is a Rust string literal (or raw string). The escaping and quoting rules will depend on which shell you use, or if using a programmatic API it depends on the escaping rules of whatever language you are using. For bourne-style shells, backslash the double quotes (key=\"val\"), or enclose the entire thing in single quotes ('key="val"').

It may be difficult to provide a general suggestion as different environments will need different escaping. It could maybe include a hint to check that it the value is properly escaped for whatever environment you are in, but I'm not sure if that would be helpful.

FWIW, the documentation does include some examples, but they don't work in powershell, for example.

[ninjasource]

Hi, I'm also struggling a little with this syntax and was wondering if I am misunderstanding how to use the config file in the .cargo folder.

I am trying to go from this
cargo build --features 52840
to this
cargo build

Why? Because that is the feature I want to use for the project I am working on and don't want to have to pass it to the command line every time. The only way I can achieve this right now is to set the following in my Cargo.toml file:

[features]
default = ["52840"]

However, this doesn't seem right to me and I want to see if the same feature could be defaulted in my .cargo\config file which I wouldn't inadvertently check in. So I added the following code (escaping was required, thanks Eric):

[build]
rustflags = "--cfg feature=\"52840\""

Cargo accepts this but seems to ignore it unfortunately. A call to cargo build --verbose confirms this behavior. Any ideas?

PS. If anyone else comes across this and wants to know more about cargo features (can be difficult to search for) and cargo configuration this a good place to start:
https://doc.rust-lang.org/cargo/reference/features.html
and
https://doc.rust-lang.org/cargo/reference/config.html

[ehuss]

@ninjasource Placing that in a config, it seems to work for me (I see --cfg 'feature="52840"' passed to rustc). You might want to check that is in the correct location. However, I would not recommend setting features that way, since it will pass that cfg to every rustc invocation for every dependency. If you want a local default, I would suggest creating an alias.

[ninjasource]

Using an alias in my .cargo/config file worked very well, thanks!

[alias]
b = "build --features 52840"

And then cargo b from the terminal. Would have been nice to alias build itself but oh well.

"However, I would not recommend setting features that way, since it will pass that cfg to every rustc invocation for every dependency."

So I guess calling cargo build --features xyz applies the feature to the code in the current project (package) only and not the dependent crates. Makes sense.

[tgross35]

If it doesn't support dashes, it would also be nice if it just said so :)

$ rustc foo.rs --cfg "foo-bar"
error: invalid `--cfg` argument: `foo-bar` (expected `key` or `key="value"`)
$ rustc foo.rs --cfg "foo_bar"