-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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 cargo rustdoc
for passing arbitrary flags to rustdoc
#1977
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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. 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. |
conceputally, 👍 from me. |
-q, --quiet No output printed to stdout | ||
--color WHEN Coloring: auto, always, never | ||
|
||
By default the documentation for the local package and all dependencies is |
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.
I think this may want to customize this text instead of just copy/pasting from cargo help doc
, for example this should probably start out by saying that it is intended to configure the invocation of rustdoc on one crate and not mention much about dependencies up here at the top.
sgtm |
So, I actually want the subcommand to pass the rustdoc flags to all dependencies. Rustdoc output would be weird if only one crate was compiled with a set of flags. For I thought this PR did do that, turns out it doesn't, I'll see if I can make it work so that the args are passed to upstream deps too. (This is why I didn't add a check for multiple targets -- this should behave exactly like cargo doc, just that every rustdoc invocation gets the extra flags) |
I would personally not want to land this with subtly different behavior than Configuration of rustdoc for all crates in the dependency graph is certainly desired, but I think that wants a more principled solution than just an extra command which passes all the flags everywhere. E.g. this is a recipe for all projects having their documentation building step be something like |
Alright, fixed so that it mirrorrs rustc
So there are multiple use cases here. One is for the default build, and one is for specialized builds. For example, I'd prefer if we had both a cargo-config based solution, and a terminal-based solution. The simplest one seems to be allowing |
Yes I agree that passing custom flags shouldn't always involve editing files, but I was mostly just saying that this should follow |
@@ -83,6 +83,7 @@ pub fn execute(options: Options, config: &Config) -> CliResult<Option<()>> { | |||
&options.flag_test, | |||
&options.flag_example, | |||
&options.flag_bench), | |||
extra_rustdoc_args: vec![], |
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.
Cargo tends to favor Vec::new()
over vec![]
currently
(addressed) |
<opts>... will all be passed to the final rustdoc invocation, not any of the | ||
dependencies. Note that rustdoc will still unconditionally receive | ||
arguments such as -L, --extern, and --crate-type, and the specified <opts>... | ||
will simply be added to the compiler invocation. |
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.
s/compiler/rustdoc/
☔ The latest upstream changes (presumably #1991) made this pull request unmergeable. Please resolve the merge conflicts. |
16a8052
to
457e7bd
Compare
Updated. It occurred to me that there's no reason for us to not allow multiple targets for |
The restriction for only one target actually mirrors |
But why would someone care about flags applying "accidentally" to many? These are docs, not code. It makes some sense to want to avoid applying the wrong extra link args, but the rustdoc flags are pretty benign. Besides, it's not possible to filter targets for docs in the current framework. (https://github.com/rust-lang/cargo/blob/master/src/bin/rustc.rs#L82, https://github.com/rust-lang/cargo/blob/master/src/bin/doc.rs#L69). Could be fixed though. |
This is inconsistent with For filtering, that's why I was saying that the |
☔ The latest upstream changes (presumably #1828) made this pull request unmergeable. Please resolve the merge conflicts. |
@Manishearth What's the status of this? I'd love to use this for internal documentation. |
Bit busy right now. I'm not really sure how to add the other flags, and sort of disagree that we need to. |
@Manishearth would you like me to take this over? To add the new flags you'd want to change the compile filter being used and construct it in a manner similar to the other subcommands. |
Sure, take it over. I don't have a lot of continuous time to work on things, and this is at the back of my queue :) (Yeah, I know the overall steps, haven't had the time to look into the specifics) |
This rebases rust-lang#1977 onto master and also tweaks the behavior to match `cargo rustc` when there are multiple targets in play.
Rebased in #2129 |
Quite useful for doing
cargo rustdoc -- --no-defaults
to get a doc package with private items.This is similar to
cargo rustc
, except that the flags passed tocargo rustdoc
are applied to both the main package and dependencies.A friend of mine was looking for this feature, couldn't find a way to do it without directly calling rustdoc. This would probably be useful for using the full configurability of rustdoc in cargo-applications.
r? @alexcrichton