本地开发远程编译有什么好方法?

同步文件其实方法很多,比如 git 勾子,inotify 等等。感觉 flycheck 才是最麻烦的

程序不一定要从仓库安装, 手动编译一个, 放在用户目录下, PATH修改一下就能用. 如果只是三四个工具程序, 完全可以这么做.

不知道你的编译环境有多老, 有centos 6老吗? 我装过centos 6的桌面, 用起来挺不错, 可以虚拟一个用.

使用本地新系统可以用flycheck, 把编译环境里专有库的头文件拷贝到本地, 确保代码在本地flycheck没问题(可以指定编译选项, 让它用老一点的c++标准来检查代码), 然后同步到编译环境中编译, 编译成功率就很高, 错误会很少.

docker 还没接触过,有空我了解下。

同步文件其实不是必须的,只是为了在那个环境上编译验证。但是一般自己的代码要编译过了再 push 比较合适, git 钩子就不合适了吧?

因为编译环境不同, flycheck 还没去整,后面我试下能不能开起来。

嗯,是可以自己手动编译安装,但依赖一多的话比较麻烦,而且有时候编译所需的依赖也不一定有。

好像是 gcc 4.4 ,不支持 C++ 11 。

看来大家都用 flycheck ,这个我看下能不能搞起来,在开发环境能把基本的错误检查出来也可以。

用 gcc 4.4 编译一个支持的保证行。

如果目标环境很旧的话,你的第二方案就很好。

rcompile 虽然废弃了,看它还能不能用,能用的话拿来改造一下,加上同步功能:

(define-advice rcompile (:before (&rest _) sync)
  ...do-sync)

这样是最省事的。如果不能用,就看现有的 compile 方法能不能扩展了。

用 Docker 本质上也是透过 SSH。你仍然需要把“远程”编译出错信息里的路径,转换成“本地”,才能 nex-error。所以,Docker 并没有解决这个问题。

不用 git 那就 inotify 配合 rsync 来同步

这个能否说的详细点,是在我的 vbox 中编译出一个完整的 4.4 工具链吗?

嗯,这个确实也是一种办法。前几天折腾了一种 Expect + rsync over ssh + ssh 的方法,我再结合 rcompile 看看。

另外,多谢指点 Docker ,相对来说似乎是一个独立的、自己可控的环境。

原来是用于自动触发同步,手动触发对我来说倒也可以接受,不是很麻烦。

我是针对你之前说的不支持C++11说的,gcc 4.4 也能编译出之后的 gcc 或者 clang。我亲自编译过 clang 3.3 是支持C++11的。

我觉得你就在远程开发可能比较好。

在服务器上搭个虚拟机,然后互相ssh (User mode with redirecting ports),不需要su。

编译环境资源有限,又是很多人在用,虚拟机估计带不起来 :joy:

正向 ssh 其实就够了,只要我在一处开发,一般不需要从编译环境反过来连到我的开发 vbox 。

kvm的性能其实还行吧,CPU效率差容器不多,网络性能和真机无异。Memory的话,运行时是可变的。

1 个赞

不仅仅是自动触发同步,你用 rsync 再写个勾子,自动触发编译,都可以

我也有类似的需求,本地开发,然后远端编译,运行,进行一些测试,也没找到好方法呢

我现在可以编译,然后在本地 next-error 定位下一步错误,可以不用肉眼手工定位到某文件某行了,略爽。待有空时我整理下分享出来。

运行调试没想好怎么结合。

2 个赞

新出的 vs code server 感觉有点意思

有意思是需要前提的。当远程环境很古老就没意思了。

远程编辑的时候,本地充当的仅仅是编辑和显示的角色,所有指令必须从本地发往远程执行,本地工具链再完善也用不上。

所以,要想有意思,首先就要问 code server 能否远程环境跑起来,兼容性这点我认为 Emacs 比 VSCode 有优势。毕竟 Emacs 有历史包袱,VCode 起点很新,不大可能回过头去支持老旧系统和CPU架构

可别认为 code server 是个简单的命令,它必须是一个 headless 版的编辑器,除了没有界面,其他功能都必须具备,就像 PhantomJS 之于 Google Chrome (Chrome 现在也自带 headless 模式了)。

其次要问 code server 配套的扩展/插件(例如 lsp,lint)是否能在远程环境下跑起来,比如 cquery / ccls 依赖最新的 llvm,这对老旧系统来说又是一大难题。我感觉这些扩展和插件支持老旧系统和CPU架构的意愿更低,因为并非所有项目都像 VScode 一样有富爸爸,甚至很多是个人项目。

总而言之,远程的环境,必须能跑一个全功能headles版的编辑器,还要能跑所需的扩展/插件,远程编辑才有意义(或意思)

2 个赞

对,但是抛开主题里的环境比较古老,场景换成一个高性能服务器用于服务端,本地只完成展示和编辑,就很好地贴合需求了。

这样的环境场景对于程序员来说,还算是挺常见的了。

再考虑兼容问题,Emacs 的 Client/Server 设计,本应可以做到类似的效果,但是如

所说,这个 C/S 设计貌似只能做到在 C/S 都在本地,或者是我的理解有误?

1 个赞

搞了一个简陋的包,有兴趣的可以看下,欢迎改进。