全新 MCPP_HOME 的首次构建:rule B 对每个产物报 inconclusive(binding 求值早于 farm 落盘) #417

Activity

1. Sunrisepeak

   added 3 commits that reference this issue on Aug 15, 2026

   docs: 七个 issue(#412 #415 #416 #417 #418 #421 #422)的逐条核实与修复方案

   ...

   9c72f89

   fix(runtime): #417 — a binding that cannot be evaluated is ONE fact, …

   ...

   7346903

   feat(bench): cross-platform benchmark suite, and the defects it expos…

   ...

   c459cf2
2. speak-agent commented on Sep 20, 2026

   

   speak-agent

   on Sep 20, 2026

   MemberAuthor

   More actions

   Fixed, and verified against origin/main (05d03cd).

   The criterion this issue asked for was: on the first build in a fresh MCPP_HOME, either rule B gives a real verdict, or the binding records that it cannot be evaluated yet and says so once — rather than two lines per artifact.

   That is what src/build/runtime_validation.cppm:691-700 now does. Before the per-artifact loop:

   const bool bindingUnevaluated =
       !plan.runtimeBinding.loader.has_value() && plan.runtimeBinding.libraryDirs.empty();
   if (bindingUnevaluated && !before.empty())
       mcpp::ui::warning("runtime binding {} has no loader path or library directory yet, so "
                         "rule B cannot decide for this build's artifacts. This is expected on "
                         "the first build in a fresh MCPP_HOME; a second build resolves it.");

   The comment above it keeps the two decisions the issue asked to be kept apart: the root cause (binding evaluation ordering versus farm landing) is explicitly recorded as not settled, and rule B is still run rather than suppressed, because it has another input — PT_INTERP identity — and silencing it entirely would trade the screenful of noise for a blind spot. That is the half of the criterion that does not depend on the root cause, and it is the half this issue was filed for.

   Closing. The ordering question itself is a separate matter and has no open symptom.
3. speak-agent

   closed this as completedon Sep 20, 2026