Cargo: `cargo test` não sobrescreve o artefato de compilação no destino / depuração em conjuntos de ferramentas recentes

Criado em 11 out. 2018 · 3Comentários · Fonte: rust-lang/cargo

Verifique o projeto minimizado para reproduzir: https://github.com/skletsun/cargo_feature_dylib_issue.
Existe um espaço de trabalho que contém uma biblioteca dinâmica e um projeto que dela depende. A biblioteca tem um recurso. O problema é que o mesmo cenário de construção e teste não funciona para conjuntos de ferramentas recentes:

Cenário de trabalho:
1) cargo +1.26.2 build --features feature
2) cargo +1.26.2 test --all -- --nocapture

Não funciona:
1) cargo +1.28.0 build --features feature
2) cargo +1.28.0 test --all -- --nocapture

Minhas observações atuais (testadas em OSX): Cenário de trabalho - na etapa (1) a biblioteca libcargo_check.dylib é construída dentro do diretório target/debug/deps e então copiada para target/debug . Na etapa (2), ele é reconstruído (por causa do recurso ausente), também copiado (sobrescrevendo o antigo) para target/debug e, em seguida, o aplicativo de teste é executado sendo vinculado à biblioteca compartilhada no target/debug . Quando tento fazer o mesmo com o conjunto de ferramentas mais recente (cenário não funcional), ele se comporta quase da mesma maneira, exceto que na etapa (2) a biblioteca é reconstruída em target/debug/deps MAS NÃO COPIADA para target/debug e o aplicativo de teste é executado na versão antiga da biblioteca dinâmica em target/debug . E se eu excluir manualmente o libcargo_check.dylib desatualizado em target/debug então cargo +1.28.0 test --all -- --nocapture funcionará conforme o esperado porque o aplicativo de teste é executado na biblioteca dinâmica localizada em target/debug/deps .

O projeto Rust original é parte de um projeto complexo que envolve Java, portanto, todo o projeto é construído com Maven, que por sua vez executa carga para construção e teste em alguma ordem. Minha expectativa é que cargo test deva se comportar da mesma maneira que nas versões anteriores dos conjuntos de ferramentas.

Eu testei em algumas versões do conjunto de ferramentas e posso dizer que funciona para 1.26.2 e 1.27.2, mas não funciona para 1.28.0 e 1.29.1.

Desde já, obrigado!

Fonte

skletsun

👍2

Comentários muito úteis

Obrigado por investigar este @ehuss! A opção (2) parece uma ótima maneira de consertar isso para mim, eu definitivamente não acho que devemos ter muitos resultados ao mudar a precedência lá e podemos sempre buscar (3) independentemente mais tarde, se necessário

alexcrichton em 11 out. 2018

👍2

Todos 3 comentários

cc @ehuss , acho que estávamos discutindo isso recentemente no discord, certo? Nisso este é o comportamento esperado atualmente, mas que podemos de fato consertar! (e provavelmente deveria para saídas dylib, pelo menos)

alexcrichton em 11 out. 2018

Acho que foi em # 6131, onde discutimos, que o edificante foi mudado.

Existem várias coisas aqui:

Os comandos build / test / run não limpam o diretório de destino. Artefatos de execuções anteriores normalmente não importam, mas para bibliotecas compartilhadas, às vezes sim.
O caminho de pesquisa dylib inclui o diretório de destino raiz e o diretório de destino deps, e o diretório raiz está tendo precedência (trocá-los aqui corrige este problema)

Quando mudamos de edificação, era uma preocupação que talvez houvesse problemas, mas na época não podíamos pensar em nada específico. Parece que encontramos um! 😄

Vejo três soluções possíveis:

Limpe o diretório de destino base antes da execução de cada comando. Agora é um depósito de lixo. No entanto, não gosto do som dessa ideia.
Inverta a ordem do caminho dylib mencionado acima.
Copie todas as bibliotecas compartilháveis (dylib / cdylib) de dependências para o destino.

Não tenho preferência sobre qual. 2 é super fácil, mas não sei as implicações. 3 é um pouco mais difícil, mas factível.