Cargo: Dependencia opcional cuando una función * no * está habilitada.

Creado en 27 jul. 2015 · 3Comentarios · Fuente: rust-lang/cargo

Algunas bibliotecas pueden ejecutarse en Rust estable con un rendimiento degradado (por ejemplo, sin usar NonZero ) o capacidades limitadas (algunas API deshabilitadas). La práctica emergente parece tener una función unstable o nightly Cargo para permitir al usuario optar por utilizar funciones inestables de Rust cuando estén disponibles.

Estoy publicando rust-rc como una solución por std::rc::Weak que aún no es estable. Por el momento, no parece haber una forma de tener esta caja como una dependencia de forma predeterminada, pero _no_ cuando la función unstable está habilitada. ¿Podría agregarse esto a Cargo?

Tenga en cuenta que revertir el valor predeterminado y tener una función stable solo mueve el problema a dependencias que solo pueden / deben usarse en Rust inestable.

A-features

Fuente

SimonSapin

❤2 👍2

Comentario más útil

Con la sintaxis [target.'cfg(...)'.dependencies] , esto podría ser compatible simplemente permitiendo que cfg(feature = "...") comporte como lo hace en el código Rust:

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

Actualmente, dicha sección se trata como habilitada _independientemente_ del estado de la función, lo que honestamente me parece un error.

eternaleye en 22 mar. 2018

👍8

Todos 3 comentarios

También me gustaría tener esto. En midir , hay varios backends (ALSA y / o JACK en Linux, CoreMIDI y / o JACK en OSX, WinMM en Windows), y mi plan es tener un indicador de función jack que habilite JACK y deshabilite el otro (nativo) uno. También me gustaría eliminar la dependencia de ALSA / CoreMIDI en el caso de compilar para JACK, por lo que incluso podría usarse si ALSA no está instalado en el sistema.

Mi primera idea fue lo que se solicitó anteriormente, es decir, simplemente deshabilitar la dependencia alsa-sys si se selecciona la función jack .

Una alternativa a esto es tener una función predeterminada (por ejemplo, native ), que podría deshabilitarse si jack está habilitado, y luego tener dependencias específicas de la plataforma para esta función (es decir, alsa-sys en Linux y CoreMIDI en OSX), usando algo como [target.x86_64-unknown-linux-gnu.features] . También parece que actualmente es imposible tener conjuntos de características predeterminadas específicas de la plataforma de destino, lo que también resolvería el problema.

Hasta ahora no pude encontrar una solución que funcione sin definir dependencias / características dependientes de la plataforma en cajas dependientes, pero es posible que haya pasado por alto algo.

Boddlnagg en 11 ago. 2015

Con la sintaxis [target.'cfg(...)'.dependencies] , esto podría ser compatible simplemente permitiendo que cfg(feature = "...") comporte como lo hace en el código Rust:

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

Actualmente, dicha sección se trata como habilitada _independientemente_ del estado de la función, lo que honestamente me parece un error.

eternaleye en 22 mar. 2018

👍8

El mismo caso para mí:

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

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

Solo quiero la dependencia heapless si la función std no está habilitada.
heapless funciona solo por la noche, pero quiero que mi biblioteca sea compatible con estable si std está habilitado.

¿El comportamiento actual es un error o está previsto?