Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions .github/workflows/mswin-build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,22 @@ jobs:
echo "CONFIGURE_ARGS=$args" >> "$GITHUB_ENV"
shell: bash

- name: Backport -we4013 to the mswin warnflags
# ruby/ruby 091c7d4a54 made C4013 (implicit function declaration)
# an error on mswin. Without it, mkmf's have_func probe for a
# compiler builtin such as __builtin_clzll compiles on a bare
# implicit declaration and reports a false positive, which then
# fails to link. json's parser hits exactly this on Ruby 3.3.
# The fix ships in 3.4 and later, so patch only the older trees
# that still lack it, mirroring the vcpkg.json override above.
run: |
set -ex
if ! grep -q 'we4013' src/win32/Makefile.sub; then
sed -i 's/-we4028 -we4142 -we4047$/-we4028 -we4142 -we4047 -we4013/' src/win32/Makefile.sub
grep -q 'we4013' src/win32/Makefile.sub
fi
shell: bash

- name: Install tools with scoop
run: |
if ((vcpkg.exe help install) -match "manifest") { exit }
Expand Down
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ Package names:
- Release: `ruby-<version>-x64-mswin64_140` (e.g. `ruby-3.4.5-x64-mswin64_140`)
- Snapshot: `ruby-<version>dev-<yyyymmdd>-<commit>-x64-mswin64_140`, so that a dev build can never collide with a release package name

Releases are built from the official release tarball on cache.ruby-lang.org, verified against `pub/ruby/index.txt`. Snapshots are built from a fresh clone of the master branch. Ruby 3.3 has no in-tree `vcpkg.json`, so the builder supplies `tool/mswin/vcpkg-ruby_3_3.json` instead. Packaging is done by `tool/binary-package.rb` from ruby/ruby, downloaded at the commit pinned in `BINARY_PACKAGE_REF` in `mswin-build.yml`. Bumping that SHA is the whole sync with upstream. The script is applied from the outside to the staged install rather than via the in-tree `nmake binary-package` target, so that already-released tarballs (which predate the script) can be packaged and the snapshot naming stays under this repository's control. Before archiving, the script scrubs build-machine paths (such as the `--with-opt-dir` vcpkg path) from the staged `rbconfig.rb` `configure_args`, since mkmf feeds those to every extension build and a leaked absolute path would break gem compilation on the destination machine. Only the staged copy is touched, never the build machine's own installation.
Releases are built from the official release tarball on cache.ruby-lang.org, verified against `pub/ruby/index.txt`. Snapshots are built from a fresh clone of the master branch. Ruby 3.3 has no in-tree `vcpkg.json`, so the builder supplies `tool/mswin/vcpkg-ruby_3_3.json` instead. Ruby 3.3 also predates ruby/ruby `091c7d4a54`, which makes the mswin C4013 warning an error, so the builder appends `-we4013` to its warnflags. Without it `mkmf`'s `have_func` probe for a compiler builtin like `__builtin_clzll` compiles a bare implicit declaration, reports a false positive, and then fails to link, which breaks `gem install json` on the packaged 3.3. Both overrides target only the older trees that need them and no-op on 3.4 and later. Packaging is done by `tool/binary-package.rb` from ruby/ruby, downloaded at the commit pinned in `BINARY_PACKAGE_REF` in `mswin-build.yml`. Bumping that SHA is the whole sync with upstream. The script is applied from the outside to the staged install rather than via the in-tree `nmake binary-package` target, so that already-released tarballs (which predate the script) can be packaged and the snapshot naming stays under this repository's control. Before archiving, the script scrubs build-machine paths (such as the `--with-opt-dir` vcpkg path) from the staged `rbconfig.rb` `configure_args`, since mkmf feeds those to every extension build and a leaked absolute path would break gem compilation on the destination machine. Only the staged copy is touched, never the build machine's own installation.

Every built zip is smoke-tested in the workflow. The zip is extracted, the root name, layout and checksum are checked, the packaged `ruby.exe` is run with PATH restricted to System32 while loading openssl, fiddle, psych and zlib, and its `configure_args` is asserted to carry no absolute path. A native gem (`json`) is then compiled against the package under the VS toolchain to confirm the extension build pulls in no vcpkg path. The zip and its checksum are uploaded as an Actions artifact. Publishing to cache.ruby-lang.org is not wired up yet.

Expand Down