flag for `cargo add` to add platform specific dependencies

[bindsdev]

Problem

Currently, there is no support for adding platform specific dependencies (such as [target.'cfg(windows)'.dependencies]) using cargo add.

Proposed Solution

Add a --cfg option that allows the user to specify the whole desired cfg predicate.

Examples:

• cargo add windows --cfg windows
• cargo add raw_cpuid --cfg any(target_arch = "x86", target_arch = "x86_64")

Notes

• Currently, since cfg dependency specifications only are supported using platform predicates, one might think that the option should be named differently. But, in case other cfg pairs/options become supported in the future, the name of the flag allows for it to also include those without confusion for its name being named after the fact it specifies platform specific dependencies only.

[bindsdev]

@rustbot claim

[epage]

@akabinds FYI this has not been marked as Accepted and there are likely things still left to resolve, like what the flag should be called. Starting on this now might lead to extra churn during review as we settle those kind of questions.

[bindsdev]

@akabinds FYI this has not been marked as Accepted and there are likely things still left to resolve, like what the flag should be called. Starting on this now might lead to extra churn during review as we settle those kind of questions.

I understand. I just wanted to claim it because I want to implement it if it is accepted. But, I had a quick question. I was looking around the code base for relevant code to help implement this. I found that this feature seems to already have tests in the test suite using the existing --target flag:

cargo/tests/testsuite/cargo_add/target_cfg/mod.rs

Lines 8 to 25 in a66f123

	#[cargo_test]
	fn target_cfg() {
	init_registry();
	let project = Project::from_template(curr_dir!().join("in"));
	let project_root = project.root();
	let cwd = &project_root;
	snapbox::cmd::Command::cargo_ui()
	.arg("add")
	.arg_line("my-package1 my-package2 --target cfg(unix)")
	.current_dir(cwd)
	.assert()
	.success()
	.stdout_matches_path(curr_dir!().join("stdout.log"))
	.stderr_matches_path(curr_dir!().join("stderr.log"));
	assert_ui().subset_matches(curr_dir!().join("out"), &project_root);
	}

But, when attempting to add platform-specific dependencies this way in my own project to test, it seems to not work. Has this been implemented already, but not present in a release?

[epage]

Huh, I thought we had this; I should have checked rather than assuming the issue author hadn't missed it.

But, when attempting to add platform-specific dependencies this way in my own project to test, it seems to not work. Has this been implemented already, but not present in a release?

Could you provide more details as to what didn't work?

[bindsdev]

Could you provide more details as to what didn't work?

My shell was giving me an obscure error after running it. It seems like all I had to do was wrap the cfg predicate in quotations and it worked fine. But, I ran this to test:

> cargo add --target cfg(windows) serde
zsh: unknown file attribute: i

If I did --target 'cfg(windows)', it worked fine.

I'm not sure if this workaround is needed on other shells or if this is even an issue on other shells.

[weihanglo]

I believe different shells have different ways to escape things. If that works for you, seems like this issue is not really an issue as cargo-add already supports that?

[bindsdev]

I believe different shells have different ways to escape things. If that works for you, seems like this issue is not really an issue as cargo-add already supports that?

Indeed. But should it not be at least documented that quotations might be needed based on the shell?

[epage]

That gets into an interesting line of how much do we document how to use each users system vs users knowing it being an expectation in using cargo.

[weihanglo]

It helps. However, there may be more flags needing that hint. If we start doing so, does that imply we require all possible flags having that hint for consistency? Personally I would probably avoid that.

We do have --package getting that hint already, though it is a bit different: the doc mentions * which may expand to valid shell glob, which makes it harder to debug. In contrast, target cfg syntax usually errors out before cargo get executed.

$ cargo build --bin *
error: unexpected argument 'CODE_OF_CONDUCT.md' found

Usage: cargo build [OPTIONS]

For more information, try '--help'.

$ cargo add tokio --target cfg(windows)
bash: syntax error near unexpected token `('

To me, even the hint in --package/--exclude is a bit too verbose 😆.