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

Document Cargo feature flags #3440

Closed
emilk opened this issue Jan 29, 2024 · 5 comments · Fixed by #3478
Closed

Document Cargo feature flags #3440

emilk opened this issue Jan 29, 2024 · 5 comments · Fixed by #3478
Labels
S - docs Awareness, docs, examples, etc.

Comments

@emilk
Copy link
Contributor

emilk commented Jan 29, 2024

document-features is a crate for easily documenting the feature flags in the Cargo.toml file.

@madsmtm madsmtm added the S - docs Awareness, docs, examples, etc. label Jan 29, 2024
@madsmtm
Copy link
Member

madsmtm commented Jan 29, 2024

I'd rather just document them manually, as exemplified in the regex crate.

Also, looking at the feature flags we do have, I think serde, rwh_04/rwh_05/rwh_06 and maybe x11/wayland should be documented in the crate root, while the backend-specific ones should be documented in the relevant platform module.

@madsmtm madsmtm changed the title Document the features flags using document-features Document Cargo feature flags Jan 29, 2024
@emilk
Copy link
Contributor Author

emilk commented Jan 29, 2024

The downside of documenting them manually is that you need to keep the documentation and Cargo.toml in sync, with the ever-looming risk of them diverging. So I recommend the document-feature crate as it makes it very simple to document the features and keep them documented. But 🤷

@daxpedda
Copy link
Member

daxpedda commented Jan 30, 2024

I would also prefer to have the process automated, but I think document-feature comes with it's own set of problems:

  • Guarding it behind a crate feature is probably a bad idea for obvious reasons.
  • Guarding it behind cfg(docsrs) is also a bad idea because we use nightly features with that.
  • So we need something new, cfg(document-feature), which also means that if users are not aware of that when generating their own documentation with cargo doc they will miss out on it.
  • Not guarding it isn't an option because it pulls in proc-macro2, which many of our backends were able to successfully mitigate so far.

None of these are real showstoppers though, just some downsides. I would have preferred to have a tool that checks it in CI instead of a Cargo dependency parsing things in a proc-macro during build. Alternatively a fix in Cargo would do it as well: rust-lang/cargo#2025, rust-lang/cargo#8811.


I don't have a strong opinion either way, but if I had to vote on something it would probably be just doing it by hand.

@dhardy
Copy link
Contributor

dhardy commented Jan 30, 2024

My personal take is that Cargo.toml is the right place to document features because it's the only place you can guarantee all features will be listed.

I'm glad we have dep: syntax now so that optional dependencies can be properly documented as features.

@kchibisov
Copy link
Member

Could we extract features manually from the Cargo.toml when building docs, generate the .md based on that and put inside the target, optionally including/linking to it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S - docs Awareness, docs, examples, etc.
Development

Successfully merging a pull request may close this issue.

5 participants