Windows x64 build (library only): add manual workflow

[jbjardine]

Adds a Windows x64 build for the Partout library to catch regressions in the C/Swift core. This first iteration keeps OpenSSL, MbedTLS and wg-go disabled so the core library build can land independently from vendor toolchain follow-ups.

Changes

1. Sources/CMakeLists.txt excludes PartoutWireGuardConnection_C/ when PP_BUILD_USE_WGGO=OFF, mirroring the existing crypto vendor filtering. Without this, the WGGO-disabled build still compiles wireguard.c, which includes wg_go.h unavailable when wg-go is not built.
2. .github/workflows/test.yml adds a Windows x64 library-only build job that verifies libpartout.lib and libpartout_c.lib are produced.

Build configuration

• Swift 6.3 Windows toolchain via compnerd/gha-setup-swift.
• clang-cl from the Swift toolchain as C/C++ compiler, since the C headers use Clang nullability annotations.
• MSVC link.exe / lib.exe via ilammy/msvc-dev-cmd.
• SDKROOT resolved from the Swift installation when the environment does not already provide a valid value.
• Swift runtime paths resolved with swift -print-target-info.
• CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY to avoid fragile executable try-link/resource steps.

Validation

• Preflight PR on fork: Windows x64 build (library only): fix CMake filter and add CI job jbjardine/partout#1
• Run SwiftPM tests: pass
• Windows x64 build (library): pass
• Local Windows container diagnostic produced:
  • bin\windows-amd64\partout\libpartout.lib
  • bin\windows-amd64\partout\libpartout_c.lib

Not in this PR

• Vendor builds for OpenSSL, MbedTLS, or wg-go.
• swift test on Windows.

[jbjardine]

@keeshux The Windows job added by this PR is passing on the upstream run.

The current red check is from the pre-existing macOS Run SwiftPM tests job, in the Verify generated OpenAPI is up to date step. It failed while downloading the existing OpenSSL binary target from GitHub Releases:

https://github.com/partout-io/openssl-apple/releases/download/3.6.300/openssl.xcframework.zip
badResponseStatusCode(504)

I checked the workflow diff: this PR does not change the macOS test job, it only appends the new build_windows job. A recent upstream Unit Tests run on another PR also passed the same macOS job, so this looks like a transient GitHub release/CDN error rather than a regression from this PR.

I don’t have permission to rerun the failed upstream job from my fork. Could you rerun the failed check when you have a moment?

[keeshux]

@jbjardine First, I'm genuinely surprised by a PR about the Windows part of this library, thank you! Second, for similar reasons, I didn't have this on my current schedule, so I'll need more time to see where this might fit.

All in all, this should be a manual workflow (workflow_dispatch), maybe even separate, because the Windows build takes billable CI time for something I'm not working on at this time.

By the way, how far did you get with Partout on Windows? Have you experimented with something in particular, or do you have any goal in mind? I'm very curious now.

Thanks again.

Side note: better not to push force in order to track changes. The PR doesn't need to be perfect all along.

[jbjardine]

@keeshux I adjusted the PR to match that constraint: the Windows build is now a separate manual workflow_dispatch workflow in .github/workflows/windows.yml, and .github/workflows/test.yml is back to the existing macOS-only PR workflow.

So this no longer spends Windows CI minutes on every PR. The fork PR now only runs the existing SwiftPM tests automatically, and that check is green.

I could not trigger the new manual workflow from the PR branch because GitHub only exposes new workflow_dispatch workflows after they exist on the default branch. The exact Windows job content was validated successfully in the fork before moving it to a manual workflow.

Noted on force-pushes. I was trying to keep the branch tidy while the CI shape was still moving, but I’ll use normal follow-up commits from here.

On the Windows status: my goal is mostly personal R&D / community help, low pressure. I’m exploring what it would take to use Partout from a Windows app, with the longer-term idea of understanding whether a Passepartout-like client could eventually be brought to Windows too.

I started by trying to reproduce the Windows build on a fresh toolchain over the weekend. I got as far as a minimal library-only Windows x64 build producing both libpartout.lib and libpartout_c.lib, with vendors disabled.

The working configuration is intentionally small:

• PP_BUILD_LIBRARY=ON
• PP_BUILD_USE_OPENSSL=OFF
• PP_BUILD_USE_MBEDTLS=OFF
• PP_BUILD_USE_WGGO=OFF
• Swift toolchain clang-cl for C/C++
• MSVC link.exe / lib.exe
• SDKROOT resolved from the Swift Windows install
• CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY

I have not reached a full Windows build with vendors or swift test yet. The main blockers I found are vendor/toolchain-specific rather than this CMake filter itself: wg-go currently runs into a MinGW/MSVC linker mix, and OpenSSL hits a Perl/asm issue on the Windows toolchain I tested.

This PR fixes the smallest independent issue I found: the missing CMake filter when wg-go is disabled. Happy to help on follow-ups if it makes sense for you, but no pressure from my side.

[keeshux]

FYI, Passepartout already builds on Windows. Everything is set up to even connect to a VPN, the data and the events are properly bound, but the UI part is missing. The wx app only shows a blank window at the moment on Linux and Windows.

But you are right, the tooling for building the vendors is the real nightmare. I'll follow up on this after I get a beta for Android.

[jbjardine]

@keeshux That’s very useful context, I didn’t realize Passepartout was already that far on Windows.

I’ll keep this PR scoped to the small CMake/workflow cleanup then. No pressure on timing from my side, Android beta sounds like the right priority.

When/if you revisit Windows later, I’d be happy to help with the vendor/tooling part first. From my weekend testing, that also looked like the main reproducibility pain point.