Cargo: Optionale Abhängigkeit, wenn eine Funktion *nicht* aktiviert ist.

Erstellt am 27. Juli 2015  ·  3Kommentare  ·  Quelle: rust-lang/cargo

Einige Bibliotheken können auf stabilem Rust mit verminderter Leistung (zB ohne NonZero ) oder eingeschränkten Fähigkeiten (einige APIs deaktiviert) laufen. Die aufkommende Praxis scheint eine unstable oder nightly Cargo-Funktion zu haben, die es dem Benutzer ermöglicht, sich für die Verwendung instabiler Rust-Funktionen zu entscheiden, wenn sie verfügbar sind.

Ich veröffentliche rust-rc als std::rc::Weak nicht stabil ist. Im Moment scheint es keine Möglichkeit zu geben, diese Kiste standardmäßig als Abhängigkeit zu verwenden, aber _nicht_, wenn die unstable Funktion aktiviert ist. Könnte dies zu Cargo hinzugefügt werden?

Beachten Sie, dass das Umkehren der Standardeinstellung und das Verwenden einer stable Funktion das Problem nur auf Abhängigkeiten verschiebt, die nur auf instabilem Rust verwendet werden können/sollten.

A-features

Hilfreichster Kommentar

Mit der [target.'cfg(...)'.dependencies] Syntax könnte dies einfach dadurch unterstützt werden, dass sich cfg(feature = "...") wie in Rust-Code verhält:

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

Derzeit wird ein solcher Abschnitt _unabhängig_ vom Funktionsstatus als aktiviert behandelt, was mir ehrlich gesagt wie ein Fehler vorkommt.

Alle 3 Kommentare

Das hätte ich auch gerne. In midir gibt es mehrere Backends (ALSA und/oder JACK unter Linux, CoreMIDI und/oder JACK unter OSX, WinMM unter Windows), und mein Plan ist es, ein jack Feature-Flag zu haben, das JACK aktiviert und deaktiviert. andere (einheimische) Ich möchte auch die Abhängigkeit von ALSA/CoreMIDI beim Kompilieren für JACK entfernen, damit es sogar verwendet werden könnte, wenn ALSA nicht auf dem System installiert ist.

Meine erste Idee war, was oben verlangt wurde, dh die Abhängigkeit von alsa-sys einfach zu deaktivieren, wenn die Funktion jack ausgewählt ist.

Eine Alternative dazu ist ein Standardfeature (zB native ), das deaktiviert werden könnte, wenn jack aktiviert ist, und dann plattformspezifische Abhängigkeiten für dieses Feature zu haben (nämlich alsa-sys unter Linux und CoreMIDI unter OSX) mit etwas wie [target.x86_64-unknown-linux-gnu.features] . Es scheint auch derzeit unmöglich zu sein, zielplattformspezifische Default-Feature-Sets zu haben, die das Problem ebenfalls lösen würden.

Bisher konnte ich keine Problemumgehung finden, die funktioniert, ohne plattformabhängige Abhängigkeiten / Funktionen in abhängigen Kisten zu definieren, aber ich habe möglicherweise etwas übersehen.

Mit der [target.'cfg(...)'.dependencies] Syntax könnte dies einfach dadurch unterstützt werden, dass sich cfg(feature = "...") wie in Rust-Code verhält:

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

Derzeit wird ein solcher Abschnitt _unabhängig_ vom Funktionsstatus als aktiviert behandelt, was mir ehrlich gesagt wie ein Fehler vorkommt.

Gleicher Fall bei mir:

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

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

Ich möchte nur die Abhängigkeit von heapless wenn die Funktion std nicht aktiviert ist.
heapless funktioniert nur mit Nightly, aber ich möchte, dass meine Bibliothek mit Stable kompatibel ist, wenn std aktiviert ist.

Ist das aktuelle Verhalten ein Bug oder beabsichtigt?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen