鸿蒙装软件还得手动编译 命令行生态空了三年 它真能填上这个坑？

今儿瞅见在上面正式发布了v1.0, 并非测试版, 乃是能够直接通过brew运行起来的版本。我用手头的开发板进行了尝试, 搞定ohos-sdk与node24之后, 实际仅需两分半钟, 既未报错, 又没去修改PATH, 也没手动下载tar包。以往处理这些事儿, 得翻阅三四个仓库, 抄写一堆命令, 还常常卡在ld: find -lc这类错误上。其并非自行从起始处编写一个包管理器 代码之中多数相关的逻辑直接依照原有路径延续进行 就连brew 以及brew 的提示性语句都未曾予以修改 可要注意的是 底部的内容全然更换过 比如说 默认情况下运用来执行服务管理操作 然而系统里根本不存在这样的事物 于是便绕过此情况 转而采用鸿蒙自身所具备的init机制去启动后台运行的进程 另外还有文件路径方面 鸿蒙系统里路径/是设置为只读性质的 那么brew 就不可以向里放置二进制文件 所以必须把这些文件全都放置到/data/hb的下面位置 随后通过软链接的方式将其连接过去。我尝试了一下安装redis, 它确实成功启动了, redis-cli能够连接得上, 然而redis- -- yes却不行, 原因是鸿蒙不支持在fork之后进行后台驻留。文档当中仅仅有一行字: “已知限制: 不支持模式”, 既不做解释, 也不画大饼。这相对于某些项目写的“未来支持”实在是要有实际得多。它那儿的库里当下存有2000多个包, 然而并非是胡乱堆放的。举例来说要是搜索gdb, 出来的可不单单是gdb本身, 还有配套的gdb-、arm- linux- -- gdb, 甚至就连带有鸿蒙符号表解析补丁的ohos- gdb也在其中。要是搜索curl, 顺带还能推出和jq。它和有些仓库不同, 在有些仓库里搜索别的无论啥出来的都只是单个二进制, 至于用不用得上那就全得靠您自己去猜测。以前安装cmake时最为麻烦的是, 要先对ninja进行编译, 之后再编译cmake, 倘若中间有任何一个依赖未能安装正确, 那么全都需要重新来做。如今采用brew cmake方式, 它会自行拉取适配鸿蒙版的ninja以及zlib, 并且全部编译完成、放置到正确位置以及设置好环境变量。整个流程不仅没有出现弹窗情况也不存在安装向导, 仅有一个进度条, 待进度条跑完后便提示 cmake... Done。它未曾触碰图形界面, 也没有进行APP分发, 官网首页的第一行明确写着, 它仅限命令行工具, 我尝试了一下brew程序, 顿时遭碰到直接报错的情况, 其状态显示为Not : GUI信号, 整体表现体现出不刻意硬撑门面, 也不随意掺杂无关内容凑数的特质, 这点在当前状况下显得颇为干净利落。存在着两个问题, 目前仍处于卡住的状态。其一属于像glibc那样依赖极为强烈的工具, 其中举例为例如, 官方网站表明“暂时不予以支持”, 甚至都没有开启相关的issue, 仅仅只是挂了一个标签“”。其二是在鸿蒙PC版当中运行brew 时会被沙箱阻挡住, 必须要先关闭开发者模式里面的“安全策略强化”。这并非是bug, 而是一种设计上的选择——宁愿使用户手动去开启权限, 也不会偷偷地进行越权操作。我查看了一下它的CI流水线配置情况, 所有的包都是在容器当中进行编译的, 镜像是以官方的ohos-sdk:3.2为依据, 并非是自行进行魔改的内核。每一次提交的时候, 都会自动运行三套测试, 分别是开发板、鸿蒙PC模拟器以及ARM64容器。通过率比较低的包会直接被标记为红色, 无法进入主干。所以它所言的“60%直通”, 并不是随意测试了几个就进行吹嘘, 而是实实在在通过真机运行得出的数字。有人提出疑问: 那其余的百分之四十情况如何呢例如gcc全家桶、gdb新版本这里项目组并未画大饼只是在其中列了个“适配优先级表”通过开发者投票来排序排在首位的是是因鸿蒙编写TS/ArkTS的人员众多排在最后的是emacs理由很实际是“CLI模式能够使用但GUI依赖过多暂时不进行投入”。它并未具备私有仓库功能, 所有内容均处于公开状态, 企事业单位若要使用, 就必须自行搭建Git服务, 更改源地址, 添加签名验证并无一键部署脚本, 也未售卖“企业版订阅”。我向一位维护者进行询问, 他表示: “我们连CDN都尚未启用, 仅仅放置在Git裸仓之中, 旨在追求快速以及稳定。”。我借助brew vim, 弹出了vim、、micro、vis, 并且带有vim-ohos-插件。安装完之后, :里与鸿蒙相关的项目皆为绿色。并非“基本能够使用”, 而是“健康检查通过”。它未曾提及“国产替代”以及“自主可控”这类词汇, 官网口号仅有一句话, 即: “brew on .”, 就连图标还是那只酒瓶的轮廓, 只不过将瓶身涂成了鸿蒙蓝。在我尝试安装node24之际, 它自行下载了预编译而成的ARM64二进制文件, 既没有进行编译, 也没有开展wait等待操作。然而呢, 倘若安装node20, 那便只好自己去编译了, 缘由在于旧版本并未制作预编译包所以没提供此类编译好的版本。它不会装作无所不能这般, 有相应预编译包就直接采用, 没有则不去采用。在最后进行卸载的时候, 其过程也显得干净利落, 就拿brew node24来说, 对于所有相关文件都清扫得彻彻底底, 就连软链接也全都给删除而未残留一点痕迹, 完全没有留下任何“小尾巴”。可某些国产工具就不同, 在卸载完成之后, PATH里面还悬挂着一堆已经失效的路径。在今天晌午十二点十七分的时候, 我于开发板之上敲完了brew , 随后终端返回了空行, 既没有提示, 也没有动画, 更没有“感谢使用”, 就这样结束了。