compat.yaml-cpp 0.8.0 and 0.9.0, measured on openkal; the site's openkal facet names openkal-ecosystem and openkal-compat; a shorter README

compat.yaml-cpp builds upstream's CMake target as it is (src/*.cpp plus the
contrib GraphBuilder), from the GitHub tag archives mirrored byte for byte to
gitcode mcpp-res/yaml-cpp. YAML_CPP_STATIC_DEFINE, a PUBLIC definition of a
static build upstream, reaches consumers through a yaml-cpp/dll.h shim, since
descriptor `defines` stay package-private; the test asserts it at compile time.
Each version has a member (yaml-cpp, yaml-cpp-v080), and both are measured on
openkal.

The test found an upstream defect: GraphBuilderInterface's pure virtual
destructor is defined nowhere, so a derived class links only when its user
defines it. The test does, as any consumer must; the descriptor does not.

The site's openkal facet had three sentences for values (openkal itself /
runs on openkal / fails on openkal). It now has two names: openkal-ecosystem
for the packages that make up openkal, openkal-compat for packages measured
to run in an openkal graph. A package that only builds or fails is filed
under neither; its page still shows the per-target measurement.

The README keeps one line per shape in its reference table; the long
explanations for recastnavigation and huxerui move into the descriptor
catalog, which gains a yaml-cpp row.

Author: Sunrisepeak

.agents/docs/2026-09-23-add-yaml-cpp-plan.md

@@ -0,0 +1,59 @@
+# compat.yaml-cpp 0.8.0 / 0.9.0
+
+## Shape
+
+C++ source compat (Form B). Upstream's CMake target is `src/*.cpp` plus, with
+`YAML_CPP_BUILD_CONTRIB` at its default ON, `src/contrib/*.cpp`. No configure
+step, no generated header, no platform code in the library. 0.9.0 adds one TU
+(`src/fptostring.cpp`, over the vendored `src/contrib/dragonbox.h`) and one
+public header (`yaml-cpp/fptostring.h`); one glob covers both versions.
+
+Tags are spelled differently upstream (`0.8.0`, `yaml-cpp-0.9.0`), so the wrap
+dirs differ (`yaml-cpp-0.8.0/`, `yaml-cpp-yaml-cpp-0.9.0/`); `*` absorbs both.
+
+## Mirror
+
+gitcode `mcpp-res/yaml-cpp`, releases `0.8.0` and `0.9.0`, assets byte-identical
+to the GitHub tag archives (sha256 checked after download from both sides; each
+GitHub archive downloaded twice, digest stable).
+
+| version | sha256 |
+| --- | --- |
+| 0.8.0 | `fbe74bbdcee21d656715688706da3c8becfd946d92cd44705cc6098bb23b3a16` |
+| 0.9.0 | `25cb043240f828a8c51beb830569634bc7ac603978e0f69d6b63558dadefd49a` |
+
+## YAML_CPP_STATIC_DEFINE
+
+Upstream makes it a PUBLIC definition of a static build and reads it only in
+`include/yaml-cpp/dll.h`, which every public header reaches. A descriptor's
+`defines` are package-private, so `mcpp_generated/yaml-cpp/dll.h` defines it
+and `#include_next`s upstream's; `mcpp_generated` is first in `include_dirs`.
+The compile database confirms the consumer TU carries no `-D` for it, and the
+test's `#error` guard passes: the shim delivered it.
+
+## Upstream defect found by the test
+
+`GraphBuilderInterface` declares its destructor pure virtual and defines it
+nowhere, in both versions. Any derived class (upstream's own `GraphBuilder<Impl>`
+included) fails to link with `undefined symbol: ~GraphBuilderInterface()`
+unless its user defines it. The descriptor does not supply the definition: a
+consumer that already writes it would then get a duplicate symbol. The test
+writes it, as any consumer of the contrib API must.
+
+## Features
+
+None. Contrib is on by default upstream and is two small TUs; there is no
+optional component worth a gate.
+
+## Verification
+
+- `mcpp test -p yaml-cpp` / `-p yaml-cpp-v080` with the pinned mcpp 2026.9.18.3,
+  cold: `test result ok`. Objects: 32 + test TU (0.9.0), 31 + test TU (0.8.0),
+  equal to the source count.
+- 0.8.0 member asserts at compile time that `yaml-cpp/fptostring.h` is absent,
+  so it cannot pass by silently resolving 0.9.0.
+- openkal: both members are listed in `tests/openkal/members.toml`. Locally,
+  `x86_64-linux-gnu`: `runs (posix)` for both. The Windows leg is taken from
+  the PR's openkal-compat run (a local run with an unpinned mcpp failed inside
+  openkal-llvm-runtime's libunwind for the cli11 control member as well, so it
+  says nothing about this package).

.xpkgindex/plugins/mcpp.py

@@ -46,17 +46,25 @@ def _t(en: str, zh: str, hant: str) -> Dict[str, str]:
     ("external", _t("upstream mcpp.toml", "上游 mcpp.toml", "上游 mcpp.toml"), "neutral"),
 ]
 
-# Whether a package's test project builds and runs on openkal, measured by
-# tests/openkal/compat.py and recorded in .xpkgindex/openkal-compat.json. The
-# label is a measurement, never a declaration: a descriptor carries no field for
-# it. Ordered from the strongest statement to the weakest.
+# The two values the `openkal` facet files a package under, and the badge each
+# puts on the package. They are names, not sentences, and are the same in every
+# language:
+#
+#   openkal-ecosystem  a package that makes up openkal (OPENKAL_FAMILY below)
+#   openkal-compat     a package whose test project was measured to RUN in an
+#                      openkal graph, by tests/openkal/compat.py, recorded in
+#                      .xpkgindex/openkal-compat.json
+#
+# `openkal-compat` is a measurement, never a declaration: a descriptor carries
+# no field for it. A package measured only to build, or to fail, is filed under
+# neither -- the facet lists what a reader can pick, and that package's page
+# still shows its per-target measurement with the first diagnostic.
 OPENKAL_LEVELS = [
-    ("family", _t("openkal itself", "openkal 本身", "openkal 本身"), "module"),
-    ("runs", _t("runs on openkal", "在 openkal 上运行", "在 openkal 上執行"), "module"),
-    ("builds", _t("builds on openkal", "在 openkal 上构建", "在 openkal 上建置"), "header"),
-    ("fails", _t("fails on openkal", "在 openkal 上失败", "在 openkal 上失敗"), "neutral"),
-    ("n/a", _t("not applicable", "不适用", "不適用"), "neutral"),
+    ("ecosystem", _t("openkal-ecosystem", "openkal-ecosystem", "openkal-ecosystem"), "module"),
+    ("compat", _t("openkal-compat", "openkal-compat", "openkal-compat"), "module"),
 ]
+# The measured level -> the facet value it is filed under.
+_OPENKAL_FACET = {"family": "ecosystem", "runs": "compat"}
 _OPENKAL_RANK = {"fails": 0, "builds": 1, "runs": 2}
 
 # How a package's best-measured target relates to the platform, orthogonal to
@@ -514,11 +522,12 @@ def on_package(self, pkg, raw: Dict[str, Any]) -> None:
 
         level = self._openkal_level(pkg.identity.slug)
         if level:
-            pkg.facets["openkal"] = level
             ext["openkal"] = {"level": level,
                               **(self.openkal_by_package.get(pkg.identity.slug) or {})}
-            if level in ("runs", "builds", "family"):
-                label = {k: lbl for k, lbl, _ in OPENKAL_LEVELS}[level]
+            facet = _OPENKAL_FACET.get(level)
+            if facet:
+                pkg.facets["openkal"] = facet
+                label = {k: lbl for k, lbl, _ in OPENKAL_LEVELS}[facet]
                 pkg.extensions.setdefault("_badges", []).append(label)
 
             # Wired the same way as `level` just above: a measurement, not a

CHANGELOG.md

@@ -7,6 +7,23 @@
 
 ## [Unreleased]
 
+### Added
+
+- **`compat.yaml-cpp` 0.8.0 与 0.9.0。** YAML 1.2 解析与生成,按上游 CMake 目标原样编译
+  (`src/*.cpp` + `src/contrib/*.cpp`),GLOBAL + GitCode CN 镜像字节一致。上游把
+  `YAML_CPP_STATIC_DEFINE` 作为静态构建的 PUBLIC 定义;描述符的 `defines` 到不了消费者,
+  所以用 `yaml-cpp/dll.h` 的同名遮蔽头送达,测试在编译期断言它到了(MSVC ABI 上缺它就是
+  dllimport 链接错误,Linux 上看不出来)。两个版本各有一个测试成员(`yaml-cpp`、
+  `yaml-cpp-v080`),都列入 `tests/openkal/members.toml` 在 openkal 上测量。
+
+### Changed
+
+- **站点的 openkal 分面改为两个取值:`openkal-ecosystem` 与 `openkal-compat`。** 原先的
+  「openkal itself / runs on openkal / fails on openkal」是句子而不是名字。构成 openkal 的
+  包归入 `openkal-ecosystem`;测试项目在 openkal 依赖图中测得 `runs` 的包归入
+  `openkal-compat`。只测得 `builds` 或 `fails` 的包不再归入分面,其页面仍按目标列出测量结果
+  与第一条诊断。
+
 ### Fixed
 
 - **索引制品按提交只定一次字节,两个托管端提供同一份。** 同一提交重跑发布(夜间 cron)

README.md

@@ -2,24 +2,14 @@
 
 **English** | [简体中文](README.zh-CN.md)
 
-> The default package index repository for the [`mcpp`](https://github.com/mcpp-community/mcpp) build tool.
+> The default package index for the [`mcpp`](https://github.com/mcpp-community/mcpp) build tool.
 > Browse every package online: **https://mcpplibs.github.io/mcpp-index/**
 
-This repository hosts the C++23 packages that `mcpp` can `add` directly — both modular libraries that are ready to
-`import`, and third-party C/C++ libraries built from upstream sources or headers in `compat` form. Every package maps
-to one `pkgs/<initial>/<name>.lua` descriptor file.
-
-> **Engine floor (mcpp 2026.9.18.3):** `openkal-musl 0.15.0` and any future
-> `[c-abi]` package require the engine that ships with `mcpp 2026.9.18.3`
-> or later — the host-macro strip on Windows hosts and the freestanding
-> wchar realisation are what let the c-abi probe verify a declaration
-> without host contamination. The `min_mcpp` floor on `[indices]`,
-> `MCPP_VERSION`, and the per-package pins under `tests/openkal/pins.toml`
-> all gate this together (raising only the index floor would still let
-> 30 members E0006 before reading any source line). Older engines
-> silently misbuild `[c-abi]` packages: the build succeeds, the probe
-> fails, the program compiles against the wrong environment. Upgrade:
-> `xlings install mcpp --force`.
+The C++23 packages `mcpp` can `add` directly: modular libraries ready to `import`, and third-party C/C++ libraries
+built from upstream sources in `compat` form. Each package is one `pkgs/<initial>/<name>.lua` descriptor.
+
+> **Requires mcpp 2026.9.18.3 or later** (`min_mcpp` in [`index.toml`](index.toml)). Older engines silently misbuild
+> `[c-abi]` packages such as `openkal-musl`. Upgrade: `xlings install mcpp --force`.
 
 ## Usage
 
@@ -31,44 +21,36 @@ mcpp search <keyword>          # search and refresh the index
 mcpp self config --mirror CN   # switch to the CN mirror; GLOBAL upstream is the default
 ```
 
-For the full package list, see the **[online index site](https://mcpplibs.github.io/mcpp-index/)**.
-
-## Package ecosystem and contributing
+## Package kinds
 
-Two kinds of packages live here:
-
-- **Native mcpp module libraries**: shipped as C++23 modules and ready to `import` — `mcpplibs.*`, `nlohmann.json`,
-  `imgui`, `ffmpeg`, `opencv`, plus libraries developed on top of mcpp by users and registered into the index (such as
-  `tensorvia-cpu` and `huxerui.huxerui`). Their upstream usually carries its own `mcpp.toml`, so the descriptor (Form A) only declares
-  metadata and a download address.
-- **Third-party C/C++ libraries (`compat`)**: upstream offers no mcpp support, so the descriptor (Form B) inlines the
-  build information. These come in several shapes — header-only, plain C sources, C++23 module wrapper — with optional
-  components gated behind `features` and a GitCode CN mirror configured.
+- **Native mcpp module libraries** (Form A): upstream carries its own `mcpp.toml`; the descriptor only declares
+  metadata and a download address. `mcpplibs.*`, `nlohmann.json`, `imgui`, `opencv`, `tensorvia-cpu`, …
+- **Third-party C/C++ libraries** (`compat`, Form B): upstream has no mcpp support, so the descriptor inlines the build.
+  Header-only, C/C++ sources, or a C++23 module wrapper; optional parts sit behind `features`; a GitCode CN mirror
+  serves the same bytes.
 
 ### Reference examples
 
-A few descriptors worth opening first, one per common shape:
-
-| Shape | Example | What it shows |
-|------|------|------|
-| Native module library (Form A) | [`mcpplibs.cmp`](pkgs/c/cmp.lua) · [`mcpplibs.tinyhttps`](pkgs/t/tinyhttps.lua) · [`gzj-creator.galay`](pkgs/g/gzj-creator.galay.lua) | Upstream carries its own `mcpp.toml`; CMP demonstrates a coroutine runtime, while Galay demonstrates a multi-module package with feature-scoped protocol layers |
-| C-source compat | [`compat.cjson`](pkgs/c/compat.cjson.lua) | One `.c` compiled into a lib; the optional extension sits behind a `features` gate |
-| Header-only | [`compat.gtl`](pkgs/c/compat.gtl.lua) | Nothing to compile — `include_dirs` and an anchor TU |
-| Whole-source build + generated config | [`compat.c-ares`](pkgs/c/compat.c-ares.lua) | The config header configure would have produced is snapshotted into `generated_files` |
-| Multi-component upstream flattened into one lib | [`compat.recastnavigation`](pkgs/c/compat.recastnavigation.lua) | Recast Navigation 1.6.0 — upstream is five inter-dependent CMake libraries; here the two every consumer uses are the base and the other three are `features`, all compiled into one lib. Their dependency edges have to be rebuilt by hand, which is why `debug-utils` carries `implies = { "tilecache" }`: upstream links DetourTileCache unconditionally, and without the implication a consumer asking only for debug drawing fails at link with missing `dtTileCache*` symbols. Upstream's install puts every header flat under `include/recastnavigation/` **and** keeps both that directory and its parent on the interface include path, so both `<Recast.h>` and `<recastnavigation/Recast.h>` are legal against a real install — 26 generated forwarding headers restore the second spelling for a source-tree build. `RECASTNAVIGATION_DT_POLYREF64` and `RECASTNAVIGATION_DT_VIRTUAL_QUERYFILTER` are deliberately NOT features: they change the ABI of types crossing the library boundary, and a feature's `defines` reach only the package's own TUs |
-| C++23 module wrapper | [`nlohmann.json`](pkgs/n/nlohmann.json.lua) | A generated `.cppm` turns a header-only library into `import` |
-| C++23 module, upstream's own | [`khronos.vulkan-hpp`](pkgs/k/khronos.vulkan-hpp.lua) | Khronos ships `vulkan.cppm`, so the descriptor just names it — `import vulkan;` with nothing authored here |
-| External build system | [`compat.openssl`](pkgs/c/compat.openssl.lua) | An `install()` hook drives upstream's own Perl Configure + Make |
-| Form A whose consumer deps must be written by hand | [`huxerui.huxerui`](pkgs/h/huxerui.huxerui.lua) | HuxerUI declares its GTK4 stack on the TARGET axis, which is the form mcpp recommends and which a descriptor structurally cannot carry — three platform blocks, and a cfg selector is not a platform. `mcpp emit xpkg` says so and emits empty `deps`, so the 36-entry closure is transcribed into `xpm.linux.deps` at PLATFORM level (a per-version `deps` is inert). Its `licenses`/`repo` also deliberately disagree with what emit produces |
+One descriptor per common shape:
 
-The full catalog — every shape this index has needed, and the reasoning behind each descriptor including what it
-deliberately leaves out — is in **[Descriptor examples by shape](docs/descriptor-examples.md)**.
+| Shape | Example |
+|------|------|
+| Native module library (Form A) | [`mcpplibs.tinyhttps`](pkgs/t/tinyhttps.lua) · [`gzj-creator.galay`](pkgs/g/gzj-creator.galay.lua) |
+| C sources + `features` | [`compat.cjson`](pkgs/c/compat.cjson.lua) |
+| C++ sources, several versions | [`compat.yaml-cpp`](pkgs/c/compat.yaml-cpp.lua) |
+| Header-only | [`compat.gtl`](pkgs/c/compat.gtl.lua) |
+| Generated config header | [`compat.c-ares`](pkgs/c/compat.c-ares.lua) |
+| C++23 module wrapper | [`nlohmann.json`](pkgs/n/nlohmann.json.lua) |
+| C++23 module shipped by upstream | [`khronos.vulkan-hpp`](pkgs/k/khronos.vulkan-hpp.lua) |
+| External build system (`install()`) | [`compat.openssl`](pkgs/c/compat.openssl.lua) |
+
+Every other shape, and why each descriptor is written the way it is, is in
+**[Descriptor examples by shape](docs/descriptor-examples.md)**.
 
 ### Adding a package
 
-The full procedure is defined in the agent skill
-[`add-mcpp-index-package`](.agents/skills/add-mcpp-index-package/SKILL.md). Hand the instruction below to an agent
-(Claude Code, for example) and it will invoke that skill to write the descriptor and carry out the whole flow:
+The procedure is the agent skill [`add-mcpp-index-package`](.agents/skills/add-mcpp-index-package/SKILL.md). Hand an
+agent (Claude Code, for example) this instruction:
 
 ```text
 Following this repo's skill `.agents/skills/add-mcpp-index-package`, add <library name / repo URL> @<version> to
@@ -78,27 +60,18 @@ member; verify locally with the same mcpp version CI pins by running `mcpp test
 the online index; open a PR and confirm CI is green.
 ```
 
-Detailed documentation lives in [`docs/`](docs/), written for humans and agents alike:
-
-- [Library shapes and descriptor templates](docs/package-types.md): descriptor templates and samples for each shape,
-  plus how to write the minimal project.
-- [Descriptor examples by shape](docs/descriptor-examples.md): the full catalog of what is already in the index, and
-  why each descriptor is written the way it is.
-- [The CN mirror loop](docs/cn-mirror.md): `gtc` and gitcode operations, plus the fallback when you have no
-  `mcpp-res` access.
-- [openkal compatibility](docs/openkal-compat.md): what the `openkal` label on the site means, how it is measured, and
-  how a package is adapted to an openkal graph.
-- [Repository layout, schema and CI](docs/repository-and-schema.md): field cheat-sheet, selective-run mechanics and
-  local lint.
-- The **authoritative** judge of a field is `mcpp xpkg parse` (exactly what CI runs: an unknown mcpp-segment field
-  fails outright instead of being silently ignored); for semantics and constraints see
-  [`docs/spec/`](https://github.com/mcpp-community/mcpp/tree/main/docs/spec) in the mcpp repository.
-
-> Once a PR is open, `validate` runs lint automatically and selects the workspace members affected by the changed
-> library (the whole test surface is one mcpp workspace, and the public module packages
-> `imgui`/`ffmpeg`/`opencv`/`tinyhttps` are ordinary members too — the `compat` redirect is declared at the workspace
-> root and inherited by members, while members that consume another namespace override it themselves, with zero shell
-> driving). After the merge, `deploy-site` publishes it to the online browser.
+A PR runs lint and tests only the workspace members that depend on the changed descriptors; after the merge,
+`deploy-site` publishes the site.
+
+## Documentation
+
+- [Library shapes and descriptor templates](docs/package-types.md)
+- [Descriptor examples by shape](docs/descriptor-examples.md)
+- [The CN mirror loop](docs/cn-mirror.md)
+- [openkal compatibility](docs/openkal-compat.md): the `openkal-ecosystem` / `openkal-compat` labels on the site
+- [Repository layout, schema and CI](docs/repository-and-schema.md)
+- The authoritative check of a field is `mcpp xpkg parse`, which CI runs; semantics are in mcpp's
+  [`docs/spec/`](https://github.com/mcpp-community/mcpp/tree/main/docs/spec).
 
 ## Related links