Skip to content
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

Get intralink information from rustdoc #177

Open
orium opened this issue Aug 16, 2023 · 4 comments · May be fixed by #236
Open

Get intralink information from rustdoc #177

orium opened this issue Aug 16, 2023 · 4 comments · May be fixed by #236

Comments

@orium
Copy link
Owner

orium commented Aug 16, 2023

No description provided.

@RReverser
Copy link

Trying out the branch - looks pretty good so far, but one thing I'm finding missing is ability to pass custom Cargo args (maybe as cargo rdme -- ...[cargo options]...?) as some projects require --features to be passed in to compile at all.

@orium
Copy link
Owner Author

orium commented Jan 23, 2024

I'm glad you gave it a try. There's still some work to do (not to mention the code is really messy right now), but I should be able to work on it occasionally.

I was thinking of starting simply with --all-features. I might add a first class features option (both in the command line and config file) in the future that can override that default behavior.

Not sure about arbitrary cargo flags, at least for now. I can be convinced otherwise if there are compelling use cases.

@RReverser
Copy link

I was thinking of starting simply with --all-features.

I think that might be problematic, as a lot of repos tend to declare features like nightly or no_std or unstable etc, which are usually not desirable and might break more things than --all-features fixes.

Not sure about arbitrary cargo flags, at least for now. I can be convinced otherwise if there are compelling use cases.

Yeah I can't really think of other compelling cases for now, but it is a pattern that other cargo-based tools tend to follow, so figured might be easiest to support. Explicit --features sounds good though.

@orium
Copy link
Owner Author

orium commented Jan 23, 2024

I think that might be problematic, as a lot of repos tend to declare features like nightly or no_std or unstable etc, which are usually not desirable and might break more things than --all-features fixes.

That's true. I'll have an explicit features options and default to whatever default features the package has.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants