parse required-features from Cargo.tomls for better UX

[LDeakin]

If a package has a binary which requires a feature to build and that feature is not enabled then cargo dist build will fail.

cargo.toml

[[bin]]
name = "bin_name"
required-features = ["feature_to_enable_bin_name"]

cargo dist build output

failed to find bin bin_name (package 0.0.1 (path+file://....)) -- did the cargo
  │ build above have errors?

https://github.com/axodotdev/cargo-dist/issues/274 suggests that this should have been fixed in cargo-dist 0.2.0, but the issue persists.

[Gankra]

The current support for binaries with requires features is for you to use features/all-features/default-features in workspace.metadata.dist/package.metadata.dist (same syntax as cargo dependencies): https://opensource.axo.dev/cargo-dist/book/reference/config.html#features

[Gankra]

Also to be clear here, required-features is a Cargo feature that can only disable a binary being built. It sadly does not tell Cargo "hey if I try to build this binary, flip on these features". I misunderstood it so the comments I made in that issue are unhelpful.😿

[Gankra]

(We could read required-features config and flip on features by default but I'm a bit skittish about confusing things happening if we do that automagically.)

[LDeakin]

Also to be clear here, required-features is a Cargo feature that can only disable a binary being built. It sadly does not tell Cargo "hey if I try to build this binary, flip on these features"

Yes precisely, this is a mechanism to disable including a binary. If the binary feature is not part of the default features, I would expect cargo-dist to not try and package it.

We could read required-features config and flip on features by default

Definitely not, cargo dist should respect the features requested.

[Gankra]

Yes precisely, this is a mechanism to disable including a binary. If the binary feature is not part of the default features, I would expect cargo-dist to not try and package it.

Oh I see you want cargo-dist to auto-hide binaries that lack sufficient features. That's... interesting. My impulse is that cargo-dist should definitely error if you require features and it's not specified. I would however be inclined to still require you to manually opt them out of cargo-dist (basically making you say the same thing twice either way to make sure you understand what you're saying, since required-features causes a ton of confusion).

INTERESTING

[LDeakin]

My impulse is that cargo-dist should definitely error if you require features and it's not specified

I'm not sure if developers would be surprised if a binary isn't packaged if its required features are not enabled, because that would be analogous to the behaviour of cargo itself.

If you are really concerned about it, perhaps a parameter could be added to cargo-dist like:

[workspace.metadata.dist]
# Targets with required-features are not packaged if their features are not enabled.
skip_disabled_targets = true

Though this seems like a hurdle to me. Because if it is false, cargo dist requires that all targets must be packaged and any required features required must be manually specified (the current behaviour).