【问题标题】:Shall go build be run always from the folder of the main package if I want to build an executable?如果我想构建可执行文件,是否应该始终从主包的文件夹运行构建?
【发布时间】:2020-07-16 07:57:38
【问题描述】:

我有一个关于 Go 构建过程的简单问题。

我有一个非常简单的应用程序,可能是最简单的,它的结构是这样的

- myapp
  - main
    - main.go
  - go.mod

main.go 存在

package main
import "fmt"
func main() {
    fmt.Println("Hello !")
}

在文件夹myapp 中运行命令go build -o bin/main main/main.go,一切正常。

不,我决定在包main 中创建一个新函数doStuff() 以供main() 调用,但我想将它放在另一个文件stuff.go 中。所以应用程序的新结构是

- myapp
  - main
    - main.go
    - stuff.go
  - go.mod

main.go 存在

package main
import "fmt"
func main() {
    fmt.Println("Hello !")
    doStuff()
}

stuff.go

package main
import "fmt"
func doStuff() {
    fmt.Println("I am doing stuff")
}

如果我现在尝试运行相同的构建命令go build -o bin/main main/main.go,我会收到错误main/main.go:4:2: undefined: doStuff

但如果我进入main 文件夹并从那里运行命令go build -o ../bin/main 一切正常。

这种行为的原因是什么?如果我想创建一个可执行文件,我应该总是从main() 所在的文件夹运行go build 命令吗?

【问题讨论】:

  • Go 的编译单元是一个包,而不是一个文件,因此在命令行中指定文件名很少是正确的。运行go build -o bin/main ./main
  • 谢谢。我之所以指定文件名,是因为 Go 中无服务器框架为 lambda 函数提供的模板实际上在构建命令中使用了文件名。现在很清楚了。

标签: go go-build


【解决方案1】:

如果 main 包被拆分成多个文件,您可以执行以下任一操作:

go build -o bin/main ./main

go build -o bin/main ./main/*

主包通常非常小。所有业务逻辑都倾向于在pkg/internal/ 中。

【讨论】:

  • 最后一个完全错误:想想 *_test.go 或 *_windows.go 文件。
  • 我说过你可以做到。根据问题工作。正如我的回答中提到的,您不应该对主要 pkg 进行单元测试,业务逻辑在其他地方。谢谢
  • 此外,该命令与 /main 目录中的 *_test.go 完美配合。抱歉,您的说法不正确。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-09-11
  • 1970-01-01
  • 1970-01-01
  • 2014-04-21
  • 1970-01-01
相关资源
最近更新 更多