MyCrate
に取り組んでいると想像してください。これは、デフォルト機能X
を持つクレートA
に依存しています。
--no-default-features
$を使用して$ MyCrate
をコンパイルした場合、クレートA
は、機能X
を有効にしてビルドされたままです。
これは煩わしいですが、次のようなCargo.tomlを使用して回避することができます。
[dependencies.A]
version = "*"
default-features = false
ただし、 A
が独自のデフォルト機能を持つ別のクレートB
$に依存している場合、このソリューションは機能しません。 この場合、 B
のデフォルト機能を無効にすることはできないようです。 言い換えれば、間接的な依存関係のデフォルト機能を無効にすることは不可能のようです。
私の特定の動機付けのケースは、貨物を介して使用される場合、libcが不必要にlibstdに依存することです。
これが、Cargoでメインクレート自体の依存関係から機能を再エクスポートできる理由です。 依存関係は、パブリックインターフェイスではなく、プライベート実装の詳細を目的としています。機能をエクスポートする場合は、明示的にオプトインする必要があります。
@alexcrichton :
では、エンドユーザーがネストされた機能をオプトアウトすることを選択できるようにするために、すべてのクレートに[dependencies.*] default-features = false
が含まれることになっていますか? それはかなり鈍いようです。
ええ、それが意図です。 default
機能を作成すると、ほぼ常にオンになるため、必ずしもすべてのオプション機能を対象としているわけではありません。
最も参考になるコメント
@alexcrichton :
では、エンドユーザーがネストされた機能をオプトアウトすることを選択できるようにするために、すべてのクレートに
[dependencies.*] default-features = false
が含まれることになっていますか? それはかなり鈍いようです。