-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --exclude flag #4031
Add --exclude flag #4031
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First contribution, would really appreciate if somebody could answer my questions.
src/bin/build.rs
Outdated
let spec = match (options.flag_all, &options.flag_exclude) { | ||
(true, exclude) if exclude.is_empty() => Packages::All, | ||
(true, exclude) => Packages::OptOut(exclude), | ||
(false, exclude) if !exclude.is_empty() => panic!("--exclude can only be used together \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would I return a proper error here? More specifically, should I build the CargoError
myself or is there some convenience function? Can I use the bail!
macro from there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, bail!
is for this use case:
Lines 136 to 145 in 13d92c6
let cfg = match color { | |
Some("auto") => Auto, | |
Some("always") => Always, | |
Some("never") => Never, | |
None => Auto, | |
Some(arg) => bail!("argument for --color must be auto, always, or \ | |
never, but found `{}`", arg), | |
}; |
src/bin/build.rs
Outdated
Packages::All | ||
} else { | ||
Packages::Packages(&options.flag_package) | ||
let spec = match (options.flag_all, &options.flag_exclude) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This match
would be used in many subcommands. May I place it in cargo::util
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could add Packages::from_flags(flag_all, flag_exclude) -> CargoResult<Packeges>
.
@@ -43,6 +44,7 @@ Options: | |||
-h, --help Print this message | |||
-p SPEC, --package SPEC ... Package to build | |||
--all Build all packages in the workspace | |||
--exclude SPEC ... Exclude packages from the build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems pretty verbose to manually handle conflicts / requirements of flags. Is there a way to let docopt
do this? There is currently sort of a bug when executing cargo build -p whatever --all
: The -p
is silently ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to let docopt do this?
Basically we need to switch to clap, and hopefully get rid of a lot of duplication along the way. But this is a hard task :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically we need to switch to clap
Oh it is desired to switch to clap
? It's good to hear that! Is there someone working on it already? If not, I'd love to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there someone working on it already?
I've tried to do that, but haven't arrived at something very satisfying :)
It would be super if you would be able to pull this off!
fb72d95
to
82cc47e
Compare
I'd say this is ready for review. |
@alexcrichton what do you think about it? I feel that we definitely need something like this, but I am worried that we will have three flags ( Hm, maybe we want |
@matklad is "-foo" allowed as argument? If that's the case, I agree that it makes more sense to only have one flag for all of them. Just used |
Thanks for the PR @torkleyy! This seems fine to me, @matklad we've got enough flags at this point for "target selection" that it may make sense to basically house their documentation elsewhere at some point. Do you think canonicalizing in one |
☔ The latest upstream changes (presumably #4050) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased |
Yeah,
Are we excluding Another option for flag name is |
@matklad I feel excluding a module would be a cheat somehow, so I wouldn't expect it to be possible with cargo. Also you can easily read the description of |
It seems we got platform-specific behavior here: I implemented a test which checks for this pattern: "[..] Compiling bar v0.1.0 ([..])\n\
[..] Compiling foo v0.1.0 ([..])\n It matches on Linux, however on Windows it seems to compile the crates the other way around. EDIT: Now it even fails locally, so apparently behavior has changed. Fixing.. |
I bet Hm, what would happen if you compile |
Oops, thought about this, but completely forgot it! I'm not sure actually. I think the current behavior is just compiling it if it's a dependency. |
Let's assign @alexcrichton to this :) |
📌 Commit 9ad240b has been approved by |
⌛ Testing commit 9ad240b with merge 50791b8... |
💔 Test failed - status-travis |
Fixed (it failed because it expected a "filtered out" argument). |
@bors: r+ |
📌 Commit b356af0 has been approved by |
⌛ Testing commit b356af0 with merge 9b856c7... |
💔 Test failed - status-travis |
Allows to exclude packages in conjunction with --all.
Huh? It works for me, even after rebasing onto |
by using with_stderr_contains because parallel build may mix up the lines. Additionally, remove the last line of the benchmark.
@bors: r+ Ah yeah I think that's a very recent change on nightly |
📌 Commit dee3c2e has been approved by |
Add --exclude flag Allows to exclude packages in conjunction with --all. Addresses #2878
☀️ Test successful - status-appveyor, status-travis |
…hton Support --exclude option for `cargo doc` I think this should have been implemented when the feature was added for other commands. Probably just an oversight. cc #4031 r? @alexcrichton
Allows to exclude packages in conjunction
with --all.
Addresses #2878