我需要go list ./...来打印所有涉及测试或构建的文件，而不受目标架构或项目特定约束(如selinux或apparmor)的影响。
不幸的是，IgnoredGoFiles无法满足需求，因为它还包括其他系统的文件，例如Windows与Linux非常不同，它会包含很多我不需要且无法在我的环境中使用的东西。
因此，go list ./...需要一种不同于一切或当前系统的设置上下文的方法。go/packages也无法满足需求，因为就我所知，它的范围仅限于包特定的范围(如./...),而我需要模块范围。
9条答案
按热度按时间7rtdyuoh1#
这似乎是一个非常特定的需求；为什么不用 https://golang.org/pkg/go/build/ 构建一个简单的Go程序来执行这个操作呢？
此外，正如 #30504 所解释的那样，
go list在加载包时是否可以忽略某些构建约束并不清楚。看起来你想要加载一个文件目录，而不是一个Go包。jhkqcmku2#
我同意@mvdan的观点，这似乎对go工具没有意义。
如果我们确实为go工具添加了一些内容，你具体建议添加什么？
qni6mghb3#
这似乎是一个非常特定的需求；为什么不用 https://golang.org/pkg/go/build/ 构建一个简单的Go程序来执行这个操作呢？
采用这种方法的问题在于，你编写的代码中的完整性检查与上游工具中使用 go build 进行的完整性检查产生了分歧，而这种分歧正是导致棘手错误的原因。
此外，正如 #30504 所解释的那样，目前还不清楚
go list在加载包时是否可以忽略某些构建约束。看起来你想要加载一个文件目录，而不是一个 Go 包。我想要加载一个 Go 模块，因为 Go 正在向模块化方向发展。一个模块的源代码是目录树，而不是单个包。
4urapxun4#
你想列出一个Go模块的所有源文件吗？这与
GOOS有什么关系？mrzz3bfm5#
如果我们为go工具添加了一些内容，你具体建议是什么？
go list ./... --os=linux --allarchs --alltags或者
go list ./... --os=linux --arch=x86_64 --tag=selinux --tag=cake(我知道目前在Go中标签和拱形之间的差别很弱，但对于集成商来说，它们完全不是一回事。一个是技术目标，另一个是功能目标)
628mspwn6#
你想列出一个Go模块的所有源文件吗？这与
GOOS有什么关系？因为我们针对特定的操作系统进行集成，而其他操作系统的支持文件会消耗掉这些文件中所有其他特定于操作系统的导入，当我们不需要它们时。
vxf3dgd47#
我个人认为在
go list中这种情况不太可能发生。通过构建标签(如GOOS)进行过滤是在包级别进行的，而不是在模块级别。同样，一个模块是一组包的集合，而不是一组 Go 文件的集合。请参阅 https://github.com/golang/go/wiki/Modules#modules 。此外，请注意
-os标志是不必要的；您应该能够使用GOOS=linux go list -json .查看将形成 Linux 包构建的 Go 文件。我知道这不是您想要的，但至少-os标志是不必要的。最后，在我看来，
GOOS=linux和-alltags似乎是矛盾的；操作系统选择也是通过构建标签完成的，因此您实际上是在忽略一些标签，而不是其他标签。我认为目前 Go 工具的任何部分都没有这样做。我仍然认为这应该是一个单独的工具；首先，我从未听说过有人有这些特定需求。如果您认为这是一个非常普遍的需求，那么提供一些证据或示例会有所帮助。
这种方法的问题在于，您编写的代码的完整性检查与上游构建在其自己的工具中的完整性检查发生了分歧，而这种分歧正是导致棘手错误的原因。
您的工具可以建立在
go list之上，所以我不同意。例如，您可以使用go list -m -json获取当前模块及其包列表，然后在您的代码中遍历包目录并查看磁盘上的文件。您应该能够轻松地使用go/build和go/parser完成这部分工作。jfgube3f8#
我个人认为在
go list中不太可能发生这种情况。通过构建标签(如GOOS)进行过滤是在包级别进行的，而不是在模块级别。同样，一个模块是一组包的集合，而不是真正的 Go 文件的集合。请参阅 https://github.com/golang/go/wiki/Modules#modules 。这只是添加了一个间接性来获取文件部分。
此外，请注意
-os标志是不必要的；您应该能够执行GOOS=linux go list -json .以查看形成 Linux 包构建的 Go 文件。我意识到这不是您想要的，但至少-os标志是不必要的。谢谢您的信息。
最后，在我看来，
GOOS=linux和-alltags似乎存在矛盾；操作系统选择也是通过构建标签完成的，因此您实际上会忽略一些标签，但不会忽略其他标签。我认为目前 Go 工具的任何部分都没有这样做。这就是为什么我写了“我知道 Go 目前标签和架构之间的差异相当薄弱，但对于集成器来说，它们完全不是一回事。一个是技术目标，另一个是功能目标”
您可以更改您的功能构建目标。您无法更改为您构建的架构(如果您希望结果在目标硬件上运行)。
我认为这应该是一个单独的工具；首先，我从未听说过有人有这些特定需求。如果您认为这是一个非常普遍的需求，那么提供一些证据或示例将是有帮助的。
这是一个 Linux 发行版的需求。我们为 Linux 分发，因此我们只关心一个系统。我们构建了许多应用程序和架构，因此我们关心所有的构建标签和架构。我们重新处理上游源文件，因为如果它们不需要重新处理，我们的用户只需直接获取它们，而无需使用分发包。
重新处理意味着许多过滤和选择步骤。
而且，向 Go 上游报告所有这些内容是非常痛苦的，因为通用答案是“为什么要做所有这些分发商的事情？我们找不到它们的必要性”。我们做这些事情是因为我们是分发商，它们构成了分发商的存在理由。Go 项目不做这些事情，因为它不是一个分发商(并且强烈不想成为分发商，因此强调在不改变任何东西的情况下发货)。
yptwkmov9#
@bcmills 提供进一步评论。