Cargo: `cargo test` n'écrase pas l'artefact de construction dans la cible/le débogage sur les chaînes d'outils récentes

Créé le 11 oct. 2018 · 3Commentaires · Source: rust-lang/cargo

Veuillez consulter le projet minimisé à reproduire : https://github.com/skletsun/cargo_feature_dylib_issue.
Il existe un espace de travail qui contient une bibliothèque dynamique et un projet qui en dépend. La bibliothèque a une fonction. Le problème est que le même scénario de construction et de test ne fonctionne pas pour les chaînes d'outils récentes :

Scénario de travail :
1) cargo +1.26.2 build --features feature
2) cargo +1.26.2 test --all -- --nocapture

Ne fonctionne pas :
1) cargo +1.28.0 build --features feature
2) cargo +1.28.0 test --all -- --nocapture

Mes observations actuelles (testées sur OSX): Scénario de travail - à l'étape (1), la bibliothèque libcargo_check.dylib est construite dans le répertoire target/debug/deps puis copiée dans target/debug . À l'étape (2), il est reconstruit (en raison de la fonctionnalité manquante), également copié (en écrasant l'ancien) dans le target/debug , puis l'application de test est exécutée en étant liée à la bibliothèque partagée dans le target/debug . Lorsque j'essaie de faire la même chose avec une nouvelle chaîne d'outils (scénario non fonctionnel), il se comporte presque de la même manière, sauf qu'à l'étape (2), la bibliothèque est reconstruite en target/debug/deps MAIS PAS COPIE dans le target/debug et l'application de test est exécutée sur l'ancienne version de la bibliothèque dynamique dans target/debug . Et si je supprime manuellement les libcargo_check.dylib obsolètes dans target/debug alors cargo +1.28.0 test --all -- --nocapture fonctionne comme prévu car l'application de test est exécutée sur la bibliothèque dynamique située dans target/debug/deps .

Le projet Rust d'origine fait partie d'un projet complexe impliquant Java, de sorte que l'ensemble du projet est construit avec Maven, qui à son tour exécute la cargaison pour la construction et les tests dans un certain ordre. Je m'attends à ce que cargo test se comporte de la même manière que dans les versions précédentes des chaînes d'outils.

Je l'ai testé avec quelques versions de la chaîne d'outils et je peux dire que cela fonctionne pour 1.26.2 et 1.27.2, mais ne fonctionne pas pour 1.28.0 et 1.29.1.

Merci d'avance!

Source

skletsun

👍2

Commentaire le plus utile

Merci d'avoir enquêté sur ce @ehuss ! L'option (2) semble être un excellent moyen de résoudre ce problème pour moi, je ne pense certainement pas que nous devrions avoir beaucoup de retombées en changeant la priorité là-bas et nous pouvons toujours poursuivre (3) indépendamment plus tard si nécessaire

alexcrichton le 11 oct. 2018

👍2

Tous les 3 commentaires

cc @ehuss , je pense que nous en discutions récemment sur Discord, non ? En ce sens, il s'agit d'un comportement attendu actuellement, mais que nous pouvons effectivement corriger ! (et devrait probablement pour les sorties dylib au moins)

alexcrichton le 11 oct. 2018

Je pense que c'était dans #6131 où nous discutions que l'élévation avait été modifiée.

Il y a plusieurs choses ici :

Les commandes build/test/run ne nettoient pas le répertoire cible. Les artefacts des exécutions précédentes n'ont normalement pas d'importance, mais pour les bibliothèques partagées, ils le font parfois.
Le chemin de recherche dylib inclut le répertoire cible racine et le répertoire cible deps, et le répertoire racine a la priorité (les échanger ici résout ce problème)

Lorsque nous avons changé d'élévation, nous craignions que cela puisse avoir des problèmes, mais à l'époque, nous ne pouvions penser à rien de spécifique. On dirait que nous en avons trouvé un ! ??

Je vois trois solutions possibles :

Nettoyez le répertoire cible de base avant l'exécution de chaque commande. En ce moment, c'est un dépotoir. Cependant, je n'aime pas le son de cette idée.
Inversez l'ordre du chemin dylib mentionné ci-dessus.
Copiez toutes les bibliothèques partageables (dylib/cdylib) des dépendances dans la cible.

Je n'ai pas de préférence sur laquelle. 2 est super facile, mais je ne connais pas les implications. 3 est un peu plus difficile, mais faisable.