go run מול go build מול go install: קומפילציה והרצה של Go

go run מקמפלת ומריצה תוכנית בצעד אחד ולא שומרת קובץ בינארי. go build מקמפלת ומשאירה קובץ הרצה בתיקייה הנוכחית. go install מקמפלת ושמה את קובץ ההרצה ב-$HOME/go/bin. שלושתן מקמפלות לקוד מכונה נייטיב; אף אחת מהן לא מפרשת (interprets) כלום.

התוכנית הבאה היא זו שמשמשת בדוגמאות בדף הזה. העורך מריץ אותה כמו ש-go run הייתה מריצה.

package main

import (
	"fmt"
	"os"
	"runtime"
)

// version is overwritten at build time with -ldflags (see below).
var version = "dev"

func main() {
	fmt.Println("version:", version)
	fmt.Println("built for:", runtime.GOOS+"/"+runtime.GOARCH)
	fmt.Println("args:", os.Args[1:])
}

go run

go run מקבלת חבילה (בדרך כלל ., התיקייה הנוכחית) או רשימה של קובצי .go:

go run .
go run main.go
go run ./cmd/server

כל מה שבא אחרי החבילה מועבר לתוכנית שלכם כארגומנטים:

go run . --port 8080 verbose

version: dev
built for: linux/amd64
args: [--port 8080 verbose]

העדיפו go run . על פני go run main.go. ציון שם קובץ מקמפל רק את הקובץ הזה, כך שברגע שיש בחבילה קובץ שני, פונקציות שמוגדרות בו מדווחות כ-undefined. הדף על חבילות ו-imports מסביר את השגיאה הזאת בפירוט.

go run יכולה גם להריץ תוכנית מרוחקת בגרסה מסוימת בלי להתקין אותה, מה שנוח למחוללי קוד:

go run golang.org/x/tools/cmd/stringer@v0.30.0 -type=Color

go build

go build מקמפלת את החבילה בתיקייה הנוכחית. עבור חבילת main היא כותבת קובץ הרצה; עבור חבילת ספרייה היא מקמפלת, מדווחת על שגיאות וזורקת את התוצאה.

go mod init example.com/hello
go build
ls

go.mod  hello  main.go

השם של הקובץ הבינארי נקבע לפי הכללים האלה:

עוד שתי צורות שתשתמשו בהן כל הזמן:

go build ./...      # compile every package in the module
go vet ./...        # static checks, covered below

./... פירושו "התיקייה הזאת וכל תיקייה שמתחתיה". go build ./... עם כמה חבילות main לא כותבת שום קובץ בינארי; זו בדיקה מהירה של "האם הכול מתקמפל".

דגלי בנייה שימושיים

הדגל -X הוא הדרך שבה רוב פרויקטי Go מטביעים גרסה בקובץ הבינארי. הוא עובד רק על משתני string ברמת החבילה (לא על קבועים):

go build -o app -ldflags "-X main.version=1.4.0" .
./app

version: 1.4.0
built for: linux/amd64
args: []

הקובץ הבינארי גם רושם את גרסאות המודולים שלו, והחל מ-Go 1.18 גם את ה-commit ב-VCS שממנו הוא נבנה. go version -m ./app מדפיסה אותם, ותוכנית יכולה לקרוא אותם עם runtime/debug.ReadBuildInfo.

go install

go install בונה בדיוק כמו go build ואז מעבירה את קובץ ההרצה ל-$GOBIN, או ל-$GOPATH/bin כש-GOBIN לא מוגדר (כברירת מחדל $HOME/go/bin):

go install .
go env GOPATH

השימוש הנפוץ ביותר בה הוא התקנת כלים שכתובים ב-Go. עם @version היא מתקינה תוכנית בלי לגעת ב-go.mod שלכם:

go install golang.org/x/tools/gopls@latest
go install honnef.co/go/tools/cmd/staticcheck@latest

אם ה-shell לא מוצא כלי אחרי ההתקנה, $HOME/go/bin לא נמצא ב-PATH שלכם. הוסיפו export PATH=$PATH:$(go env GOPATH)/bin לפרופיל של ה-shell.

Cross-compile עם GOOS ו-GOARCH

Go יכולה לבנות למערכת הפעלה או למעבד אחרים מכל מכונה, בלי toolchain נוסף. הגדירו שני משתני סביבה עבור פקודת הבנייה:

GOOS=linux GOARCH=amd64 go build -o app-linux-amd64 .
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 .
GOOS=darwin GOARCH=arm64 go build -o app-macos .
GOOS=windows GOARCH=amd64 go build -o app.exe .

ב-PowerShell מגדירים משתני סביבה אחרת:

$env:GOOS = "linux"; $env:GOARCH = "amd64"; go build -o app-linux .

הצמדים הנפוצים ביותר:

go tool dist list מדפיסה כל צמד נתמך (48 ב-Go 1.24).

cross-compile קל כל כך רק לקוד Go טהור. חבילה שמשתמשת ב-cgo (קוד C, למשל חלק מהדרייברים של SQLite) צריכה cross-compiler של C עבור היעד. בזמן cross-compile, cgo מושבת כברירת מחדל, והגדרה מפורשת של CGO_ENABLED=0 נותנת גם קובץ בינארי סטטי לחלוטין ל-Linux, וזה מה שרוצים ב-image מינימלי של קונטיינר מסוג scratch או distroless.

go fmt ו-go vet

שתי בדיקות שייכות לכל תהליך עבודה, וגם ל-CI.

go fmt משכתבת קבצים בסגנון הרשמי האחד: טאבים, שדות מיושרים, ריווח אחיד. היא עוטפת את gofmt -l -w:

go fmt ./...
gofmt -l .     # list files that are not formatted; empty output means clean

go vet מדווחת על קוד שמתקמפל אבל כמעט בוודאות שגוי. אי התאמה בפורמט של Printf היא המקרה הקלאסי:

package main

import "fmt"

func main() {
	count := 3
	fmt.Printf("%s items\n", count)
}

go vet ./...

# example.com/hello
# [example.com/hello]
./main.go:7:2: fmt.Printf format %s has arg count of wrong type int

התוכנית מתקמפלת ומדפיסה %!s(int=3) items, וזה בדיוק סוג הבאג ש-vet קיימת כדי לתפוס. בדיקות vet נוספות כוללות העתקה של sync.Mutex לפי ערך, קוד שאי אפשר להגיע אליו, struct tags עם תחביר שגוי, ו-context.CancelFunc שאף פעם לא נקראת. go test מריצה אוטומטית חלק מהבדיקות האלה; go build לא מריצה אף אחת.

פקודות go נוספות

למה בניות מהירות בפעם השנייה

Go שומרת חבילות מקומפלות ב-build cache (go env GOCACHE). בנייה מחדש מקמפלת רק חבילות שקוד המקור או התלויות שלהן השתנו, כך ש-go run . על פרויקט שלא השתנה עולה כמעט מיד. אם בנייה אי פעם מתנהגת מוזר אחרי החלפת גרסת Go או משתני סביבה, go clean -cache מנקה אותו; לעיתים רחוקות תצטרכו את זה.