Build libicsneo master (icspb/protobuf) in wheel builds#236
Merged
Conversation
…trap libicsneo now requires icspb, whose protobuf codegen breaks under the default Unix Makefiles generator: protobuf v33's protobuf_generate() never creates PROTOC_OUT_DIR and only Ninja pre-creates declared output dirs, so protoc fails with '_deps/icspb-build/protos/: No such file or directory' (reproduced and A/B-verified in docker on 4ed29b4). - bump LIBICSNEO_VERSION to current master (4ed29b4) - configure with -G Ninja on Linux/macOS; add ninja to build requires - share ICSPB_BOOTSTRAP_DIR across cibuildwheel builds so protobuf compiles once per arch, not once per python (vital under QEMU aarch64) - macOS: pass OSX arch/deployment target via environment so icspb's nested protobuf bootstrap builds universal2 instead of arm64-only Verified locally: cp312-manylinux_x86_64 wheel builds end-to-end in docker; libicsneolegacy.so links icspb descriptors; wheel passes check-wheel-contents. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
cibuildwheel deletes each python's isolated build env, but the macOS libicsneo build dir is reused across pythons; CMake cached the previous env's ninja path and cp311+ configures failed with 'no such file or directory'. Reproduced the stale-cache mechanism in docker and verified that passing -DCMAKE_MAKE_PROGRAM=<current ninja> at configure fixes the reconfigure. (Ubuntu's failure in the same run was fail-fast collateral; Windows 'failure' was a cancelled job with every step green.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Upstream's vendored icsnVC40.h is now byte-identical to this repo's (verified), closing the Linux/macOS ABI gap for the grown/new device settings structs (Galaxy2 1204, Comet3 918, Gigastar2 2400, GLOBAL_SETTINGS 2406). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
libicsneo now permanently depends on icspb (protobuf), so python_ics's Linux/macOS wheel builds must build it. The previous attempt to bump the pin (#234 follow-up) failed CI with:
Root cause
protobuf v33's
protobuf_generate()(used by icspb) declares the generated.pb.h/.pb.ccas custom-command outputs but never createsPROTOC_OUT_DIR— and protoc does not create its own output root. The Ninja generator pre-creates directories for declared outputs; Unix Makefiles (whatbuild_libicsneo.pyused by default) does not. A/B-verified in docker on the same libicsneo commit (4ed29b4): Makefiles reproduces the exact CI error, Ninja builds clean.Changes
LIBICSNEO_VERSIONto current master4ed29b4-G Ninjaon Linux/macOS; addninjato[build-system] requiresso the binary is on the isolated build env's PATH in every cibuildwheel environmentICSPB_BOOTSTRAP_DIRto a shared root outside the libicsneo build dir: icspb compiles protobuf from source at configure time, and the Linux job builds 5 Pythons × 2 archs with agit cleanbetween each — sharing the bootstrap (it self-partitions by<system>-<processor>) means one protobuf compile per arch instead of ten. This matters most for aarch64 under QEMU.CMAKE_OSX_ARCHITECTURES/CMAKE_OSX_DEPLOYMENT_TARGETas environment variables too — icspb's nested protobuf bootstrap is a separateexecute_processcmake that inherits env but not-Dcache entries, and would otherwise produce arm64-only static libs that break the universal2 link.Verification
4ed29b4: Makefiles → exact CI failure; Ninja →icspbtarget builds.cibuildwheel --only cp312-manylinux_x86_64run with these changes: wheel builds end-to-end;libicsneolegacy.socontains the icspb proto descriptors and protobuf runtime; wheel passescheck-wheel-contents --ignore W009,W010.ABI parity (updated)
The header sync landed upstream: the pin is now master
0dd8dbf, whose vendoredicsnVC40.his byte-identical to this repo's 3.26.3.9 header (verified). Linux/macOS wheels now match the Windows ABI — Galaxy2 1204, Comet3 918, Gigastar2 2400, GLOBAL_SETTINGS 2406.🤖 Generated with Claude Code