Skip to content

Windows support for skit #162

@leogdion

Description

@leogdion

skit currently doesn't run on Windows. The library is largely platform-agnostic, but several gaps need closing before the executable is usable.

Known gaps

  • Sources/SyntaxKit/Execution/String+DylibFilename.swift: add an os(Windows) case returning .dll (it currently falls through to .dylib, which is wrong on Windows).
  • Sources/SyntaxKit/Execution/OutputCache.swift: add a Windows cache-root branch (%LOCALAPPDATA%\SyntaxKit\cache via FOLDERID_LocalAppData or the env var fallback).
  • Build-bundle flow: bash scripts don't run natively on Windows. Options:
    • PowerShell sibling (Scripts/build-skit.ps1).
    • Move bundle creation into a Swift target that runs on every platform (preferred long-term; less duplication).
  • DLL search-path strategy: Windows uses the binary's directory as a default search path, so the macOS-style lib/ subdirectory layout may need SetDllDirectoryW or a flat layout. Verify with a smoke test.
  • TerminationStatus+ExitCode.swift:41 already guards .signaled with #if !os(Windows) — confirm the Windows path still returns a meaningful exit code on abnormal termination.
  • Help text and diagnostics still say "libSyntaxKit.dylib" — make them platform-aware.
  • CI: add a Windows job that runs a built bundle end-to-end (currently only `swift build`/`swift test`).

Dependencies

  • `swift-subprocess` Windows backend is less battle-tested than macOS/Linux; expect to hit issues and contribute upstream.

Out of scope

  • Native Windows installer (MSI/WinGet).
  • Cross-compiling from macOS/Linux (deferred until the native build is proven).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions