Skip to content

fix(deps+heatmap): occtDep checkouts guard + ViewportBody.directMesh drift#68

Open
gsdali wants to merge 2 commits into
mainfrom
fix/occtdep-guard-and-viewportbody-drift
Open

fix(deps+heatmap): occtDep checkouts guard + ViewportBody.directMesh drift#68
gsdali wants to merge 2 commits into
mainfrom
fix/occtdep-guard-and-viewportbody-drift

Conversation

@gsdali

@gsdali gsdali commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator

Two independent fixes, both required for this repo to build clean again.

1. occtDep/occtDepUpToNextMinor checkouts guard

Same fleet-wide fix as OCCTSwiftScripts#69/#70 and OCCTSwiftIO's 2026-06-23 fix: the sibling probe is a plain filesystem check with no guard against SwiftPM's own flat .build/checkouts/ layout, so this manifest's own dependency declaration could flip from url to path mid-resolution whenever this package is consumed transitively (or, as seen here, when one of its own transitive deps — OCCTSwiftScripts — hadn't yet had the same fix merged). Confirmed live: before Scripts#70 merged, this repo's build hit the classic "exhausted attempts to resolve the dependencies graph"; after the merge + this guard, resolution succeeds cleanly.

2. ViewportBody.directMesh API drift (genuinely unrelated bug)

Once resolution succeeded, swift build still failed on Sources/OCCTMCPCore/Tools/HeatmapTools.swift:138: ViewportBody.directMesh(positions:normals:indices:color:) no longer exists in OCCTSwiftViewport — its real init takes a single interleaved vertexData (stride 6), not separate arrays. Fixed by interleaving positions/bnormals into that layout directly (the same idiom OCCTSwiftViewport's own primitive factories use).

Verified

  • swift build: Build complete!
  • swift test --no-parallel: 48/48 tests passed, including signed_deviation_heatmap and the other heatmap tests that exercise the fixed path.

🤖 Generated with Claude Code

gsdali and others added 2 commits July 2, 2026 05:52
…Data directly

ViewportBody dropped the directMesh(positions:normals:indices:color:) factory;
its real init takes a single interleaved vertexData ([px,py,pz,nx,ny,nz,...],
stride 6), not separate positions/normals arrays. Zips the two flat per-vertex
arrays HeatmapTools already builds into that layout — the same idiom
OCCTSwiftViewport's own primitive factories (e.g. .box) use internally.

Verified: swift build succeeds (was failing on this exact API-drift error);
swift test --no-parallel passes 48/48, including signed_deviation_heatmap
and the other heatmap-adjacent tests that exercise this path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…t layout

Same fleet-wide fix as OCCTSwiftScripts#69/#70 and OCCTSwiftIO's 2026-06-23
fix: occtDep's sibling probe (../<name>/Package.swift) is filesystem-based
and fires whenever a same-named directory happens to exist next to this
manifest — including when THIS manifest is itself a transitively-resolved
SwiftPM checkout under a consumer's .build/checkouts/, where SwiftPM lays
every dependency out as a flat sibling. Doesn't affect OCCTMCP's own build
(it's the root package here, so its manifestDir is never inside .build/) but
matters once OCCTMCP itself is consumed as a dependency by something else —
added for fleet-wide consistency with the sweep. Guards both occtDep and
occtDepUpToNextMinor.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant