A pipewire type in a cfg(any(linux, test)) signature has been holding the Windows client leg red #267

Merged

enricobuehler merged 1 commits from worktree-padaudio-win-cfg into main 2026-08-16 10:02:10 +00:00

Conversation 0 Commits 1 Files Changed 1

+6 -1

enricobuehler commented 2026-08-16 08:59:34 +00:00

Owner

Copy Link

Copy Source

main has been red on both Windows client jobs since the pad-audio work landed:

error[E0433]: cannot find module or crate `pipewire` in this scope
   --> crates\pf-client-core\src\pad_audio.rs:368:39
368 | pub(crate) fn sink_from_props(props: &pipewire::spa::utils::dict::DictRef) -> …
error: could not compile `pf-client-core` (lib test) due to 1 previous error

x64 and arm64 fail on the identical error, same file and line.

Why

pad_audio.rs gates its pure-logic helpers cfg(any(target_os = "linux", test)), so the sink-picking decisions stay unit-testable on every platform. sink_from_props was given that same gate — but it is not pure logic. It takes a &pipewire::spa::utils::dict::DictRef, and pipewire is declared under [target.'cfg(target_os = "linux")'.dependencies].

On Windows the test arm therefore pulls the item into the lib test target, where the crate does not exist. Nothing but --all-targets compiles that target, which is why no Linux gate could see it — including the container gate used to validate the original change, which lints pf-client-core for the host target only.

The change

One attribute:

-#[cfg(any(target_os = "linux", test))]
+#[cfg(target_os = "linux")]
 pub(crate) fn sink_from_props(props: &pipewire::spa::utils::dict::DictRef) -> Option<SinkNode> {

The function's sole caller already lives inside a plain cfg(target_os = "linux") block and no test refers to it, so the test arm was only ever dead weight.

Linux codegen is unchanged: target_os = "linux" was already true on the old arm, so the item compiles there exactly as before.

Is this a pattern or a one-off?

Swept before touching anything — it is a single site:

• of the 13 cfg(any(target_os = "linux", test)) items in pad_audio.rs, this is the only one that names a Linux-only crate (checked against pipewire, sdl3, pf_vaadec, libloading, x11rb);
• the other 13 pipewire references in the file all sit under a plain cfg(target_os = "linux");
• no other file in pf-client-core uses that gate at all.

Verification

The CI clippy line replayed verbatim on the actual windows-amd64 runner, both legs, each in its own target dir so the live CI dirs (C:\t, C:\t-a64) were untouched:

Leg	Command	Result
x64	full CI package list, --all-targets --target x86_64-pc-windows-msvc -- -D warnings	clippy-x64-exit=0
arm64	same minus pf-console-ui, plus --no-default-features, --target aarch64-pc-windows-msvc	clippy-a64-exit=0

Plus Linux (pf-client-core, container): cargo fmt --all --check, cargo clippy --all-targets -D warnings, cargo test — all 0, and non-vacuous (the crate really was compiled, not judged fresh).

The Windows script asserted the shipped tree carried the new gate and that the old one was gone before running clippy, so the green is not a stale-tree artifact. Scratch and target dirs were removed afterwards (runner 37.5 → 39.4 GB free; it is disk-policed at 35 GB).

Note for whoever runs gates over ssh next

ssh … 'powershell -NoProfile -File x.ps1' returns exit 0 while the execution policy refuses to run the script. My first run "passed" having compiled nothing. -ExecutionPolicy Bypass -File is the fix, but the real lesson is to judge such a run by a marker line in its log rather than by ssh's exit code.

`main` has been red on **both** Windows client jobs since the pad-audio work landed: ``` error[E0433]: cannot find module or crate `pipewire` in this scope --> crates\pf-client-core\src\pad_audio.rs:368:39 368 | pub(crate) fn sink_from_props(props: &pipewire::spa::utils::dict::DictRef) -> … error: could not compile `pf-client-core` (lib test) due to 1 previous error ``` x64 and arm64 fail on the identical error, same file and line. ## Why `pad_audio.rs` gates its pure-logic helpers `cfg(any(target_os = "linux", test))`, so the sink-picking decisions stay unit-testable on every platform. `sink_from_props` was given that same gate — but it is not pure logic. It takes a `&pipewire::spa::utils::dict::DictRef`, and `pipewire` is declared under `[target.'cfg(target_os = "linux")'.dependencies]`. On Windows the `test` arm therefore pulls the item into the `lib test` target, where the crate does not exist. Nothing but `--all-targets` compiles that target, which is why no Linux gate could see it — including the container gate used to validate the original change, which lints `pf-client-core` for the host target only. ## The change One attribute: ```diff -#[cfg(any(target_os = "linux", test))] +#[cfg(target_os = "linux")] pub(crate) fn sink_from_props(props: &pipewire::spa::utils::dict::DictRef) -> Option<SinkNode> { ``` The function's sole caller already lives inside a plain `cfg(target_os = "linux")` block and no test refers to it, so the `test` arm was only ever dead weight. Linux codegen is unchanged: `target_os = "linux"` was already true on the old arm, so the item compiles there exactly as before. ## Is this a pattern or a one-off? Swept before touching anything — it is a single site: - of the **13** `cfg(any(target_os = "linux", test))` items in `pad_audio.rs`, this is the only one that names a Linux-only crate (checked against `pipewire`, `sdl3`, `pf_vaadec`, `libloading`, `x11rb`); - the other **13** `pipewire` references in the file all sit under a plain `cfg(target_os = "linux")`; - no other file in `pf-client-core` uses that gate at all. ## Verification The CI clippy line replayed verbatim on the actual `windows-amd64` runner, both legs, each in its own target dir so the live CI dirs (`C:\t`, `C:\t-a64`) were untouched: | Leg | Command | Result | |---|---|---| | x64 | full CI package list, `--all-targets --target x86_64-pc-windows-msvc -- -D warnings` | `clippy-x64-exit=0` | | arm64 | same minus `pf-console-ui`, plus `--no-default-features`, `--target aarch64-pc-windows-msvc` | `clippy-a64-exit=0` | Plus Linux (`pf-client-core`, container): `cargo fmt --all --check`, `cargo clippy --all-targets -D warnings`, `cargo test` — all 0, and non-vacuous (the crate really was compiled, not judged fresh). The Windows script asserted the shipped tree carried the new gate *and* that the old one was gone before running clippy, so the green is not a stale-tree artifact. Scratch and target dirs were removed afterwards (runner 37.5 → 39.4 GB free; it is disk-policed at 35 GB). ## Note for whoever runs gates over ssh next `ssh … 'powershell -NoProfile -File x.ps1'` returns **exit 0 while the execution policy refuses to run the script**. My first run "passed" having compiled nothing. `-ExecutionPolicy Bypass -File` is the fix, but the real lesson is to judge such a run by a marker line in its log rather than by ssh's exit code.

enricobuehler added 1 commit 2026-08-16 08:59:38 +00:00

fix(client-core): a pipewire type in a cfg(any(linux, test)) signature broke the Windows client leg ... d5838f381a

Main has been red on both Windows client jobs since the pad-audio work landed:

    error[E0433]: cannot find module or crate `pipewire`
       --> crates\pf-client-core\src\pad_audio.rs:368:39
    error: could not compile `pf-client-core` (lib test) due to 1 previous error

`pad_audio.rs` gates its pure-logic helpers `cfg(any(target_os = "linux", test))` so the
sink-picking decisions stay unit-testable on every platform. `sink_from_props` was given
the same gate, but it is not pure logic: it takes a `&pipewire::spa::utils::dict::DictRef`,
and `pipewire` is declared under `[target.'cfg(target_os = "linux")'.dependencies]`.

So on Windows the `test` arm pulls the item into the `lib test` target, where the crate
does not exist. Nothing but `--all-targets` compiles that target, which is why no Linux
gate could see it — including the container gate used to validate the original change,
which lints pf-client-core for the host target only.

The function's sole caller already lives inside a plain `cfg(target_os = "linux")` block
and no test refers to it, so the `test` arm was only ever dead weight. Dropped it.

Swept the rest of the crate for the same shape: of the 13 `cfg(any(target_os = "linux",
test))` items in pad_audio.rs, this is the only one that names a Linux-only crate, and no
other file in pf-client-core uses that gate. All 13 other pipewire references sit under a
plain `cfg(target_os = "linux")`.

Linux codegen is unchanged: `target_os = "linux"` was already true on that arm, so the
item compiles exactly as before there.

enricobuehler merged commit cd8e19a7d5 into main 2026-08-16 10:02:10 +00:00

enricobuehler deleted branch worktree-padaudio-win-cfg 2026-08-16 10:02:34 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX HitFrostbite enricobuehler (Enrico Bühler) kszlim luxus nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#267