Build constraint e tag

I build constraint (chiamati anche build tag) condizionano la compilazione di un file in base a OS, architettura, versione di Go o tag custom passati a riga di comando. Servono per cross-platform code, file di test pesanti opt-in, e simili.

Sintassi moderna: //go:build

Dal Go 1.17+ il formato canonico è il commento speciale //go:build, posto in cima al file prima del package, su una riga isolata, seguito da una riga vuota:

//go:build linux

package main

// questo file viene compilato SOLO su Linux

Tre regole assolute:

1. Il commento deve stare prima del package.
2. Deve essere seguito da una riga vuota.
3. Niente spazio fra // e go:build (è un trigger sintattico, non un commento qualsiasi).

Espressioni booleane

L'espressione dopo //go:build accetta operatori logici:

//go:build linux && amd64           // entrambe le condizioni
//go:build linux || darwin          // una qualsiasi (Unix-like)
//go:build !windows                 // negazione
//go:build (linux || darwin) && !arm64
//go:build go1.22                   // versione di Go ≥ 1.22
//go:build integration              // tag custom (vedi sotto)

Tag built-in più usati:

• OS: linux, darwin, windows, freebsd, js...
• Architettura: amd64, arm64, 386, wasm...
• Versione Go: go1.20, go1.22... (vero se la versione è ≥).
• cgo: vero se cgo è abilitato.

Cross-platform: convenzione del nome file

Oltre ai tag espliciti, Go riconosce suffissi nel nome file come build constraint impliciti:

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

È il pattern idiomatico per implementazioni dipendenti dalla piattaforma di una stessa interfaccia (ogni file definisce le stesse funzioni con codice diverso).

Tag custom: opt-in di test pesanti

I tag custom sono qualunque identificatore che passi a riga di comando:

//go:build integration

package mypkg

// test che richiedono un DB reale, eseguiti solo on demand

Esecuzione:

go test -tags=integration ./...

Senza -tags=integration, il file è invisibile al compilatore (i test al suo interno non esistono per go test). È il modo canonico per separare unit test (sempre) da integration test (su richiesta, magari solo in CI).

Sintassi vecchia: // +build (deprecata)

Prima del 1.17 il formato era // +build linux (notare lo spazio, e che +build non go:build). È ancora supportato per retro-compatibilità, ma gofmt di Go 1.17+ aggiunge entrambi quando trova solo il vecchio:

//go:build linux
// +build linux

package main

Per nuovi file usa solo la versione moderna //go:build.

Esercizi

$ go test -tags=???