Skip to content

feat(mcpp.plugins): 0.2.4 — every rule brings its own environment - #364

Merged
Sunrisepeak merged 1 commit into
mainfrom
feat/mcpp-plugins-0.2.4
Sep 7, 2026
Merged

feat(mcpp.plugins): 0.2.4 — every rule brings its own environment#364
Sunrisepeak merged 1 commit into
mainfrom
feat/mcpp-plugins-0.2.4

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

What changes for a consumer

One edge, and no payload list:

[build-dependencies.mcpp]
plugins = { version = "0.2.4", features = ["rules-cuda"], host-module = true }

Each rule declares the xim payloads it drives, under the feature that selects it
and the accelerator it serves. Two gates, and both must open before a byte is
downloaded — a build that names no accelerator installs nothing.

Why the floor moves to 2026.9.6.6 for every member

One change in the engine rather than five in the rules: a payload a dependency
declared is now both installed and answerable.
Before it, mcpp::xpkg_dir
compared the whole version position against a directory name, so a rule could
declare >=8.5.0, have it installed, and still be told nothing was there — which
is why every project using a rule repeated that rule's own package list.

The floor is documentation, not a gate: nothing here or in the package's manifest
records a per-package engine floor, and the index-level min_mcpp is
deliberately left alone. What an older client gets is legible at the point of
use, and the descriptor now says so rather than claiming a refusal that does not
exist.

The shape of each default

A judgement about coupling, not a style. An exact version where the payload's
version is coupled to something the rule cannot see — a CUDA runtime must not be
newer than the driver it will meet, and the 12.9 line reaches every driver from
r525 where 13.x raises that to r580. A floor where no such coupling exists:
glslang, dpcpp, the CANN toolkit.

mcpp reads the difference: a bare version is a choice, so a project pinning a
different one wins and the override is reported; a >= is a requirement, so a
project pinning below it is refused naming both sides. Either way one version is
installed.

Verification

  • mcpp-plugins CI green on the merge commit 7a834933, including a new step
    that asserts the payloads came from the graph pass rather than the root's:
    no [xlings.workspace] in any device fixture, and mcpp's own
    entries declared by dependencies line for each.
  • Both mirrors downloaded and compared byte for byte; one sha256 names both
    (abcf165e…).
  • The descriptor parses under lua, and latest is 0.2.4 on all three
    platform tables.

使用者从此只写一条边:

    [build-dependencies.mcpp]
    plugins = { version = "0.2.4", features = ["rules-cuda"], host-module = true }

规则包在 `cfg(accelerator = ...)` 与选中它的 feature 之下声明自己驱动的那些
xim 载荷。两重门都要开才下载:feature 说要不要这条规则,selector 说这次构建是不是
真的为设备编译 —— 不带加速器的构建一个字节都不装。

这一版把五个成员的下界统一到 2026.9.6.6,而理由是引擎里的一处改动而不是规则里的
五处:**依赖声明的载荷现在既被安装也被回答**。在那之前 `mcpp::xpkg_dir` 把整个版本
位拿去与目录名比对,于是规则可以声明 `>=8.5.0`、把它装上、然后被告知不存在 ——
这正是每个用规则的工程都要把规则自己的包列表重写一遍的原因。

默认的**形状**是耦合判断而不是风格:版本耦合着规则看不见的东西时写精确版本(CUDA
运行时耦合驱动下界,12.x 够 r525 而 13.x 要 r580),不耦合时写 `>=`(glslang、
dpcpp、CANN 工具包)。mcpp 读得出这个差别:裸版本是**选择**,工程钉别的会赢并被
报出来;`>=` 是**要求**,钉在它下面会被拒绝并点出两侧。两种情形都只装一个版本。

规则**不**声明产物运行时跑在上面的东西。Vulkan ICD 是设备,规则声明它会给每一个有
GPU 的消费者强加一个软件渲染器;`compat:*-runtime` 适配器同理,而且有结构性理由 ——
本包是一条 `[build-dependencies]` 边,它自己的 `[dependencies]` 有意不到达消费者的
target。

两端产物已下载并逐字节比对,一个 sha256 同时命名两者。
@Sunrisepeak
Sunrisepeak merged commit 8e18fe2 into main Sep 7, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant