mirror of
https://github.com/logos-co/logos-module-builder.git
synced 2026-08-31 12:11:08 +00:00
Dario LipicarandClaude Opus 5
01bb03f91f
Every module was building a third `headers-std` derivation (a full
logos-cpp-generator run) that nothing ever consumed. buildPlugin.nix
picks a dep's headers with `dep."headers-${apiStyle}"`, and apiStyle is
only ever "lp" (cdylib / core universal) or "qt" (everything else) —
the "std" branch has been unreachable since lp replaced it. Measured:
the recursive derivation closure of a built module contains zero
headers-std, and no revision of buildPlugin.nix ever selected "std".
So drop the producer (`moduleIncludeStd`) and both output aliases
(`<name>-headers-std` and `headers-std`).
The std rung also sat in the middle of the dep-resolution fallback
chain (`headers-lp = ps.headers-lp or ps.headers-std or ps.headers-qt
or ...`). Rather than let it collapse to headers-qt, the lp chain now
throws: handing Qt-typed wrappers to a module whose own codegen ran
with `--api-style lp` fails deep inside a generated source file with a
wall of unrelated-looking Qt type errors. The throw names the dep and
says to rebuild/re-pin it against a current builder. It is lazy, so it
only fires when an lp consumer actually reads `headers-lp` — a Qt
consumer with the same stale dep still resolves to headers-qt exactly
as before.
buildCppPlugin.nix gets the same treatment. Its struct had no
headers-lp entry at all, so an lp consumer reaching that path died with
"cannot coerce a set to a string" from the header copy; now it gets the
same actionable message. (In practice everything built through there is
a ui_qml view module, which is always typed "qt".)
The generator still accepts `--api-style std`; removing that is a
separate step, ordered after this lands and is re-pinned.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>