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
3d7e3e68b3
The four LogosView*.in templates had two byte-identical copies:
logos-module-builder/cmake/ (LIVE — LogosModule.cmake)
logos-plugin-qt/tests/rep-file-plugin/cmake/ (fixture — rep-file-plugin)
Nothing compared them. This is the fifth defect of that exact shape in this
refactor, and it was created by the fix for the fourth: when this repo's
duplicate LogosModule.cmake was deleted, the templates it read were MOVED into
the fixture rather than removed, because the fixture still needed them.
It needed them because it cannot reach where they went. The edge runs
logos-module-builder -> logos-plugin-qt, one way, so a fixture inside this repo
can never consume logos-module-builder's copy, and this repo cannot re-export
it either. "Own them in the builder" is not reachable; a copy in the fixture is
what "own them in the builder" degrades into.
So ownership follows the direction that works. The templates are this repo's:
* cmake/ holds the one copy, with cmake/README.md stating the rule and the
argument for it.
* packages.<sys>.logos-view-templates publishes them as a nameable output.
* lib.buildPlugin / lib.generate set LOGOS_VIEW_TEMPLATE_DIR (cmake flag and
env var) on every plugin build, so logos-module-builder's LogosModule.cmake
receives the directory without either repo growing a new input.
* devShellInputs exports it too, so a hand-run cmake in a module dev shell
resolves it the same way.
LogosModule.cmake itself does NOT come back here. That file is the builder's
build-system contract and stays there; only the Qt-specific templates it
instantiates are published from this side of the edge.
The fixture now takes the directory from the harness and has nothing to fall
back to — a missing LOGOS_VIEW_TEMPLATE_DIR is a FATAL_ERROR, not a quiet
second copy. Proof it reads the owned file and not a leftover: changing the IID
in cmake/LogosViewReplicaFactory.h.in makes rep-file-plugin fail its
"IID found in binary" assertion.
rep-file-plugin is also added to CI. It is the check that instantiates these
templates and it was never listed in the workflow, so the templates had no CI
coverage at all — part of why a duplicate could sit in the fixture unnoticed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
19 lines
824 B
Plaintext
19 lines
824 B
Plaintext
// Auto-generated by logos_module(REP_FILE ...) — DO NOT EDIT.
|
|
#include "LogosViewPluginBase.h"
|
|
#include "rep_@LOGOS_REP_BASE@_source.h"
|
|
|
|
#include <QRemoteObjectHost>
|
|
|
|
bool @LOGOS_REP_CLASS@ViewPluginBase::enableRemoting(QRemoteObjectHostBase* host)
|
|
{
|
|
if (!host || !m_backend) return false;
|
|
// The backend must inherit @LOGOS_REP_CLASS@SimpleSource (which the rep
|
|
// compiler generates from @LOGOS_REP_BASE@.rep). Using the templated
|
|
// enableRemoting<@LOGOS_REP_CLASS@SourceAPI> overload publishes the
|
|
// typed source signature so typed replicas on the client side reach the
|
|
// Valid state and start receiving property updates.
|
|
auto* src = qobject_cast<@LOGOS_REP_CLASS@SimpleSource*>(m_backend);
|
|
if (!src) return false;
|
|
return host->enableRemoting<@LOGOS_REP_CLASS@SourceAPI>(src);
|
|
}
|