Fix build on Linux hosts#16
Open
SkyLeite wants to merge 25 commits into
Open
Conversation
CI's MSYS2 libstdc++ doesn't transitively expose the fixed-width integer types (uint8_t/uint32_t/...) that ~95 source files rely on via other standard headers, so the release build failed file-by-file (EventManager, ReplayCreator, ...). Add -include cstdint to CC_FLAGS so every TU gets <cstdint> up front, rather than hand-adding the include to every file. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The release build compiled serially (~3.5 min). The Makefile's recursive phases propagate -j via MAKEFLAGS, so -j $(nproc) parallelizes the main build's compilation while link steps still wait on their object deps — same as scripts/build-steam.sh already does. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CC_FLAGS is shared with the C sources (3rdparty/md5.c, miniz.c, minhook), and <cstdint> is C++-only, so -include cstdint broke the C compiles with "cstdint: No such file or directory". stdint.h works for both C and C++ and still exposes the bare global uint32_t the codebase relies on. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When multiple release tags share the HEAD commit, git describe could pick a lower version (e.g. v4.0 over v4.0.1), producing a binary whose built-in version never matches the GitHub 'latest' release and so re-prompts to update forever. Prefer the highest version tag pointing at HEAD, falling back to the nearest reachable tag. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The release build derived its version from git *inside* the recursive make, but
on the CI runner the MSYS2 git only had safe.directory configured for the Windows
git (set by actions/checkout). make_version's git calls returned empty, so the
archive was named from the tag (vX.Y.Z) while the binary baked in a bogus version
and a bare '-custom' revision. Clients then saw a version that never matched the
release and an exe/dll version mismatch ('incompatible hook.dll').
- Mark the workdir safe.directory for the MSYS2 git too.
- On tag builds, pass FULL_VERSION straight from the tag so the baked-in version
is deterministic and always matches the tag/archive name.
- Add a guardrail step that fails the build if the produced exe doesn't embed the
tag version, so a mis-versioned artifact can never be published.
- Make the release step idempotent (clobber on re-run) so a re-pushed tag updates
the asset instead of failing on an existing release.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The 'Verify baked version matches tag' step used `unzip -p` to read the exe out of the release zip, but the CI MSYS2 environment only installs zip, not unzip, so the step failed with 'unzip: command not found' (exit 127) on tag builds. Grep the built exe directly instead — it's the exact file that gets zipped, so the check is equivalent and needs no extra tool. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The previous fix gated the FULL_VERSION override on $GITHUB_REF inside the msys2
build shell. That check didn't fire on the runner (the override never reached make),
so the build fell back to git-in-make derivation and baked a version that didn't
match the tag — caught by the guardrail ('does not embed version').
Inject the tag version as TAG_VERSION via the Actions context (github.ref_name),
which the runner resolves before the step runs, so it can't be lost by the shell.
Passing FULL_VERSION bypasses git-in-make entirely; verified locally that a full
`make release FULL_VERSION=X` bakes X and passes the guardrail. Also cat the
generated Version.local.hpp after the build for diagnostics.
Co-Authored-By: Claude Opus 4.8 (1M context) <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.
No description provided.