例如，https://github.com/golang/sys/blob/master/cpu/cpu_gccgo_x86.go#L5：//go:build (386 || amd64 || amd64p32) && gccgo// +build 386 amd64 amd64p32// +build gccgopackage cpu在我看來，作為一個構建標簽，可以很好地工作。為什么仍然顯式指定？// +build ... //go:build順便說一句，很難找到的，但很容易（https://pkg.go.dev/cmd/go#hdr-Build_constraints//go:build// +build)
1 回答
當年話下
TA貢獻1890條經驗 獲得超9個贊
前往 1.18
新指令現在是首選，工具鏈將主動刪除舊指令;如 Go 1.18 發行說明中所述：//go:build
在 Go 1.18 中，現在刪除模塊中在其 go.mod 文件中聲明 go 1.18 或更高版本的過時行。
go fix// +build
由于上述原因，如果您嘗試構建一個 1.17 或更低版本的模塊，并且該模塊需要 1.18 或更高版本的依賴項，則在缺少依賴項行的情況下，生成可能會失敗。go.mod// +build
前往 1.17
//go:build是用于指定生成約束的新條件編譯指令。它是在 Go 1.17 中引入的。
它旨在取代舊的指令;用例仍然是相同的：它“列出了文件應包含在包中的條件”。新語法帶來了一些關鍵改進：// +build
與其他現有 Go 指令和編譯指示的一致性，例如
//go:generate支持標準布爾表達式，例如，而舊注釋的語法不那么直觀。例如，AND 用逗號表示，用 OR 用空格表示
//go:build foo && bar// +build// +build foo,bar// +build foo bar它受 支持，它將自動修復指令在源文件中的錯誤位置，從而避免常見錯誤，因為在指令和包語句之間不會留下空行。
go fmt
這兩個構建指令將在幾個Go版本中共存，以確保平穩過渡，如相關提案文檔中所述（在下面的引文中，N是17，強調我的）：
Go 1.N將開始過渡。在 Go 1.N 中：
生成將開始首選行以進行文件選擇。如果文件中沒有，則任何行仍然適用。
//go:build//go:build// +build如果 Go 文件包含 不 帶 的 生成將不再失敗。
//go:build// +build如果 Go 或程序集文件包含的文件中太晚，則生成將失敗。Gofmt 會將錯放的 //go：構建和 // +構建行移動到它們在文件中的正確位置。
//go:build
Gofmt將使用與其他 Go 布爾表達式相同的規則（all 和運算符周圍的空格）將表達式格式化為行。//go:build&&||如果文件只包含
// +構建行，gofmt將在它們上方添加等效的 //go：構建行。如果文件同時包含
//go：構建和// +構建行，gofmt將考慮//go：build真實來源并更新行以匹配，從而保持與早期版本的 Go 的兼容性。 還將拒絕被認為過于復雜而無法轉換為格式的行，盡管這種情況很少見。（請注意此項目符號開頭的“如果”。 不會向只有 .） 的文件添加行。// +buildGofmt//go:build// +buildGofmt// +build//go:build簽入將添加對約束的支持。當 Go 源文件包含具有不同含義的
//go：構建和// +構建行時，它將失敗。如果檢查失敗，可以運行 。buildtagsgo vet//go:buildgofmt -w當 Go 源文件包含 without 并且其包含模塊具有列出 Go 1.N 之前版本的 go 行時，檢查也將失敗。如果檢查失敗，可以添加任何行，然后運行 ，這將用正確的行替換它?；蛘呖梢詫?go 版本提升到 Go 1.N。
buildtags//go:build// +build// +buildgofmt -wgo.mod
有關語法更改的詳細信息：Golang 條件編譯
- 1 回答
- 0 關注
- 439 瀏覽
添加回答
舉報
0/150
提交
取消