Comments and docs across the repo still claimed this generator emits the Qt
plugin glue, and pointed `--backend qt` users at logos-qt-generator. Neither
is true: the Qt-plugin (provider) glue is emitted by logos-plugin-qt's
logos-qt-host-generator --backend cdylib, on top of the C ABI this tool emits
with --backend cdylib, and logos-qt-generator owns only `consumer` and `ui`
(it refuses the flag too).
Also corrects the LogosModuleContext header, whose comments described the
retired Qt provider path throughout — `<name>_events.cpp` marshalling into a
QVariantList and a provider `onInit` setting the context. The emitted file is
`<name>_events_cdylib.cpp`, it marshals into nlohmann::json, and the C-ABI
export TU installs the callback. The runtime path it named
(runtime_qt/host/module_initializer.cpp) no longer exists.
The only behaviour change is the text of three --backend/--from-header error
messages, which named the wrong tool. Nothing asserts on them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dynamic (by-name) invoke path already existed and was already ungated at
every layer — lp_client_create / lp_invoke in the C ABI, logos::LpClient above
it, and the Qt client above that. Nothing checked a host service; there was no
gate to open. What was missing was the ERGONOMICS, which is what turned a
supported capability into something callers reached around the umbrella to get.
Three additive pieces, no gate touched:
1. LogosModuleContext::moduleName() — the module's own registry name, i.e. the
origin it authenticates as. The typed wrappers bake their origin in at
codegen time; a by-name call has to state one, and a wrong origin
authenticates as nobody and fails far from the call site. Set through a NEW
`_logosCoreSetModuleName_`, deliberately not a fourth parameter on
`_logosCoreSetContext_`: every generated provider calls that signature, so
widening it would break each one until regenerated, for a value the
generator knows statically. Set before the context, so moduleName() is live
inside onContextReady().
2. LogosModules::dynamic(target) on the origin-bound umbrella — the untyped
client, with the origin baked in exactly as the typed members' is, and
cached per target because LpClient owns a connection. The typed members over
metadata.json#dependencies stay the ordinary way to call another module;
this is for the cases whose target is a runtime value (a proxy, a router).
3. LpClient::getMethods() over the already-exported lp_get_methods. Invoke
without introspect is guessing — a caller that cannot ask what exists can
only hardcode, and a wrong guess fails at runtime like a typo.
Verified: #default builds, and both checks pass (tests, generator-cli).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every provider now goes through the module-impl C ABI, so the LOGOS_METHOD
dispatch path is gone: parseProviderHeader, generateProviderDispatch,
ParsedMethod and the joinDocLines helper only it used (~300 lines), plus the
test that covered it.
`toQVariantConversion` is NOT removed — it is shared with live emitters — and
its test stays.
The flag is REFUSED rather than dropped. Without that, `--provider-header x.h`
falls through to the plugin-path branch, which reads the flag itself as a
plugin path and reports "Plugin file does not exist: --provider-header" — a
missing-file error for what is really a retired mode. It now exits 2 with a
message pointing at interface: "universal".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
