Dario Gabriel LipicarandClaude Opus 5
34704d1841
This repo's cmake/LogosModule.cmake was a duplicate of
logos-module-builder's, and the build chose between them by module type:
logos-module-builder set LOGOS_MODULE_BUILDER_ROOT only when a MODULE carried
that file (none does), so every ui_qml plugin configured with THIS copy while
every core module configured with the builder's. Both compiled. That is how a
stale generator, a stale host-runtime repoint and a missing source file each
shipped in a green tree.
The CMake module is the builder's build-system contract -- it reads
LOGOS_API_STYLE, LOGOS_MODULE_GO_STATIC_LIBS and generated_code/, none of
which this backend knows about -- and it cannot live here anyway: the
dependency runs builder -> backend, so this repo could never re-export the
builder's file. It is deleted, not forwarded. logos-module-builder now passes
LOGOS_MODULE_BUILDER_ROOT for both module types (its 0ddac92), so the deletion
lands after the routing, not before it.
Consequently:
- lib/default.nix no longer defaults LOGOS_MODULE_BUILDER_ROOT to backendRoot.
A caller that forgets it now gets a FATAL_ERROR from the module's own
CMakeLists instead of a build against whatever this repo contains. That was
backendRoot's only use, so the parameter goes too.
- packages.cmake-module is gone; `default` is logos-qt-host, the output this
repo now produces that a consumer can build.
- cmake/ is gone. LogosViewPluginBase.{h,cpp}.in were read only by the deleted
file. The two LogosViewReplicaFactory templates are read only by
tests/test-rep-file-plugin.nix, so they move into that fixture's own cmake/
and are what they are: a test fixture, not a shipped template.
Checks: header-generator-guard, headers-emitter-routing, qt-host-generator,
rep-file-plugin, vanilla-plugin OK. qt-host fails identically at the pre-change
baseline -- this repo's lock pins a logos-protocol whose TokenManager has no
forIdentity/isolateIdentity, so cpp/logos_api.cpp will not compile from it.
It builds green in the workspace closure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.3 KiB
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>.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. |
logos-qt-host is also the default package.
There is no cmake-module output and no cmake/ directory. LogosModule.cmake
lives in logos-module-builder, and only there. This repo shipped a second
copy until the builder was made to point LOGOS_MODULE_BUILDER_ROOT at its own
copy for every module type: the builder only overrode that variable when a
MODULE carried the file (none does), so ui_qml plugins configured with this
repo's copy while core modules configured with the builder's, and the two drifted
apart in silence. The CMake module reads the builder's own variables
(LOGOS_API_STYLE, LOGOS_MODULE_GO_STATIC_LIBS, generated_code/), so the
builder is where it belongs.
lib / rawLib are pure Nix and stay that way: nothing reachable from them
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)
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