Commit Graph
3 Commits
Author SHA1 Message Date
Dario Gabriel LipicarandClaude Opus 5 3d7e3e68b3 feat: the view templates exist once, and this repo is where
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>
2026-08-16 09:07:05 -03:00
Dario Gabriel LipicarandClaude Opus 5 34704d1841 feat: stop shipping a second LogosModule.cmake
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>
2026-08-16 09:07:05 -03:00
Khushboo Mehta 343eafb294 feat: add support for rep files and its various interfaces needed 2026-04-10 14:50:31 +02:00