Cargo: Dépendance facultative lorsqu'une fonctionnalité n'est pas activée.

Créé le 27 juil. 2015 · 3Commentaires · Source: rust-lang/cargo

Certaines bibliothèques peuvent fonctionner sur Rust stable avec des performances dégradées (par exemple sans utiliser NonZero ) ou des capacités limitées (certaines API désactivées). La pratique émergente semble avoir une fonctionnalité unstable ou nightly Cargo pour permettre à l'utilisateur d'opter pour l'utilisation des fonctionnalités Rust instables lorsqu'elles sont disponibles.

Je publie rust-rc comme std::rc::Weak n'est pas encore stable. Pour le moment, il ne semble pas y avoir de moyen d'avoir cette caisse en tant que dépendance par défaut, mais _pas_ lorsque la fonctionnalité unstable est activée. Cela pourrait-il être ajouté à Cargo ?

Notez qu'inverser la valeur par défaut et disposer d'une fonctionnalité stable ne fait que déplacer le problème vers les dépendances qui ne peuvent/devraient être utilisées que sur Rust instable.

A-features

Source

SimonSapin

❤2 👍2

Commentaire le plus utile

Avec la syntaxe [target.'cfg(...)'.dependencies] , cela pourrait être pris en charge simplement en permettant à cfg(feature = "...") de se comporter comme dans le code Rust :

[target.'cfg(not(feature = "std"))'.dependencies]
hashmap_core = "0.1.2"

Actuellement, une telle section est traitée comme activée _quel que soit l'état de la fonctionnalité, ce qui me semble honnêtement être un bogue.

eternaleye le 22 mars 2018

👍8

Tous les 3 commentaires

J'aimerais aussi avoir ça. Dans midr , il existe plusieurs backends (ALSA et/ou JACK sous Linux, CoreMIDI et/ou JACK sous OSX, WinMM sous Windows), et mon plan est d'avoir un indicateur de fonctionnalité jack qui active JACK et désactive le autre (natif). Je voudrais également supprimer la dépendance sur ALSA/CoreMIDI dans le cas de la compilation pour JACK, afin qu'elle puisse même être utilisée si ALSA n'est pas installé sur le système.

Ma première idée était ce qui est demandé ci-dessus, c'est-à-dire simplement désactiver la dépendance alsa-sys si la fonction jack est sélectionnée.

Une alternative à cela est d'avoir une fonctionnalité par défaut (par exemple native ), qui pourrait être désactivée si jack est activé, puis d'avoir des dépendances spécifiques à la plate-forme pour cette fonctionnalité (à savoir alsa-sys sur Linux et CoreMIDI sur OSX), en utilisant quelque chose comme [target.x86_64-unknown-linux-gnu.features] . Il semble également qu'il soit actuellement impossible d'avoir des ensembles de fonctionnalités par défaut spécifiques à la plate-forme cible, ce qui résoudrait également le problème.

Jusqu'à présent, je n'ai pas pu trouver de solution de contournement qui fonctionne sans définir les dépendances/fonctionnalités dépendantes de la plate-forme dans les caisses dépendantes, mais j'ai peut-être oublié quelque chose.

Boddlnagg le 11 août 2015

Avec la syntaxe [target.'cfg(...)'.dependencies] , cela pourrait être pris en charge simplement en permettant à cfg(feature = "...") de se comporter comme dans le code Rust :

[target.'cfg(not(feature = "std"))'.dependencies]
hashmap_core = "0.1.2"

Actuellement, une telle section est traitée comme activée _quel que soit l'état de la fonctionnalité, ce qui me semble honnêtement être un bogue.

eternaleye le 22 mars 2018

👍8

Même cas pour moi :

[target.'cfg(not(feature = "std"))'.dependencies]
heapless = "0.2.7"

[features]
default = ["std"]
std = []

Je veux seulement la dépendance heapless si la fonctionnalité std n'est pas activée.
heapless fonctionne uniquement avec nightly, mais je veux que ma bibliothèque soit compatible avec stable si std est activé.

Le comportement actuel est-il un bogue ou est-il voulu ?