在标准仓库和x/tools中维护go/internal/gcimporter有些繁琐。我们能找到更好的解决方案吗？
例如，我们将许多其他x/仓库打包到主构建中。我们是否也可以为x/tools/go/internal/gcimporter做同样的事情？
我知道go/internal/gcimporter比x/tools/go/internal/gcimporter更积极地修剪向后兼容的代码，但我认为我们仍然可以使用相同的代码库，只是使用不同的入口点或以不同的方式构建它。
/cc @griesemer@alandonovan
3条答案
按热度按时间i7uaboj41#
相关问题：我提交了 95b8cbf 和 golang/tools@db0687c,然后它们破坏了 x/exp 构建器，因为它们使用了最新的 golang/go 仓库(即，生成了 iexport v1 数据),但使用了较旧版本的 golang/tools(即，只理解 iexport v0 数据)。
/cc @bcmills@ianthehat
cgvd09ve2#
我们将一堆其他的x/仓库合并到主构建中。我们能为x/tools/go/internal/gcimporter也这样做吗？
它需要一个新的导入路径：标准库不能从另一个模块导入一个
internal包。话虽如此，如果
gcimporter的依赖是自包含的，那么将其分解出一个模块并让std模块在其上进行vendor似乎也是可以的。CC @matloob,因为我怀疑这涉及到了
go/packages。tez616oj3#
vendoring并不能解决版本问题，例如它不能帮助在较新的导出数据上运行旧工具，而且这也意味着它总是需要理解所有曾经存在过的版本。
如果我们将一个能够理解导出数据的工具与分发一起发布，我们就不需要在该工具内维护兼容性。它只需要理解当前版本并将其转换为API格式，这可能使用效率较低但更容易维护的兼容形式(如JSON)。
然后，我们可以重写x/tools/go/internal/gcimporter以使用该工具的输出而不是直接读取文件。