Cargo: Dependência opcional quando um recurso * não * está ativado.

Criado em 27 jul. 2015 · 3Comentários · Fonte: rust-lang/cargo

Algumas bibliotecas podem ser executadas em Rust estável com desempenho degradado (por exemplo, sem usar NonZero ) ou recursos limitados (algumas APIs desabilitadas). A prática emergente parece ter um recurso unstable ou nightly Cargo para permitir que o usuário opte por usar recursos Rust instáveis quando estiverem disponíveis.

Estou publicando rust-rc como uma std::rc::Weak que ainda não está estável. No momento, não parece haver uma maneira de ter esta caixa como uma dependência por padrão, mas _não_ quando o recurso unstable está habilitado. Isso poderia ser adicionado ao Cargo?

Observe que reverter o padrão e ter um recurso stable apenas move o problema para dependências que podem / devem ser usadas apenas no Rust instável.

A-features

Fonte

SimonSapin

❤2 👍2

Comentários muito úteis

Com a sintaxe [target.'cfg(...)'.dependencies] , isso poderia ser suportado simplesmente permitindo que cfg(feature = "...") se comportasse como no código Rust:

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

Atualmente, essa seção é tratada como ativada _ independentemente_ do status do recurso, o que, honestamente, parece um bug para mim.

eternaleye em 22 mar. 2018

👍8

Todos 3 comentários

Eu também gostaria de ter isso. No midir , há vários back-ends (ALSA e / ou JACK no Linux, CoreMIDI e / ou JACK no OSX, WinMM no Windows), e meu plano é ter um sinalizador de recurso jack que ativa o JACK e desativa o outro (nativo). Eu também gostaria de remover a dependência do ALSA / CoreMIDI no caso de compilar para JACK, então ele poderia até ser usado se o ALSA não estiver instalado no sistema.

Minha primeira idéia era o que é solicitado acima, ou seja, simplesmente desativar alsa-sys dependência se jack recurso é selecionado.

Uma alternativa para isso é ter um recurso padrão (por exemplo, native ), que pode ser desativado se jack estiver ativado e, em seguida, ter dependências específicas da plataforma para este recurso (a saber alsa-sys no Linux e CoreMIDI no OSX), usando algo como [target.x86_64-unknown-linux-gnu.features] . Também parece ser atualmente impossível ter conjuntos de recursos padrão específicos da plataforma de destino, o que também resolveria o problema.

Até agora, não consegui encontrar uma solução alternativa que funcione sem definir dependências / recursos dependentes de plataforma em caixas dependentes, mas posso ter esquecido algo.

Boddlnagg em 11 ago. 2015

Com a sintaxe [target.'cfg(...)'.dependencies] , isso poderia ser suportado simplesmente permitindo que cfg(feature = "...") se comportasse como no código Rust:

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

Atualmente, essa seção é tratada como ativada _ independentemente_ do status do recurso, o que, honestamente, parece um bug para mim.

eternaleye em 22 mar. 2018

👍8

Mesmo caso para mim:

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

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

Eu só quero a dependência heapless se o recurso std não estiver habilitado.
heapless funciona apenas à noite, mas quero que minha biblioteca seja compatível com estável se std estiver habilitado.

O comportamento atual é um bug ou é intencional?