ci: pin tile57 by commit, build both Linux arches, and add the release workflow - #11
Merged
Conversation
beetlebugorg
force-pushed
the
feat/ci-releases
branch
from
August 24, 2026 16:14
1b3a0ed to
30f5492
Compare
…e workflow The fix/maplibre-rendering branch CI built against was merged and deleted, which broke the engine checkout. Both workflows now pin the same tile57 commit (edcac13, current main) through one TILE57_REF env var - bump it deliberately to track a new engine. CI's linux job gains an ubuntu-24.04-arm leg so both Linux release targets are proven before tag day. release.yml follows tile57's release model: a v* tag checks the version in cmake/Package.cmake and src/tile57_pi.cpp against the tag, builds the Linux x86_64/aarch64 and Windows x86 import tarballs, and attaches them to a GitHub release with SHA256SUMS. A suffixed tag (v0.2.0-rc1) publishes as a prerelease.
Both mac arches build natively (Homebrew wx/GLEW are host-arch, and a plugin must match the arch OpenCPN runs as). The job pulls the OpenCPN 5.14.0 universal pkg, expands it with pkgutil, and points -DOCPN_APP at the extracted app, so the wxWidgets retarget and ad-hoc re-sign run the same way they do on a user's machine. A verify step asserts every wx reference points into the app bundle, since fix-macos-libs.sh only warns when the app is missing. Releases still skip macOS: Package.cmake has no macOS layout, so the CI artifact is the bare retargeted dylib.
beetlebugorg
force-pushed
the
feat/ci-releases
branch
from
August 24, 2026 18:27
30f5492 to
a23b594
Compare
The pkg installs AS /Applications/OpenCPN.app, so its expanded payload root is the app Contents/ directly and no OpenCPN.app directory exists to find. Locate */Contents/Frameworks - the only part the retarget reads - and derive the app root from it.
zig build lib installed tile57's raw archive on macOS, skipping the ld64 repack the default install runs, so the plugin link failed with "64-bit mach-o member not 8-byte aligned". tile57 1d7a7b7 installs the repacked archive from the lib step too.
…bundle Homebrew's main wxwidgets formula moved to wx 3.3. OpenCPN.app bundles 3.2, and the retarget only rebinds within the same minor (wx keeps ABI across 3.2.x, not across 3.2 -> 3.3), so the 3.3 references were left pointing at Homebrew and the verify step failed. The versioned keg is keg-only, so Configure names its wx-config explicitly.
Homebrew's wxwidgets@3.2 renames wx-config to wx-config-3.2 to avoid clashing with the main formula, so the plain wx-config path did not exist and FindwxWidgets failed.
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.
CI checked out whatever tile57's default branch held at run time. Both workflows now pin the same tile57 commit (edcac13, current main) through one TILE57_REF env var - bump it deliberately to track a new engine.
CI's linux job gains an ubuntu-24.04-arm leg so both Linux release targets are proven before tag day.
release.yml follows tile57's release model: a v* tag checks the version in cmake/Package.cmake and src/tile57_pi.cpp against the tag, builds the Linux x86_64/aarch64 and Windows x86 import tarballs, and attaches them to a GitHub release with SHA256SUMS. A suffixed tag (v0.2.0-rc1) publishes as a prerelease.