Question

我无法实现应该是一项简单的任务。我理解代码组织的GitHub模型（即库存仓库和使用库的应用程序仓库）。我觉得这很棒。但我经常发现，我希望mylib与单个main.go文件中的简单可执行文件捆绑在一起。 main.go应为package main，并且应导入mylib。换句话说，它应该是如何构建使用此库的应用程序的确切文档。

我的观点是，因为提供一个包装你的库的简单命令行界面通常很方便，所以应该有一个简单的方法来做到这一点，而不必再做一个repo，golang应该有所帮助。

我想要以下内容：

$GOPATH/src/github.com/me/mylib
    mylib.go
    mylib_also.go
    main.go

其中mylib是库（package mylib），main.go是package main，在运行go install时，它生成bin/mylib和{{1} }}。

pkg/mylib.a应导入main.go（如果我现在这样做，我会遇到周期性导入错误）或"github.com/me/mylib"会理解发生了什么，因为应该内置此功能并且go { repo中的{1}}生成exec。可能需要导入（并且丢弃周期性错误）是更好的方法。

现在，我必须做

main.go

所以我必须导入github.com/me/mylib/mylib，这很荒谬。

总之，$GOPATH/src/github.com/me/mylib mylib/ mylib.go main.go应该允许包的特殊情况和导入包的main，并提供演示包API的简单cli。 GitHub模型促进了两个回购，但是在一个中应该很容易做简单的clis！

Answer 1

每个文件夹不能包含多个包。 Go在包级别而不是文件级别上运行。

本例中的惯例 - 使用您的库的二进制文件 - 是使用您的包主文件创建cmd文件夹 - 即按https://github.com/bradfitz/camlistore/tree/master/cmd或https://github.com/boltdb/bolt

在你的情况下，这将是：

$GOPATH/src/github.com/me/mylib
    mylib/
      mylib.go
      README.md
      cmd/
        your-lib-tool/
          main.go

Answer 2

如果你只是想要一个方便的小包装器，只需要一些lib的命令行界面用于演示目的，如果主程序不是构建在go get上（而不是在简单的{{1}期间），那也没关系}和go build）但你可以通过go install运行它或手动构建它，例如使用go run main.go：只需在main.go中使用构建代码（请参阅http://golang.org/pkg/go/build/#hdr-Build_Constraints）：

6g

并且您不需要其他文件夹或回购。

为什么我不能在golang中为我的库添加一个main？

2 个答案: