English | 简体中文
mcpp构建工具的默认包索引仓库。 在线浏览所有包:https://mcpplibs.github.io/mcpp-index/
本仓收录可被 mcpp 直接 add 的 C++23 包,既包含 import 即用的模块化库,也包含以 compat 形态从上游源码或
头文件构建的第三方 C/C++ 库。每个包对应一个 pkgs/<首字母>/<包名>.lua 描述文件。
mcpp add ftxui@6.1.9 # 添加依赖到 mcpp.toml
mcpp build # 自动拉取源码并构建,依赖沿链路自动传递
mcpp search <keyword> # 搜索并刷新索引
mcpp self config --mirror CN # 切换至国内镜像,默认使用 GLOBAL 上游源完整包列表见 在线索引站。
本仓收录两类包:
- 原生 mcpp 模块库:以 C++23 模块发布、
import即用,包括mcpplibs.*、nlohmann.json、imgui、ffmpeg、opencv,以及由 用户基于 mcpp 开发并登记进索引的库(如tensorvia-cpu)。其上游通常自带mcpp.toml,描述文件(Form A)只声明 元数据与下载地址。 - 第三方 C/C++ 库(
compat):其上游不提供 mcpp 支持,描述文件(Form B)内联构建信息。该类库存在 header-only、纯 C 源码、C++23 module wrapper 等形态,可选组件经features门控,并配备 GitCode CN 镜像。
| 形态 | 示例 |
|---|---|
| 原生模块库(Form A) | mcpplibs.xpkg · mcpplibs.tinyhttps · tensorvia-cpu · ffmpeg(模块层,源码经 compat.ffmpeg 直编) · opencv(单仓库:模块层与 OpenCV 5 全源码构建同在包内,索引侧只留本描述符) · mcpplibs.grpc(gRPC 1.83.0 —— 本索引里唯一无法做成 compat 描述符的库:上游不发布任何自包含源码产物,其 tag 归档里 abseil/protobuf/re2/boringssl/zlib 全是空 submodule 占位,因此 grpc-m 的 release tarball 才是那个产物。它只 vendor gRPC 自己的源码,五个依赖全取自本索引,故同时直接使用 protobuf 的消费者链进去的是同一份而非两份) |
C 源码 compat(含 features) |
compat.cjson · compat.zlib |
| C++ 源码 compat(彼此依赖) | compat.abseil(151 TU;对 absl/** 取通配后,按上游自身的 test/benchmark 命名约定裁剪) · compat.protobuf(libprotobuf 运行时,79 TU 逐条转录自上游 src/file_lists.cmake;因 protobuf 公开头文件 include 了 absl/…,故显式依赖 compat.abseil;gzip feature 定义 HAVE_ZLIB 并拉入 compat.zlib,upb feature 则从同一个 tarball 里再编出 protobuf 的 64 TU C 运行时) · compat.re2(22 TU,取自上游自身的 RE2_SOURCES) |
header-only(含 features) |
compat.eigen |
| 运行时 loader compat(纯源码,绕开上游 codegen/asm) | compat.vulkan(Khronos loader:loader/generated/ 已签入,汇编路径经 UNKNOWN_FUNCTIONS_SUPPORTED 降级为纯 C,故无需 CMake/Python/汇编器;windows 延后)· compat.vulkan-headers |
| 全源码直编 + 生成 config(仅缺口平台) | compat.curl(win32 用上游签入 config,unix 生成) · compat.sdl2(win/mac 用上游签入 config,linux 生成 + 手工开 X11) · compat.c-ares(91 TU;release tarball 已自带 ares_build.h 与 Windows 配置,故只需按 OS 冻结 ares_config.h) |
| 上游 codegen 前置冻结进镜像归档 | compat.godot-cpp(两个版本:4.5.0 是 godot-4.5-stable 的绑定,10.0.0-rc1 是 godot-cpp 自己的 10.x 线、对应 Godot 4.6。gen/ 下约 1000 个 GDExtension 类不在任何上游 tag 归档里,由上游 binding_generator.py 在构建时生成。改为离线跑一次,把上游源码树逐字节原样 加上 gen/ 一起发布,消费侧就完全不需要 Python;tools/godot-cpp/repack.sh 可确定性复现该归档,且上游文件一旦有出入即拒绝打包) |
| 补索引空缺的头文件包 | compat.glx-headers(libglvnd 的 GL/glx.h,Khronos registry 不含,SDL 的 X11 后端必需) |
| C++ 应用框架 compat(依赖复用索引内既有包) | compat.eui-neo(上游 3rd/ 自带 8 个 vendored 依赖,此处一个不编,全部改指索引内同版本 compat.*) |
| 互斥后端(同包多后端二选一) | compat.eui-neo:vulkan / sdl2 各自替换默认的 OpenGL / GLFW,默认后端由"不点名任何 feature"表达,并不存在 opengl/glfw feature。default feature 表达不了互斥 —— 它自带的 defines/sources/deps 完全不生效,而 implies 又恒生效、无法被点名的 feature 覆盖(后者反而正好是本表『恒开的 interface define』一行的解法)。可行解是读 mcpp 本就会传的 -DMCPP_FEATURE_<NAME>,在强制包含头里做前置判定。另注意 cflags 只作用于 C TU,C++ 需 cxxflags —— 只写进 cflags 的后端 define 到不了任何 .cpp |
| 宿主运行时适配(不 vendor 驱动) | compat.glx-runtime · compat.vulkan-runtime(mcpp 产物跑在自带 glibc 下,裸 soname 的 dlopen 够不到宿主驱动;用符号链接农场 + runtime.library_dirs 打通。注意 farm 只放带版本号的 soname —— library_dirs 同时进链接行) |
| 恒开的 interface define | compat.curl 的 CURL_STATICLIB:cflags 恒开但包私有,feature defines 可达消费端但需点名 —— default = { implies = … } 无条件生效,恰好两者兼得 |
| 单包多 major(形态随版本切换) | compat.catch2(3.x 编 src/catch2/ 出静态库;2.x 走 single_include/ header-only) |
外部构建系统(install() 从源码构建) |
compat.openblas(Make) · compat.openssl(Perl Configure + Make,静态 libssl/libcrypto) |
| 全源码直编(config 快照 + 源列表,零外部构建系统) | compat.ffmpeg(2281 TU 含 NASM 汇编,28 个目录 glob 声明) |
| 模块层叠在 compat 源码构建之上(外部 Form-A 仓) | godotengine.godot-cpp-m(两个版本与上游对齐:10.0.0-rc1 对应 Godot 4.6,4.5.0 对应 Godot 4.5。import godot_cpp; 重导出整个 godot 命名空间,约 1800 个名字由头文件生成而非手工罗列;1022 个 TU 的构建留在 compat.godot-cpp,索引侧只留这一个描述符。宏 —— GDCLASS、GDREGISTER_CLASS、memnew、ERR_* —— 是具名模块唯一带不走的东西,故包内附一个与 import 并排包含的侧头文件。另外还带一份生成的 hashfuncs.hpp 遮蔽头 —— 上游那个头去掉两个函数的 static(它们体内声明了匿名 union)—— 否则 GCC 直接拒绝该模块接口,且是任何 -W 开关都够不到的硬错误) |
| C++23 module wrapper | nlohmann.json · marzer.tomlplusplus · neargye.magic_enum · boost-ext.ut(逐字复用上游自带的 include/boost/ut.cppm,仅加一处 Clang-on-MSVC 需要的 __argc/__argv shim;命名空间取 boost-ext,因其并非 boost 官方库) |
完整流程定义于 agent skill add-mcpp-index-package。可将下列
指令提供给 agent(如 Claude Code),由其调用该 skill 完成描述文件的编写与全流程:
参考本仓 skill `.agents/skills/add-mcpp-index-package`,将 <库名 / 仓库URL> @<版本> 收录进 mcpp-index:
判定形态;配置 CN 镜像(无 mcpp-res 权限时使用 plain-string 上游 url);编写 pkgs/<首字母>/<包名>.lua;
添加 tests/examples/<库>/ 测试工程并登记为 workspace 成员;使用与 CI 同版本的 mcpp 本地执行
`mcpp test -p <成员>` 进行验证;更新 README 与在线索引;提交 PR 并确认 CI 通过。
细节文档位于 docs/zh/,供人工与 agent 共同使用(英文版位于 docs/):
- 库形态与描述符模板:各类形态的描述符模板与样例,以及最小工程的写法。
- CN 镜像闭环:
gtc与 gitcode 操作,以及无mcpp-res权限时的回退方案。 - 仓库结构与 schema 与 CI:字段速查、选跑机制与本地 lint。
- 字段的权威判定是
mcpp xpkg parse(CI 用的就是它:未知的 mcpp 段字段直接失败,而不是被静默忽略); 语义与约束见 mcpp 仓的docs/spec/。
提交 PR 后,
validate自动执行 lint 并按改动库选跑对应 workspace 成员(整个测试面是一个 mcpp workspace,公开模块包imgui/ffmpeg/opencv/tinyhttps也是普通成员——compat的重定向声明在 workspace 根并由成员继承,消费其他命名空间的成员各自覆盖,零 shell 驱动);合并后,deploy-site将其发布至在线浏览站。
| 项目 | 说明 |
|---|---|
| mcpp | 现代 C++23 构建与包管理工具 |
| xlings | mcpp 底层的包安装引擎与沙箱环境 |
| xpkg V1 spec | 包描述文件规范 |
| mcpplibs | mcpp 生态的模块化 C++23 库集合 |
| mcpp-res | 包资源的 CN 镜像组织(gitcode) |
包描述文件采用 CC0;各上游库保留其自身许可证。