go build ne fonctionne pas lorsqu'il est utilisé avec un espace de travail

l'éditeur php Banana est là pour vous présenter un problème courant, c'est-à-dire que la commande go build ne peut pas fonctionner correctement lors de l'utilisation de l'espace de travail. Ce problème peut dérouter les développeurs, car l'espace de travail est un concept très important dans le langage Go, et l'incapacité d'utiliser correctement la commande go build affectera sérieusement le processus de développement. Dans l'article suivant, nous analyserons en profondeur la cause de ce problème et proposerons des solutions pour aider les développeurs à résoudre ce problème avec succès.

Contenu des questions

Ce qui suit est la structure de mon code golang,

├── go.work
├── moda
│   ├── go.mod
│   └── main.go
├── go.mod
└── modb
    └── main.go

Le problème est que je ne peux créer des binaires que pour un seul module. Pour construire d'autres modules, cela ne fonctionne que si je commente les autres modules dans go.work

Mon go.work est le suivant,

go 1.19
use (
    ./moda
    .
)

Donc, lorsque j'utilise go.work ci-dessus pour construire comme suit, cela fonctionne bien,

go build -o test-binary -modfile ./moda/go.mod ./moda

Mais lorsque j'essaie de construire pour mon autre module (c'est-à-dire modb/) comme indiqué ci-dessous,

go build -o test-binary1 -modfile ./go.mod ./modb

J'ai rencontré l'erreur suivante,

directory modb is contained in a module that is not one of the workspace modules listed in go.work. you can add the module to the workspace using go work use .

J'ai essayé d'utiliser go 工作 use mais je suis toujours confronté au même problème. Quelqu'un peut-il m'aider à résoudre ce problème ?

Edit 1 :

J'avais un projet qui nécessitait plusieurs fichiers go.mod pour séparer les dépendances du module principal et des sous-modules, et c'est à ce moment-là que j'ai commencé à découvrir les espaces de travail go qui convenaient très bien à mon cas d'utilisation.

La structure de mon projet est la même que celle mentionnée ci-dessus,

├── go.work
├── submodule
│   ├── go.mod
│   ├── go.sum
│   └── main.go
└── mainmodule
    └── main.go
├── go.mod
├── go.sum

Maintenant, lors de la construction de l'exécutable d'un sous-module, go build fonctionne correctement, mais lors de la construction de l'exécutable du module principal, les importations présentes dans le sous-module/go.mod sont également ajoutées à l'exécutable du module principal. J'ai vérifié cela avec go build -n aussi.

Pour éviter d'ajouter des importations de sous-modules à l'exécutable du module principal, j'ai utilisé -modfile mais en l'utilisant, je ne peux construire l'exécutable que pour le sous-module et non pour le module principal.

code source de github

ps : Bien que j'ai ajouté un exemple de code dans github, je ne peux pas reproduire le même problème (les importations de sous-modules sont ajoutées au module principal) Je ne sais pas si c'est à cause des importations que j'ai utilisées

Bonne réponse

Après en discutant avec @arigatomanga, nous avons découvert que la confusion est causée par la sélection de version minimale (mvs) dans l'espace de travail. Un espace de travail est une collection de modules sur disque qui est utilisée comme module principal lors de l'exécution de Sélection de version minimale (mvs) (Référence). Grâce à mvs, les modules construits avec le mode espace de travail activé peuvent utiliser des modules dépendants différents de ceux construits avec le mode espace de travail désactivé.

Il s'agit du comportement documenté de l'espace de travail et il n'y a aucun problème pour le moment.

Mise à jour : vous trouverez ci-dessous la réponse originale, axée sur le drapeau -modfile. En mode espace de travail dans go1.21, cet indicateur sera rejeté.

Vous avez rencontré une erreur dans l'outil go. Je viens de signaler ce problème ici.

Le message d'erreur dans go1.20 est différent et toujours trompeur :

go: module example.com/m1 appears multiple times in workspace

La différence a été introduite par le commit cmd/go/internal/modload : erreur renvoyée lors de la duplication des chemins de module entre les modules dans go.work, mais la cause première est la même : en mode espace de travail, l'indicateur -modfile n'a pas été corrigé. .

Mise à jour : la section suivante n'est pas pertinente pour le moment. Avant de comprendre ce qu'est mvc, essayer de supprimer mvs en utilisant le drapeau -modfile est une tentative ratée.

Dans le rapport de problème, j'ai suggéré de bloquer le drapeau -modfile en mode espace de travail. Mais vous avez dit dans les commentaires que vous aviez besoin de ce drapeau.

La raison d'utiliser -modfile 的原因是如果我为 ./src 构建二进制文件，即使在 ./moda 中存在的模块也会作为 ./src est que si je construis un binaire pour ./src, même les modules présents dans ./moda apparaîtront comme ./src code> est téléchargé et chargé dans le cadre du binaire, bien qu'il ne doive pas être inclus

Mais selon la documentation cmd/go  :

-fichier modfile

En mode compatible avec les modules, lisez (et éventuellement écrivez) un go.mod alternatif fichier au lieu d’un fichier dans le répertoire racine du module. Une personne nommée "go.mod" doit toujours exister pour déterminer la racine du module répertoire, mais le répertoire n'a pas été consulté. Lorsque -modfile est spécifié, Utilise également un autre fichier go.sum : son chemin est dérivé de -indicateur modfile, en supprimant l'extension ".mod" et en ajoutant ".sum".

L'indicateur

-modfile 标志用于替换模块根目录中的 go.mod est utilisé pour remplacer le fichier go.mod dans le répertoire racine du module. Mais dans votre exemple, vous avez spécifié le même fichier que celui de la racine du module. Donc je ne comprends pas très bien. Pouvez-vous mettre à jour votre question pour développer cette partie ? La démo est occupée !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!