算一算，已经有一段时间没有更新博客内容了，一方面是3，4月份在整点新的论文玩意和养龙虾（Openclaw）/养马（Hermes），外加准备毕业答辩和参加毕业答辩（btw很高兴能在4月底顺利完成毕业答辩😁），另外一方面是沉迷Vibe Coding，工程工作都交给Claude Code做了，但工程推进太快，倒逼个人去不断学习充电，反倒没空去整理笔记😨
但是关于MLIR环境配置这一块，这一块我还是不吐不快。众所周知，MLIR现在是LLVM的子项目，而LLVM项目本身是一个巨大的Monorepo，每次安装都要拉取一堆无关文件，占用硬盘空间，编译速度还慢，所以今天准备写篇文章，好好说说MLIR的环境搭建这事
方案1：从源代码编译
老老实实从头编译肯定是最好的，MLIR的初始教程也是建议大家从零开始编译，但你要是机器一般（笔记本或一般PC），或者网络不行（比如国内），仓库拉取和编译本身就是非常要命的事😰之前在某公司内网部署MLIR环境，光编译参数的调整都不下三四个方案，还而且还不能保证每一个方案，一定能编译使用通过。从那以后，关于MLIR环境，我都是能用二进制分发就不要手动编译
对此，我对这个方案的评价是NPC
方案2：Debian Sid源二进制分发
容器构建是我当时学习MLIR的逃课Idea，Debian Sid的源仓库默认有二进制分发的MLIR，只需要Pull一个Debian Sid容器，直接安装就行，分发起来也很方便
唯一的问题是，容器内不方便perf，但这个方案可以给一个夯，Dev Container是团队协作的正解
（虽然但是，我那个项目直到最后跑路，都没有迎来一个很好的技术Partner😂MLIR门槛还是太高了，环境部署问题能简化解决就简化解决吧）
方案3-推荐方案：包管理二进制分发方案(pixi)
因为众所周知的历史问题，CPP的依赖管理机制是个大坑，而CPP的包管理机制更是五花八门，我知道的方案都不下三四个（Conon，VCpkg，手动脚本管理，apt仓库管理，甚至还见过用Python的venv虚拟环境管理C++依赖的）
而在这里面，Conon我只是听说过但没用过，当时用Debian容器分发就能解决大部分问题，外加当时是用Windows的WSL或远程Linux机器，就没尝试Conon🤔
至于VCpkg，我24年尝试的时候，那个依赖链又臭又长，占硬盘空间的同时，编译速度还慢，在一些小项目还挺好用的，但碰到MLIR这种大项目编译就很慢，后面也没再尝试了😅
至于用Python的venv虚拟环境管理CPP依赖，意外觉得这个方案不错😂（llvm/lighthouse这种示范性项目末甚至用uv管理，配合edusl的包分发），但这个方案二进制不能共享（也许用uv可以实现共享的效果？），如果只是单纯写CPP项目，.venv文件夹看着很膈应，与之相对应的还有conda管理，但在公司使用conda有合规风险，遂放弃
我知道Google他们使用bazel管理MLIR环境，但那玩意儿太复杂了，不适合个人使用
这个包管理机制我感觉棒极了！其默认使用的是conda-forge，不存在Anaconda的合规风险，对于国内，也可以换成conda的清华源解决依赖下载问题
我尝试把我之前用于MLIR项目依赖修改为pixi（mlir-hello-world），很顺利的实现了Mac OS和Linux的依赖管理，这应该是我目前见到最合适的分发方案🤩（顺带Vibe Coding把这项目从LLVM20升级到LLVM22）
而对于PPoPP 2026的Tutorial，我也整理了一个使用Pixi管理的方案（mocusez/mlir-tutor），不然国内使用edusl依赖不要太麻烦（但实际测试conda-forge分发的mlir-python-bindings的MacOS包有问题，会报错LLVM ERROR: Attempting to attach an interface to an unregistered operation，所以目前只支持在Linux下使用）
结语
说到底就是C++依赖问题，我认为Conda生态下的pixi就是当前条件下，跨平台分发的最优解
我推荐任何初学，或者只是想简单尝试MLIR，但不想花时间配置环境的人，都使用Pixi配置MLIR环境👍