Skip to content

Add Windows/MSVC support - #161

Merged
TuxedoFish merged 2 commits into
mainfrom
windows/msvc-support
Sep 11, 2026
Merged

Add Windows/MSVC support#161
TuxedoFish merged 2 commits into
mainfrom
windows/msvc-support

Conversation

@TuxedoFish

Copy link
Copy Markdown
Owner

Summary

Gets hyperliquid-sdk-cpp building and passing its full test suite on Windows/MSVC - the last blocker called out for eventually submitting this SDK as an official vcpkg port (vcpkg's port-acceptance CI builds across Windows/Linux/macOS by default).

Fixes needed, found by iterating against real windows-latest/MSVC CI:

  • timegm: POSIX/glibc extension, no MSVC equivalent by that name - added an _mkgmtime/timegm split in ResponseTypes.h::parseOutcomeExpiry (same semantics), plus the <ctime> include it was transitively relying on before.
  • /bigobj: Boost.Asio/Beast's heavy template instantiation blew past MSVC's default COFF object section-table limit (C1128) in WebsocketRunner.cpp.
  • /EHsc: MSVC needs the exception model spelled out explicitly; this codebase throws/catches throughout.
  • NOMINMAX / WIN32_LEAN_AND_MEAN / _WIN32_WINNT=0x0A00: standard guards against Boost.Asio's transitive <windows.h> (min/max macro collisions, header bloat, Asio's own "guessing the target Windows version" warning).
  • ws2_32 / mswsock: Winsock link libraries Asio's networking code needs on Windows, not required on Linux/macOS.
  • CI portability: ci.yml's build-and-test job now sets shell: bash at the job level (Git Bash is present on windows-latest, so the existing bootstrap-vcpkg.sh/mkdir -p steps run unmodified across all four OS/compiler combinations), and Build/Test use --config Release/-C Release (no-ops on Linux/macOS's single-config generator, required for Windows' multi-config Visual Studio generator).

Removed the stale "Windows/MSVC is intentionally out of scope" comment and the temporary branch-scoped windows-experiment.yml used to iterate against real MSVC without waiting on the full Linux/macOS/sanitizer/coverage suite each round.

Stacked on #160 (secp256k1 overlay-port removal) since both are prerequisites for a future vcpkg port submission.

Test plan

  • Windows CI (windows-latest, MSVC): 100% passed, 29/29 tests (verified on this branch before folding into ci.yml's real matrix)
  • Local Linux rebuild + ctest: 29/29 passing, confirming the if(WIN32)/if(MSVC)-guarded CMake changes don't affect non-Windows builds

🤖 Generated with Claude Code

https://claude.ai/code/session_018Le73N2EZjGLsCqmCScAse

Base automatically changed from fix/secp256k1-drop-overlay-port to main September 11, 2026 06:42
@codecov

codecov Bot commented Sep 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.09%. Comparing base (ee37310) to head (b519bfd).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #161   +/-   ##
=======================================
  Coverage   70.09%   70.09%           
=======================================
  Files          54       54           
  Lines        8840     8840           
  Branches      530      530           
=======================================
  Hits         6196     6196           
  Misses       2639     2639           
  Partials        5        5           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Removes the last blocker for eventually submitting hyperliquid-sdk-cpp as an
official vcpkg port - vcpkg's port-acceptance CI builds across Windows,
Linux, and macOS by default, and this SDK had never been built on MSVC.

Fixes needed, found by iterating against real windows-latest/MSVC CI (a
temporary branch-scoped workflow was used to iterate without waiting on the
full Linux/macOS/sanitizer/coverage suite each round, then folded into the
real ci.yml matrix once green - 100% passed, 29/29 tests):

- timegm: POSIX/glibc extension, no MSVC equivalent by that name - added an
  _mkgmtime/timegm split in ResponseTypes.h::parseOutcomeExpiry (same
  semantics), plus the <ctime> include it was transitively relying on.
- /bigobj: Boost.Asio/Beast's heavy template instantiation blew past MSVC's
  default COFF object section-table limit (C1128) in WebsocketRunner.cpp.
- /EHsc: MSVC needs the exception model spelled out explicitly; this
  codebase throws/catches throughout.
- NOMINMAX / WIN32_LEAN_AND_MEAN / _WIN32_WINNT=0x0A00: standard guards
  against Boost.Asio's transitive <windows.h> (min/max macro collisions,
  header bloat, Asio's own target-Windows-version guessing warning).
- ws2_32 / mswsock: Winsock link libraries Asio's networking code needs on
  Windows, not required on Linux/macOS.
- CI: ci.yml's build-and-test job now sets shell: bash at the job level
  (Git Bash is present on windows-latest, so the existing bootstrap-vcpkg.sh
  and mkdir -p steps run unmodified across all four OS/compiler
  combinations), and Build/Test use --config Release/-C Release (no-ops on
  Linux/macOS's single-config generator, required on Windows' multi-config
  Visual Studio generator).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Le73N2EZjGLsCqmCScAse
The "ubuntu-latest always fails, macos-latest hangs" pattern on this branch
wasn't CI flakiness - it was self-inflicted. cmake --build --parallel with
no number resolves to a bare `make -j` on the Makefiles generator (verified
via --verbose), which for GNU Make means *unlimited* concurrent jobs, not
"one per core". This repo's ~80 independent test/example targets all become
ready simultaneously right after the shared library links, and firing all
of them at once as heavy Boost.Asio/Beast compiles exhausts memory on a
standard hosted runner.

Reproduced locally: `systemd-run --user --scope -p MemoryMax=16G` (matching
a typical hosted runner) + the old bare `--parallel` produced the exact same
failure signature as CI - dozens of `gmake[2]: *** [...] Terminated` at the
fan-out point. The same constrained build with `--parallel 4` completes
cleanly (exit 0, 0 Terminated, 29/29 tests pass) - confirming the fix
resolves the actual reproduced failure, not just a guess.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Le73N2EZjGLsCqmCScAse
@github-actions github-actions Bot added the build failing CI is currently failing on this PR label Sep 11, 2026
@TuxedoFish
TuxedoFish merged commit 1629718 into main Sep 11, 2026
12 checks passed
@TuxedoFish
TuxedoFish deleted the windows/msvc-support branch September 11, 2026 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build failing CI is currently failing on this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant