You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
It would be a lot easier if Cargo just printed the compiler configuration with some kind of cargo rustc --cfg -like command and flag. The issue for determining the Cargo target is because Cargo has a gate check that passing arguments to the compiler, i.e. using the -- argument, must have a single Cargo target selected.
Thus, I created the rust-lang/cargo#8923 in the Cargo project. This would greatly simplify the implementation of this crate and make it similar to the cargo-metadata crate. To this end, I started digging through the Cargo source code to implement a cargo rustc --cfg command. This lead to PR rust-lang/cargo#9002. If and when this PR is merged, this issue will be easily addressed but the crate will radically change in implementation. It will also be a while before the --cfg feature is stabilized...if it is accepted and merged. So, I am holding off on applying too much attention to this issue and crate until the fate of the PR for Cargo is more certain.
The rust-lang/cargo#8923 issue and PR rust-lang/cargo#9002 have been resolved and merged, respectively. This greatly simplifies the implementation of this crate, but it currently requires Cargo nightly to be installed since it will take some time for the changes to Cargo to propagate to the stable channel. The most recent merge and changes (62c90ea) account for multiple targets and the new nightly features. The API has changed significantly, but it appears to be working. There are a couple of doc tests that need to be fixed, too, but this specific issue and the previously discussed sources of headaches have been resolved.
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.The text was updated successfully, but these errors were encountered: