--crate-type does not override lib properties on manifest

[bltavares]

I've faced this recently, and I was surprised by the --crate-type flag behavior. I'm trying to work on a cross-platform library building script to be added on projects on crossgen and it would be really nice if we could contain all the cross-platform bits on the build script.

The Cargo.toml was a default --lib project:

[project]
name = "example"
version = "0.0.1"

[lib]

[dependencies]

When compiling with cargo rustc --lib --release -- --crate-type staticlib I expected this to take over the manifest and add the extra output type. To my surprise, no libexample.a was produced tho.

During the experiments, passing in an invalid crate type as RUSTFLAGS seems to show that cargo is passing multiple --crate-type options down to rustc:

$  RUSTFLAGS="--crate-type example" cargo rustc --lib --release
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --crate-type example --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: unknown crate type: `example`

Should the --crate-type override what is defined on cargo manifest? Is this something to add on the cargo rustc argument list instead of the other side of --?

This would help a lot to output different targets, such as C libs and wasm.

There are related issues:

• Ability to set crate-type depending on target #4881
• LTO ignored for all crate types when building multiple crate types and one doesn't support it rust#51009

[bltavares]

This seems to come from this line:

cargo/src/cargo/core/compiler/build_context/target_info.rs

Lines 85 to 90 in ce455cd

	let crate_type_process = process.clone();
	const KNOWN_CRATE_TYPES: &[&str] =
	&["bin", "rlib", "dylib", "cdylib", "staticlib", "proc-macro"];
	for crate_type in KNOWN_CRATE_TYPES.iter() {
	process.arg("--crate-type").arg(crate_type);
	}

Am I heading to the right direction?

[alexcrichton]

Thanks for the report! Unfortunately though --crate-type will not work in RUSTFLAGS, because it affects output artifacts Cargo needs to know about it ahead of time, not through RUSTFLAGS.

We could improve the error message here though for sure!

[bltavares]

@alexcrichton thanks for replying.

In regard of the expected behavior for the flags. Should a lib that have not defined a crate-type produce both the rlib and staticlib if I call cargo rustc --release -- --crate-type staticlib?

Nowaday, both type of creates are produced. I would expect that the flags override whatever is defined on Cargo.toml, not combined.

This also means that it is also not possible to pass cargo rustc --release -- --crate-type staticlib -C lto, as if there is a rlib on the build plan the feature gets disable.

What is the expected behavior of the CLI flag?

[alexcrichton]

@bltavares it's unfortunately basically not expected for manual specification of --crate-type to work at all. Cargo treats rustflags as a black box, and --crate-type is one of those flags which can just cause compilation to go awry in a whole manner of ways.

[bltavares]

I think it was a mismatch of expectations more than the error message.

From Rust Docs:

If one or more command line flags are specified, all crate_type attributes will be ignored in favor of only building the artifacts specified by command line.

This looks to be applied to rustc only (if I understood it correctly), while I had the expectation to also be applied to cargo rustc.

Should I focus on a workaround editing the Cargo.toml to change the crate-type attribute on those build phases instead of making --crate-type a flag which cargo knows about?

[alexcrichton]

Unfortunately there's not really a great way forward for something like this, but if editing Cargo.toml works for now that's probably "best", although it's by no measure a great solution

[bltavares]

Given how hard this would be, I would be ok to close this issue, even tho the error message is confusing.

Would it be ok if I open a PR on Cargo with a note on the docs regarding this behavior?

[alexcrichton]

Ok sounds good to me! And certainly yeah, PRs improving docs are always appreciated!