Skip to content

ci: verify the ferric Apple binaries depend on weak-node-api - #409

Open
kraenhansen wants to merge 2 commits into
nextfrom
claude/pr-336-verify-redo-3nyqjc
Open

ci: verify the ferric Apple binaries depend on weak-node-api#409
kraenhansen wants to merge 2 commits into
nextfrom
claude/pr-336-verify-redo-3nyqjc

Conversation

@kraenhansen

@kraenhansen kraenhansen commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Redo of #336 (and the #335 it was stacked on), rebased onto next and with the check actually verified against a real CI run instead of guessed.

To help increase confidence and avoid future regressions, the "Test ferric Apple triplets" job now checks the otool output too, so it doesn't only assert which architectures were produced but also that every produced binary actually links weak-node-api.framework.

Changes

  • Run otool -L alongside lipo -info on the built framework binaries, and upload both as artifacts.
  • Assert that every binary slice lists a dependency on weak-node-api.framework.
  • Rename lipo-info.txt to lipo-output.txt, for symmetry with the new otool-output.txt.

Why not a hard-coded count

#335 hard-coded -ne 4; #336 changed it to 7, reasoning "3 fat binaries + 4 thin binaries". Both are wrong, and in two independent ways that a hard-coded number can't express:

  1. otool -L prints one header — and therefore one dependency list — per architecture slice for a fat file, not one per file. With 3 fat (2 archs each) + 4 thin binaries there are 10 dependency lists, not 7.
  2. Not every slice spells the dependency the same way (see below).

So the expected count is now derived from the otool output itself by counting its header lines. It can't drift out of sync with the lipo fixture above it, and it doesn't need updating when a triplet is added or dropped. The step echoes what it found, so the numbers are visible in the job log on success as well as failure.

What the verification run turned up

The first run of this check on CI reported:

Found 8 weak-node-api dependencies across 10 binaries

The two misses were the macOS slices. macOS frameworks use the versioned bundle layout, so the install name there is

@rpath/weak-node-api.framework/Versions/0.1.1/weak-node-api

where iOS, tvOS and visionOS get the flat

@rpath/weak-node-api.framework/weak-node-api

Both are a genuine dependency on the framework, so the pattern now accepts an optional Versions/{version}/ path component. This is exactly the sort of detail a hard-coded 4 or 7 would have papered over — with 7 the check would have passed while two slices went unmatched, and the number would have looked "verified".

After the fix, CI reports:

Found 10 weak-node-api dependencies across 10 binaries

Extends the "Test ferric Apple triplets" job so it doesn't only assert
which architectures were produced, but also that each produced binary
actually links the weak-node-api framework, catching regressions where a
triplet builds but drops the dependency.

The expected number of `@rpath/weak-node-api.framework/weak-node-api`
lines is derived from the otool output itself — `otool -L` prints one
header per file, or one per architecture for fat files — rather than
hard-coded, so it doesn't rot when a triplet is added or dropped.

Also renames lipo-info.txt to lipo-output.txt for symmetry with the new
otool-output.txt, and uploads both as artifacts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SrPdjhQ6aG949mVDDaiT2U
The first CI run of this check reported 8 dependencies across 10 binary
slices. The two misses were the macOS slices: macOS frameworks use the
versioned bundle layout, so weak-node-api's install name there is

  @rpath/weak-node-api.framework/Versions/0.1.1/weak-node-api

where iOS, tvOS and visionOS get the flat

  @rpath/weak-node-api.framework/weak-node-api

Both are a genuine dependency on the framework, so match the optional
"Versions/<version>/" component rather than only the flat form.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SrPdjhQ6aG949mVDDaiT2U
@kraenhansen kraenhansen self-assigned this Aug 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants