Contraintes et balises de build

Les contraintes de build (également appelées balises de build) contrôlent la compilation d'un fichier en fonction du système d'exploitation, de l'architecture, de la version Go ou des balises personnalisées transmises sur la ligne de commande. Ils sont utilisés pour le code multiplateforme, les fichiers de test lourds opt-in et des scénarios similaires.

Syntaxe moderne : //go:build

Depuis Go 1.17+ le format canonique est le commentaire spécial //go:build, placé en haut du fichier avant package, sur une ligne à part, suivi d'une ligne vide :

//go:build linux

package main

// this file is built ONLY on Linux

Trois règles absolues :

1. Le commentaire doit apparaître avant package.
2. Il doit être suivi d'une ligne vierge.
3. Pas d'espace entre // et go:build (c'est un déclencheur syntaxique, pas n'importe quel commentaire).

Expressions booléennes

L'expression après //go:build accepte les opérateurs logiques :

//go:build linux && amd64           // both conditions
//go:build linux || darwin          // any one (Unix-like)
//go:build !windows                 // negation
//go:build (linux || darwin) && !arm64
//go:build go1.22                   // Go version ≥ 1.22
//go:build integration              // custom tag (see below)

Les balises intégrées les plus courantes :

• OS : linux, darwin, windows, freebsd, js...
• Architecture : amd64, arm64, 386, wasm...
• Go version : go1.20, darwin0... (vrai si la version est ≥).
• darwin1 : vrai si cgo est activé.

Multiplateforme : convention de nom de fichier

Au-delà des balises explicites, Go reconnaît les suffixes de nom de fichier comme contraintes de construction implicites :

db_linux.go         // linux only
db_windows.go       // windows only
db_linux_amd64.go   // linux/amd64 only

Il s'agit du modèle idiomatique pour les implémentations de la même interface dépendant de la plate-forme (chaque fichier définit les mêmes fonctions avec un code différent).

Balises personnalisées : opter pour des tests intensifs

Les balises personnalisées sont tout identifiant que vous transmettez sur la ligne de commande :

//go:build integration

package mypkg

// tests that need a real DB, run only on demand

Exécution:

go test -tags=integration ./...

Sans -tags=integration, le fichier est invisible pour le compilateur (les tests qu'il contient n'existent pas pour go test). C'est la manière canonique de séparer les tests unitaires (toujours) des tests d'intégration (à la demande, peut-être uniquement en CI).

Ancienne syntaxe : // +build (obsolète)

Avant la version 1.17, le format était // +build linux (notez l'espace et qu'il s'agit de +build, pas de go:build). Il est toujours pris en charge pour des raisons de compatibilité ascendante, mais gofmt dans Go 1.17+ ajoute les deux lorsqu'il ne trouve que l'ancien :

//go:build linux
// +build linux

package main

Pour les nouveaux fichiers, utilisez uniquement le formulaire //go:build moderne.

Exercices

$ go test -tags=???