volks73 / cargo-rustc-cfg Goto Github PK

It is possible to specify a toolchain with cargo commands using a +stable syntax after the cargo command but before any subcommands. For example, cargo +nightly rustc --target x86_64-pc-windows-msvc -- --print cfg. It is also possible to specify a target with the toolchain argument, cargo +stable-i686-pc-windows-gnu rustc -- --print cfg. Thus, it would be good to allow users to specify a toolchain in the command.

An error will occur if a Cargo project has multiple targets, i.e. library and one or more binaries defined in the package's manifest (Cargo.toml). Please note, "target" here is not the compiler target but the Cargo target. In this situation, the with_args must be used and the --lib or --bin <NAME> flag or option, respectively, must be added. Otherwise, an error message appears with the cargo rustc command that a single Cargo target must be called in order to pass rustc arguments.

The correct terminology for the "default Rust compiler (rustc) target" is just "host". The "host" is the system and compiler configuration. The target is for cross-compilation, or when the host system is not the target system. Thus, the new method should be renamed to host to make this more obvious.

An error occurs if there is more than one Cargo target defined in a package's manifest (Cargo.toml), so the default is to add the --lib flag to select the library Cargo target. If there is only one Cargo target, and it is a library, then the --lib flag is functionally a "no-op". However, if there is only one Cargo target and it is a binary, or multiple binary Cargo targets are defined with no library target, then another error occurs: "no library targets found in package <PACKAGE_NAME>.

The CargoRustcPrintCfg builder allows for customization of the command to select the appropriate Cargo target to avoid this error, but if this crate is used within another crate, it may not be possible to customize the command for the two cases where the --lib is a problem. So, this crate needs to be smarter about selecting the Cargo target and avoid blindly using the --lib flag.

I am currently thinking of using the cargo-metadata crate to obtain a list of Cargo targets and determine usage of the --lib flag or --bin flags based on the Cargo targets listed.

Unlike the rustc --target <TRIPLE> --print cfg command, the cargo rustc --target <TRIPLE> -- --print cfg will compile all of the dependencies for a project before printing the configuration. This means the target and toolchain must be installed in order for the command to work.

Based on some investigations, it appears there is no way to skip compiling the dependencies and just print the configuration. So, some information and documentation would prevent surprises.

The -Z unstable-options argument is added to the command invocation because the --print option for the cargo rustc subcommand is currently marked as unstable. Once the --print option has been stabilized and the nightly toolchain is no longer required. The -Z unstable-options should be removed from the invocation.

Maybe something fancy with conditional compilation and/or cargo feature flags could be used, but the easiest thing to do for now is to just add a TODO comment to remove the relevant code at the appropriate time.

Three of the doc tests are currently ignored because I cannot get them to work/pass. I get an error that the "+nightly" subcommand is not found, but when I use the dbg! macro on the cmd just before execution, the command looks perfect. The command works when I type it manually into the terminal without any problems. Originally, I thought it was related to the rustc_target and rustc_targets methods, but when I commented this functionality out, it still occurred. I think it might be something with the doc test implementation.