Repository navigation
Description
Context
CMake 4.2.x (the current default on GitHub's macos-latest runners) rejects our weak-node-api build with:
CMake Error in CMakeLists.txt:
The file set "HEADERS", of type "HEADERS", is incompatible with the
"FRAMEWORK" target "weak-node-api".
As a temporary unblock, #375 (and the unit-tests pin in #374) pins CMake to 4.1.2 on macOS CI, which still tolerates this configuration. That's a workaround, not a fix — it freezes our macOS CI on an old CMake and will break again when 4.1.2 becomes unavailable or when contributors run a newer local CMake.
Root cause
packages/weak-node-api/CMakeLists.txt attaches headers to the same target two ways:
- Modern
FILE_SET HEADERS— lines 16-24 - Legacy framework
PUBLIC_HEADER— line 38, inside theif(APPLE)block that also setsFRAMEWORK TRUE(line 32)
CMake 4.2 made a HEADERS file set incompatible with a FRAMEWORK target, so setting both on the Apple build is now an error.
Proper fix
Ensure we don't declare a HEADERS file set while building a framework. Options to explore:
- On Apple (
FRAMEWORK TRUE), rely solely onPUBLIC_HEADERand avoid theFILE_SET HEADERS; on other platforms keepFILE_SET HEADERS. - Or drop
PUBLIC_HEADERand use the file set's own framework/install integration if it covers our XCFramework packaging needs.
Whichever path, verify the produced macOS .framework still contains the expected public headers and the XCFramework packaging is unchanged.
Acceptance criteria
-
weak-node-apiconfigures and builds on macOS with the runner's default CMake (no version pin). - Revert the macOS CMake pin added in ci: pin CMake on macOS weak-node-api tests #375 (and reassess the
unit-testspin from Fix main CI: commit ferric Cargo.lock and pin macOS CMake #374). - macOS
.framework/ XCFramework still ships the correct public headers.
References
- Workaround PR: ci: pin CMake on macOS weak-node-api tests #375
- Related pin: Fix main CI: commit ferric Cargo.lock and pin macOS CMake #374
packages/weak-node-api/CMakeLists.txtlines 16-24 (FILE_SET HEADERS) and 38 (PUBLIC_HEADER)
Activity
kraenhansen commentedon Jul 17, 2026
The CMake pin ended up needed on five jobs, not two — every macOS job that builds the
weak-node-apiframework hits this:unit-tests(Fix main CI: commit ferric Cargo.lock and pin macOS CMake #374)weak-node-api-tests(ci: pin CMake on macOS weak-node-api tests #375)test-iosandtest-ferric-apple-triplets(ci: pin CMake on macOS test-ios and test-ferric-apple-triplets #377)test-macos(pre-existing pin)The proper CMakeLists fix should let us revert the pin from all of them. This spread is exactly the motivation to fix the root cause.
ci: pin CMake on macOS test-ios and test-ferric-apple-triplets (#377)
Split public header packaging between framework and file set