标题
⭐[golang的坑]同时开发两个库的简单方法
clq
浏览(351) +
2023-09-10 22:55:14 发表
编辑
关键字:
[2023-09-10 22:58:21 最后更新]
⭐[golang的坑]同时开发两个库的简单方法"go.toolsEnvVars"
golang 作为这么好的工具。它居然是不能同时开发两个库(一个需要引用另外一个的时候)的。这也主要是因为 golang 带有很强的极客色彩,它的创始人的坚持造就了 golang 的成功。
灌输了很多震撼的理念给我们,一些非常不好理解的东西也造成了困扰。其中库路径就是其中之一,我和很多 go 开发一样一直都搞不清楚 gomod 的全部用法,可以说是一团混乱。更牛x的是这种规则目前都还在剧烈的演化。
比如我今天刚知道 18.3 后出了一个 go.work 的相关文件和概念。大喜之下我试用了一天,可以说在 liteide 下非常好用,可惜 vscode 的支持还不完整,如果应用会让某些代码的提示失效 -- 感觉这部分 vscode 的 go 插件做得很差劲。
它长久以来对源码中的子目录也是不能完好支持,难道老外都不用子目录吗?我看好多库里用的呀。
就目前来说有开发两个库的项目,比较完美的做法还是用 "GO111MODULE":"off" 使用传统的 gopath 路径搜索方式。遗憾的是,这在 vscode 中还是有问题,编译完好但没有代码提示。折腾了一在发现可以用一个国内 golang 开发很少提到的选项
可以做到提示与编译相同的可用度。其实原因出在 vscode 的语言服务器默认是 "GO111MODULE":"on" 的。这是我早就知道的。不过今天才发现它是可以切换的,方法很晦涩,原因是这个参数不是插件中的,而是语言服务器的参数。
所以它在插件中没有说明。
这实际上要修改插件的
"go.toolsEnvVars"
通过变量名我猜测它是 go 插件使用到的工具的环境变量,有可能会影响到语言服务器。一试之下果然是可以修改语言服务器的启动环境变量的,方法如下
//-------- 这个里面的 GO111MODULE 可对 go 扩展起作用!
"go.toolsEnvVars": {
"GOPATH":"D:/gopath1.18.3",
//"GO111MODULE":"off", //会导致 go.work 也失效 //不过编译会比较容易成功
"GO111MODULE":"on",
"GOROOT": "D:/go1.18.3.windows-amd64/go",
// "GOROOT": "D:/go1.10.8.windows-amd64/go",
},
这是写在项目目录的 settings.json 文件中的。
这个的原理需要的知识点多了一点,类似于编译运行调试时的 "env" 参数。
当前的结果是很完美的,关键是不知道能用多久。
--------------------------------------------------------
于是我又折腾了两个小时看看怎样在 "GO111MODULE":"on" 的时候也能完美支持代码提示。
最后做出来的方法可以说非常老土,非常不值得一晒。 :)
不过确实有效。
方法就是在 gopath/src 或者 vendor 中您任意喜欢的一个目录中写好代码,然后软链接它们的目录就可以了! 非常完美,根本不用修改 vscode 和 liteide 的配置。
NEWBT官方QQ群1: 276678893
可求档连环画,漫画;询问文本处理大师等软件使用技巧;求档softhub软件下载及使用技巧.
但不可"开车",严禁国家敏感话题,不可求档涉及版权的文档软件.
验证问题说明申请入群原因即可.