在 clang64 环境下,没有装似乎没办法通过编译。
可以试试不装这个,然后根据 configure 的输出装其他的。
在 clang64 环境下,没有装似乎没办法通过编译。
可以试试不装这个,然后根据 configure 的输出装其他的。
编译了一份 ucrt+native comp 出来,体感确实比 29.2 好不少
今天重新体验了一下,是要快一些。
用scoop安装,不要装emacs-k,emacs-k安装到C:\Program Files\WindowsApps目录。
建议装emacs-kl,emacs-kl安装在scoop目录下。速度比emacs-k更快,我也不知道为啥。
scoop install emacs-kl
对,但全面的测试有点难搞,我就借 native-comp 作者的 benchmark 随便跑跑了。
Windows app是运行在受控环境中,性能会差些,安全性更好。emacs-kl 就是原生exe,性能更好。
用 UCRT64 版本两天了,几个问题:
这个我之前看日本有些博客折腾过,是可以的,只不过比较麻烦。让官方编译的 Windows 版 Emacs 29.2 的 native-comp 特性生效
这个得像官方提供的预编译版本一样,把 Emacs.exe 要用到的 dll 库全都放到 Emacs 安装(也就是 make install 的那个目录)目录的 bin
下,也得一个一个弄很麻烦。
Windows Defender 算是 Emacs 在 Windows 上慢的一个很大原因,不管是编译还是运行。
看来得写一个辅助工具,递归检查 exe 和 dll 依赖的 dll 了。
没办法,Windows 不装杀毒软件就等于给黑客当筛子。
那 Linux 为啥不需要装?
kiennq最近编译出来emacs.exe真是小呀
这个问题讨论得很多嘛。随便说几个,一,大部分 linux 软件是从可信任的包管理器安装的,而 Windows 软件不是。二,linux 软件大多都是开源的,开源多少能增加软件代码被人审查的机会。三,不像 Windows 软件大多拥有全盘的访问权限,linux 有手段可以严格限制一个软件访问哪些目录。还有很多原因,也有一些是劣势。其中最关键的大概是很少有不安全源下载的软件这一点了。
linug入手门槛比windows高,并且linux大多数情况下都是使用包管理器安装,windows用户更倾向于去网站下载exe,另外就是系统文件权限的问题,windows下的管理员权限被滥用也不是一天两天的了
好奇怪啊,上面的那个构建我使用就莫名其妙的高CPU,用你说的这个就正常,而且速度确实提升不少
主要原因还是因为 linux 的用户水平大部分都比较高,不会像小白那样随便找个 exe 不管三七二十一直接双击运行。要是 linux 成了主流的桌面系统,然后到处都是闭源野包不知道哪里来的 deb 满天飞,那一样安全性是个问题。
没那么麻烦,用 Process Explorer - Sysinternals 很容易就能找到 EXE 加载了什么 dll:
打开 Process Explorer 之后可以打开 Lower Pane(菜单 View → Show Lower Pane 或者 Ctrl + L),然后在上面选中 Emacs.exe 即可。或者使用菜单里面的 Find 然后搜索 emacs。
这个是检查正在运行的 Process,看起来应该比 ldd
效果更好。
我找找它有没有 CLI 接口,如果有的话就可以方便地集成进打包脚本和 CI/CD 里了。
找到了:
P.S. 这个工具的作者好像现在是 Azure 的 CTO 吧?
对对,这是一个重要原因。我只是举些例子~ 覆盖不全还望海纳。
试了下kiennq最新的emacs31 ucrt,发现出现了编码的问题,又是典中典的GBK与UTF-8的斗争……
编码没问题啊, 只需要加这一行就行了。
(prefer-coding-system 'utf-8)
其实还有更方便的方法,把 MSYS2 的库先都复制过去,打开 Emacs,再把所有库选中删除,Windows 不让删正在用的库就能把需要的给过滤了