chore: 身份对齐上游 —— ocornut:imgui@1.92.8,app facade 收进 feature

[Sunrisepeak]

生态规范化的第一例,规则与全量迁移表见 mcpp-index#163。

版本:0.0.6 → 1.92.8

0.0.6 是打包计数,消费者看不出拿到的是哪一版 Dear ImGui(实际是 1.92.8-docking)。同一个索引里 compat.imgui@1.92.8、compat.ffmpeg@8.1.2、compat.lua@5.4.7 一直是对的。

命名空间:mcpplibs → ocornut

mcpplibs 不是"上游是谁"的答案 —— 它是 mcpp 的默认命名空间:

// mcpp src/pm/dep_spec.cppm
inline constexpr std::string_view kDefaultNamespace = "mcpplibs";

Dear ImGui 是 ocornut 的,本仓库只是在它之上加 C++23 module 层。索引里 nlohmann.json / fmtlib.fmt / godotengine.godot-cpp-m 早就是这个口径。

为什么两件事必须同批

裸名梯级是 (mcpplibs, X) → (compat, X)。索引现状:

tests/examples/imgui          imgui = "1.92.8"  → mcpplibs 无此版本 → 落到 compat.imgui(源码构建)
tests/examples/imgui-module   imgui = "0.0.1"   → 命中本包

只改版本会让前者在第一级就命中本包,静默换成另一个包。迁出 mcpplibs 后第一级永远落空,现有写法行为不变。

app facade 收进 feature

imgui.app 是本仓库发明的 facade;backends 属于上游(上游自己就发 backends/imgui_impl_glfw.cpp)。所以只 gate 前者 —— 想要原生 ImGui API 的人不该被塞一个框架。

已验证 gating 是真的,去掉 feature 后:

warning: .../src/main.cpp: module 'imgui.app' imported but not provided in this build
error: build failed

带上 feature 正常构建;默认档 mcpp test 3 个用例全过(105s)。

附带发现

模板里 ocornut 是硬编码的 —— mcpp 的模板变量只有 {{self.name}} 与 {{self.version}},没有 {{self.namespace}},于是非默认命名空间的包无法在自己的模板里拼出依赖声明。这会打到每一个带模板的待迁包,另行补。

索引侧的描述符(pkgs/o/ocornut.imgui.lua + 旧条目冻结)需要本 PR 合入后的 tag,另开 PR。

[Sunrisepeak]

更正:PR 描述里「为什么两件事必须同批」那一节的论据是错的

我在描述里写:

tests/examples/imgui 写的是裸名 imgui = "1.92.8",只改版本会让它在第一级命中本包,静默换包。

那个成员写的是限定名,带着段头看是 [dependencies.compat] imgui = "1.92.8"。我只看了 grep 出来的那一行,没看它属于哪个 [dependencies.*] 段。既然明写了 compat,就没有东西能把它换掉 —— 那条"静默换包"的风险不存在。

真正成立的后果是另一条:module 层的成员用的才是裸名(imgui-module 的 imgui = "0.0.1"、ffmpeg-module 的 ffmpeg = "0.0.3" 等),迁出默认命名空间后它们会响亮地解析失败,索引 PR 里必须一并改成限定写法。比我原先描述的风险小得多,也好查得多。

判据与本 PR 的改动都不依赖那条错误论据:命名空间说的是这个库是谁的,版本说的是你拿到的是哪一版上游。同批做仍然对,理由退化成朴素的一条 —— 一次迁移比两次迁移少让用户改一遍写法。

详见 mcpp-index#163 的更正。