mirror of https://github.com/logos-co/logos-plugin-qt.git synced 2026-08-27 08:51:07 +00:00

T

Dario Gabriel LipicarandClaude Opus 5 27b83cddca fix(headers): a failing logos-cpp-generator must fail the build

buildHeaders.nix swallowed the generator's exit status:

    logos-cpp-generator ... || {
      echo "Warning: ... may be expected if the module has no public API"
      touch ./generated_headers/.no-api
    }

so every real failure — a plugin the generator cannot dlopen (SDK/ABI
skew), an --api-style the pinned SDK rejects, a missing plugin file —
produced an EMPTY header set and exit 0. `nix build .#headers-<style>`
looked green with an include/ holding nothing but a `.generated`
placeholder, and the first symptom was an unresolved symbol when a
downstream module linked, far from the cause.

The escape hatch was aimed at a case that does not exist in this mode:
the generator introspects the plugin's QMetaObject, so a module with no
Q_INVOKABLE method still yields a wrapper class (with zero methods) and
exits 0. Measured against logos-cpp-sdk's generator:

    Q_INVOKABLE present     -> exit 0, <name>_api.{h,cpp}
    no Q_INVOKABLE at all    -> exit 0, <name>_api.{h,cpp} (no methods)
    plugin fails to dlopen   -> exit 3, nothing written
    retired/unknown api-style-> exit 1, nothing written
    plugin file missing      -> exit 2, nothing written

So "no public API" is signalled by SUCCESS, not by a status, and every
non-zero status is a build error. buildPlugin.nix already treats the
generator's status as fatal; buildHeaders.nix was the outlier.

The generator call moves to lib/generate-module-headers.sh, which:
  * fails the build on any non-zero status, echoing the status, the
    plugin, the api style and the likely causes (pin mismatch first);
  * fails a zero status that produced no <module>_api.{h,cpp} pair, so
    an empty include/ can never be installed;
  * reports a missing generator instead of a bare "command not found".
The install phase's "no headers -> empty include/" branch becomes an
error for the same reason.

tests/test-header-generator-guard.nix drives that script directly (so
the guard under test is the guard the build runs) across: no-public-API
success, generator failure, rejected api style, exit-0-with-no-output,
half-written output, missing generator, and argument forwarding
(--module-only / --api-style / --events-from).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-31 18:16:29 -03:00

.github/workflows

move non-qt specific logic out

2026-04-01 18:05:47 -04:00

cmake

Retarget Qt backend to logos-qt-sdk: three-root resolution in LogosModule.cmake (#10 )

2026-06-12 20:59:29 -03:00

lib

fix(headers): a failing logos-cpp-generator must fail the build

2026-07-31 18:16:29 -03:00

tests

fix(headers): a failing logos-cpp-generator must fail the build