fix(qt-guidelines): qmake is forbidden as a build system, not as a query - #51
Conversation
Applying this skill to Majestic C1 (Qt 6.11 + CXX-Qt 0.9.1 on NixOS) hit a rule that is wrong as written. "Never qmake in new projects" forbids the one thing that makes the skill's own preferred Rust path work on the house platform. The failure was not a Qt 6.11 API incompatibility. cxx-qt-build locates Qt by querying qmake and assumes QtBase and QtDeclarative share one SDK prefix; Nix gives each module its own immutable output, so the build stopped on a missing Qt6Qml.prl. Combining the outputs exposed a second split — libGLX/libOpenGL come from libglvnd. Both are packaging mismatches. Qt 6.11 itself built, linked, and passed the sanitizer and package gates. - SKILL.md and the C++ reference now forbid qmake as the BUILD SYSTEM and state that querying it is a different act and permitted. The toolchain line records Qt 6.11 as validated rather than merely current. - The Rust reference gains §2.1 "Qt Discovery on Nix": the combined qt6.env, libglvnd in buildInputs, QMAKE exported for discovery only, and -fuse-ld=mold per §3.2.1 — pointing at majestic-codex/c1's derivation and devShell as the reference implementation rather than restating them. - Both troubleshooting tables gain a split-Qt-outputs row. - The QML reference records Qt 6.11's stale-accessible-path diagnostics on rebuilt dynamic scene nodes as known Qt behaviour: the tree stays correct and Orca operates it, so the §18.4 gate is an Orca run, not a clean console. Also warns against "fixing" it by pinning Accessible properties onto recycled delegates, which trades a harmless warning for a wrong tree. The Steelbore Standard says nothing about qmake, so this needs no Standard sync. Frontmatter description untouched (826 chars, §5.6 cap 1000). Both bundles rebuilt in this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M94JK8t6zguGCTDP7udiUv
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0621d37143
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| normally. Do not chase the log, and do not paper over it by pinning `Accessible` properties | ||
| onto recycled delegates — that trades a harmless warning for a genuinely wrong tree. The |
There was a problem hiding this comment.
For a model-driven ListView with interactive delegates, this warning discourages the same Accessible.role and Accessible.name bindings that the example at lines 115–139 and the checklist require. Following it literally leaves recycled controls unnamed or without an explicit role, making the verified tree less accessible. Identify the specific warning-suppression workaround that is unsafe rather than broadly telling readers not to attach Accessible properties.
Useful? React with 👍 / 👎.
| Reference implementation: `majestic-codex/c1/packaging/default.nix` (derivation) and | ||
| `majestic-codex/c1/flake.nix` (devShell). Read those rather than re-deriving the | ||
| environment. |
There was a problem hiding this comment.
These majestic-codex/c1/... paths do not exist anywhere in this repository, so consumers installing the standalone skill bundle cannot follow the instruction to read them instead of deriving the environment. Include the reference implementation under this skill's references/ directory or replace this with a public, resolvable reference.
AGENTS.md reference: AGENTS.md:L72-L76
Useful? React with 👍 / 👎.
1 participant
Applying
spacecraft-qt-guidelinesto Majestic C1 (Qt 6.11 + CXX-Qt 0.9.1 on NixOS) hit a rule that is wrong as written:A compliant reading of that forbids the one thing that makes this skill's own preferred path — Rust behind CXX-Qt — build on the house platform.
What actually broke
Not a Qt 6.11 API incompatibility.
cxx-qt-buildlocates Qt by queryingqmakeand assumes a vendor-SDK layout: QtBase and QtDeclarative under one prefix. Nix gives each module its own immutable output, so discovery failed on a missingQt6Qml.prl. Combining the outputs then exposed a second split —libGLX/libOpenGLlive inlibglvnd, not in any Qt output.Both are packaging mismatches. Qt 6.11 itself built, linked, and passed the sanitizer and package gates.
The change
SKILL.md— the prohibition is now scoped to qmake as the build system; querying it is stated as a different act and permitted. The toolchain line records Qt 6.11 as validated (built + sanitizer + package gates against CXX-Qt 0.9.1) rather than merely "current".Spacecraft_Qt_Rust_Guidelines.md— new §2.1 Qt Discovery on Nix: the combinedqt6.env "<name>-qt" [ qt6.qtdeclarative ],libglvndinbuildInputs,QMAKEexported for discovery only,QT_VERSION_MAJOR=6, and the §3.2.1-fuse-ld=moldflag in the same block. It explains why each is load-bearing (separatebuildInputsdo not give qmake one prefix to report; the libglvnd failure only surfaces after the.prlone is solved) and points atmajestic-codex/c1/packaging/default.nix+flake.nixas the reference implementation instead of restating a full derivation.Spacecraft_Qt_Cpp_Guidelines.md— same relaxation for the C++ path, with the reason the build-system half of the rule still stands (a.probesideCMakeLists.txtis two sources of truth).Spacecraft_Qt_QML_Guidelines.md— records Qt 6.11's repeated stale-accessible-path diagnostics on rebuilt dynamic scene nodes as known Qt behaviour: the tree stays correct and Orca operates it, so the §18.4 gate is an Orca run, not a clean console. It also warns against "fixing" the warning by pinningAccessibleproperties onto recycled delegates — that trades a harmless log line for a genuinely wrong tree.Evidence
majestic-codex/c1/packaging/default.nix:32— the combinedqt6.env:99–101—libglvnd,qt6.qtbase,qtEnvironmentinbuildInputs:104–108—export QMAKE=…,QT_VERSION_MAJOR=6,-C link-arg=-fuse-ld=moldevidence/touchstone/m4-nix-qt-package.v1.json— Qt 6.11.0,"build": "pass"evidence/touchstone/m4-orca-accessibility.v1.json— "Qt 6.11 emitted repeated stale-accessible-path diagnostics while rebuilding dynamic scene nodes, although Orca exposed and operated the resulting tree."Scope
The Steelbore Standard says nothing about
qmake, so this is Construct-only — no two-repo Standard sync.Verified
grep -rn -i qmake spacecraft-qt-guidelines/— every surviving hit reads as build-system-only or as the documented query..githooks/check-description-length.py— pass; frontmatterdescriptionuntouched at 826 chars against the §5.6 cap of 1000..github/check-license-files.pyandreuse lint— clean..skillcarries no directory entries.nix build .#majestic-c1-qtwas not run: its closure is 1090 MiB and the build host has ~2.2 GB free.