mirror of
https://github.com/logos-co/logos-plugin-qt.git
synced 2026-08-27 08:51:07 +00:00
Dario Gabriel LipicarandClaude Opus 5
67ba6efe29
The qt api-style path emitted its per-dependency wrappers from
logos-cpp-generator's legacy ApiStyle::Qt emitter — a second implementation of
the consumer surface, with its own conversion table and its own transport. The
qt-generator `--backend consumer` veneer exists to replace it so there is ONE
transport, one codec and one Qt type mapper under both consumer surfaces. It was
golden-tested and wired into nothing.
The umbrella is what made this non-obvious. `--general-only` emits both the
per-dep wrappers AND logos_sdk.{h,cpp} (the LogosModules aggregate);
`--backend consumer` emits no umbrella at all, and the umbrella is live —
storage-ui and wallet-ui both use LogosModules. Nor is the umbrella
style-agnostic: makeUmbrellaHeaderFromDeps branches hard on apiStyle, emitting
`LogosModules(LogosAPI*)` with `dep(api)` members for qt and a
default-constructible struct with `dep("<origin>")` for lp.
What it IS agnostic to is WHICH generator produced the wrappers for a given
style — the qt branch's two constructor shapes are exactly what the consumer
backend emits for Static and Bound, and both spell the member's type with the
same PascalCase routine, shared through cpp-sdk's share/lidl-frontend. So
cpp-generator still emits the umbrella into a scratch dir, from which only
logos_sdk.{h,cpp} is copied, and qt-generator emits the wrappers. No legacy
wrapper text reaches the build tree; the shipped wrapper has exactly one author.
--dep is dropped from the umbrella call (those flags only drive wrapper
emission; the umbrella's members come from metadata.json dependencies), while
--interface is kept, because the bind_<name> factories come from the interface
names and a cross-repo interface can only reach the generator through a flag.
The lp path is emitted verbatim as before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
logos-plugin-qt
Everything specific to running a Logos module as a Qt 6 plugin, in one repo: the build logic logos-module-builder delegates to, and the runtime that build produces plugins against. Keeping both here is what lets the plugin technology be swapped without touching the module builder or individual modules.
Outputs
| Output | What it is |
|---|---|
lib / rawLib |
The Nix build functions (buildPlugin, buildHeaders, devShellInputs). rawLib takes its Logos deps as arguments; lib pre-fills them from this flake. |
packages.<sys>.cmake-module |
LogosModule.cmake — the CMake half of the plugin build. Also the default package. |
packages.<sys>.logos-qt-host |
The Qt host runtime a plugin links: LogosAPI, LogosAPIProvider, LogosProviderBase + the LOGOS_PROVIDER / LOGOS_METHOD macros, the legacy QtProviderObject adapter, and core/interface.h. Static library, headers, and a find_package(logos-qt-host) config. |
packages.<sys>.logos-qt-host-generator |
Emits the Qt plugin glue around a cdylib module's C ABI (<name>_cdylib_glue.{h,cpp}) from its LIDL contract. |
The first two are pure Nix / CMake and stay that way: nothing reachable from
lib, rawLib or cmake-module mentions the two C++ derivations, so a
consumer that only wants the build functions never realises a Qt or protocol
build to get them.
Layout
lib/ the Nix build functions (buildPlugin, buildHeaders)
cmake/ LogosModule.cmake
cpp/ the Qt host runtime library (logos-qt-host)
core/interface.h the legacy Qt plugin interface (PluginInterface)
qt-host-generator/ the cdylib -> Qt-plugin glue emitter
nix/ derivations for the two C++ outputs
tests/ flake checks