Make the tree compile for Windows without touching core logic, by confining all Linux/PipeWire assumptions behind cfg gates and a single platform-selected backend alias. No new dependencies — the cpal/WASAPI backend lands in Phase 1; this ships a no-op stub. - Cargo.toml: move pipewire + rfd(xdg-portal) under cfg(unix); add a cfg(windows) rfd using the Win32 dialog backend. - audio: gate pipewire_impl to unix, add a cpal_impl stub for windows, and select between them via the new PlatformAudioBackend alias. - core: use PlatformAudioBackend instead of the concrete PipeWireBackend. - lib: gate the unix-only 0o600 log-file mode code (+ its test); Windows logs inherit the directory ACL. - audio_probe: gate this PipeWire diagnostic to unix with a stub main. - app: open URLs via rundll32 on windows, xdg-open on unix (shell-free). - ci: add .gitea/workflows/windows-build.yml (M1) — build + lib tests for x86_64-pc-windows-msvc, with CMAKE_POLICY_VERSION_MINIMUM=3.5 for the vendored libopus build. Needs a windows act_runner to actually run. Linux build/clippy/tests green (316/316). The Windows path is verified by inspection only (no local Windows toolchain); CI is the real gate. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
86 lines
3.6 KiB
YAML
86 lines
3.6 KiB
YAML
name: windows-build
|
|
|
|
# Milestone M1 of the Windows port (see docs/handoff windows-migration-plan):
|
|
# prove the tree compiles for `x86_64-pc-windows-msvc` and the unit tests pass.
|
|
# The audio backend is the Phase 0 `CpalBackend` stub for now — this job guards
|
|
# the *compile* boundary (cfg gating, platform deps, the PlatformAudioBackend
|
|
# alias) so a Unix-only assumption can't sneak back in and break Windows.
|
|
#
|
|
# RUNNER REQUIREMENT: this needs a Windows act_runner registered with the
|
|
# `windows-latest` label (the Linux `cargo-deny` job's container approach does
|
|
# NOT apply here — Windows jobs run on the host, not a Linux container). If your
|
|
# runner advertises a different label, change `runs-on` below. Until a Windows
|
|
# runner exists this workflow is simply skipped/queued, not a failure of the
|
|
# Linux CI.
|
|
#
|
|
# BUILD-HOST REQUIREMENTS (validated by the opus spike, see
|
|
# peerspeak-windows-opus-spike.md):
|
|
# - MSVC C toolchain (Visual Studio Build Tools) — to compile vendored libopus.
|
|
# - CMake on PATH — `audiopus_sys` builds libopus from source via cmake.
|
|
# - CMAKE_POLICY_VERSION_MINIMUM=3.5 (set below) — the vendored libopus declares
|
|
# an ancient `cmake_minimum_required` that CMake >= 4.0 refuses without it.
|
|
# GitHub-hosted `windows-latest` images ship MSVC + CMake; a self-hosted runner
|
|
# must provide both.
|
|
|
|
on:
|
|
push:
|
|
# `main` plus the in-progress port branches, so the Windows path is exercised
|
|
# before merge rather than only after.
|
|
branches: [main, "windows-port-**"]
|
|
pull_request:
|
|
# Allow manual runs from the Gitea Actions UI.
|
|
workflow_dispatch:
|
|
|
|
permissions:
|
|
contents: read
|
|
|
|
env:
|
|
CARGO_TERM_COLOR: always
|
|
# The vendored libopus (audiopus_sys -> cmake) uses cmake_minimum_required < 3.5,
|
|
# which CMake 4.x rejects unless this is set. See the opus spike report.
|
|
CMAKE_POLICY_VERSION_MINIMUM: "3.5"
|
|
|
|
jobs:
|
|
windows-build:
|
|
runs-on: windows-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- name: Install Rust (MSVC, pinned to repo toolchain if present)
|
|
uses: dtolnay/rust-toolchain@stable
|
|
with:
|
|
targets: x86_64-pc-windows-msvc
|
|
components: clippy
|
|
|
|
- name: Show toolchain + build prerequisites
|
|
shell: bash
|
|
run: |
|
|
set -euo pipefail
|
|
rustc --version
|
|
cargo --version
|
|
# libopus is built from source via cmake; fail early with a clear
|
|
# message if the runner lacks it rather than deep in the opus build.
|
|
if ! command -v cmake >/dev/null 2>&1; then
|
|
echo "::error::cmake not found on PATH. The opus crate builds libopus from source via cmake; install CMake on this runner."
|
|
exit 1
|
|
fi
|
|
cmake --version
|
|
|
|
# Build on a *locked* tree so the pinned, vetted Cargo.lock versions are what
|
|
# get compiled — same supply-chain stance as the cargo-deny job.
|
|
- name: Build (all targets, msvc)
|
|
run: cargo build --all-targets --locked --target x86_64-pc-windows-msvc
|
|
|
|
# Unit (lib) tests only: the `transport_loopback` integration tests stand up
|
|
# real iroh/QUIC endpoints and need working loopback networking, which isn't
|
|
# guaranteed on a CI runner. Add `--tests` here once a networked Windows
|
|
# runner is confirmed.
|
|
- name: Unit tests (lib, msvc)
|
|
run: cargo test --lib --locked --target x86_64-pc-windows-msvc
|
|
|
|
# Informational for now (not `-D warnings`): the Windows tree may surface
|
|
# platform-specific lints we haven't triaged. Tighten to deny-warnings once
|
|
# it's clean.
|
|
- name: Clippy (msvc)
|
|
run: cargo clippy --all-targets --locked --target x86_64-pc-windows-msvc
|