gh-actions: Build on windows

[JohnAZoidberg]

No description provided.

[grouzen]

LGTM! Thank you for making it available for Win users

[grouzen]

Hi! Need to update the branch for including the latest windows improvement. Hopefully it fixes the build.

[Martin005]

@grouzen After this branch is updated to the latest main, would it make sense to add a Windows release to ci-release.yaml? I think only the matrix needs to be updated in order to have Windows releases 🙂

[grouzen]

@grouzen After this branch is updated to the latest main, would it make sense to add a Windows release to ci-release.yaml? I think only the matrix needs to be updated in order to have Windows releases 🙂

Good shout!

[grouzen]

@grouzen After this branch is updated to the latest main, would it make sense to add a Windows release to ci-release.yaml? I think only the matrix needs to be updated in order to have Windows releases 🙂

FYI the Windows version seems broken and we need a volunteer with Windows installation to fix it: #29

[JohnAZoidberg]

Hmm why can't it link to libgit2 on windows
I don't have issues locally with framework-tool-tui or framework-system on github.

[grouzen]

Hmm why can't it link to libgit2 on windows I don't have issues locally with framework-tool-tui or framework-system on github.

I have no experience with compiling rust for windows. I asked perplexity pro about the errors we get for both msvc and gnu targets and I got this:

These unresolved symbols are all from Windows APIs that live in advapi32.lib, crypt32.lib, and advapi32-related security/registry libraries, but they are not being linked in for libgit2-sys on your Windows build. On MSVC Rust targets, rustc normally adds the required system libraries automatically, so for libgit2-sys this usually indicates its build flags or features are not matching what the linker expects on Windows.​

Root cause
The missing symbols correspond to these libraries:

OpenProcessToken, CheckTokenMembership, CopySid, EqualSid, GetTokenInformation, GetNamedSecurityInfoW, RegOpenKeyExW, RegQueryValueExW, RegCloseKey are in advapi32.lib.​

CryptAcquireContextA, CryptReleaseContext, CryptGenRandom are in advapi32.lib/crypt32.lib depending on how libgit2 is built.​

libgit2-sys is clearly calling these APIs (fs_path.c, rand.c, findfile.c), but your linker line does not include advapi32.lib at all, and crypt32.lib alone is not enough for OpenProcessToken and the SID/registry functions.​

Quick fixes to try
Force linking advapi32 for the build script

Because the failure happens while linking the framework_lib build script, you can force advapi32 in that build’s link flags. Add a .cargo/config.toml in your project root:

For MSVC:

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "link-args=/DEFAULTLIB:advapi32.lib"]

This injects advapi32.lib into link.exe’s default libraries, satisfying OpenProcessToken and related symbols.​

Use the Windows “security” feature of git2/libgit2-sys

If your dependency on git2 or libgit2-sys is configured with features that affect Windows security/registry support, adjust them so they match libgit2’s expectations on Windows:

In Cargo.toml, ensure git2 (or the crate that brings in libgit2-sys) has the default features enabled, or explicitly enable the windows-related feature if the crate exposes one (often called “vendored-openssl”, “https”, or similar). Then rebuild on Windows.​

If you currently disable default features for git2/libgit2-sys, re-enable them for Windows builds so that the crate’s build script can correctly link the necessary system libraries.

Narrow to MSVC-only Windows build

Make sure your matrix entry is exactly:

build: windows
os: windows-2022
use-cross: false
target: x86_64-pc-windows-msvc

And use that same target in .cargo/config.toml as shown above, so the rustflags apply only to MSVC and do not affect Linux.​

Suggested minimal change set
If you want the smallest change that is likely to make CI green:

Keep the Windows job on x86_64-pc-windows-msvc.

Add .cargo/config.toml:

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "link-args=/DEFAULTLIB:advapi32.lib"]

Do not change your Cargo.toml yet; if this alone fixes the build, you can then later clean it up by relying on crate features instead of manual link-args.

This should resolve the 15 unresolved externals for the libgit2-sys objects on the Windows MSVC build.

Sorry if it looks like AI slop, I just don't know how else I can help with this