fix(cli): copy external_bin sidecars on Windows by appending .exe#5583
fix(cli): copy external_bin sidecars on Windows by appending .exe#5583Booyaka101 wants to merge 1 commit into
Conversation
`dx bundle` was silently dropping `external_bin` sidecars on Windows.
`copy_external_binaries` constructed the staging path as
`{bin}-{target}` without the `.exe` extension, so `src.exists()` was
always false for the file users actually produce
(`my_backend-x86_64-pc-windows-msvc.exe`). The binary was missing from
`_staging` and no warning was emitted.
Extract the path construction into a small `external_bin_src_path`
helper that appends `.exe` when the target triple contains `"windows"`
(matching the convention already used at `bundler/windows.rs:406` for
the main binary). The replace-based `dest_name` derivation already
preserves the extension correctly because `file_name()` returns it
as-is.
Includes three regression tests:
- path appends `.exe` on every Windows target triple
- path is unchanged on Linux, macOS, wasm32 targets
- end-to-end: stage a real `.exe` in a tempdir, resolve through the
helper, run the exact `file_name().replace(...) + std::fs::copy(...)`
sequence from `copy_external_binaries`, assert the destination ends
up as `my_backend.exe` with the original bytes.
Closes DioxusLabs#5578.
|
The failing check is "Check | Minimum dependency versions" and it errors out inside Same check is failing on #5587 (also opened 2026-05-26) for the same reason. Rhai 1.25.0 was published 2026-05-24, and from that point on The pre-existing successful run on this branch (2026-05-26T15:53Z attempt 1 of run 26353043246) hit it after the 1.25.0 publication window. Not something I can fix from inside this diff. Options on your side would be bumping the |
1 participant
Closes #5578.
dx bundlewas silently droppingexternal_binsidecars on Windows.copy_external_binariesinpackages/cli/src/bundler/mod.rsconstructed the staging path as{bin}-{target}without.exe, sosrc.exists()was always false for the file users actually produce (my_backend-x86_64-pc-windows-msvc.exe). The binary was missing from_stagingand no warning was emitted.Fix
Extract the path construction into a small
external_bin_src_pathhelper that appends.exewhen the target triple contains\"windows\"— matching the convention already used atbundler/windows.rs:406for the main binary. The replace-baseddest_namederivation already preserves the extension correctly becausefile_name()returns it as-is.The check is target-only (not
cfg!(target_os = \"windows\")-gated like the main-binary path does) because the sidecar naming convention is determined by the target platform, not the build host — stagingfoo-x86_64-unknown-linux-gnuon a Windows host should not look for.exe.Tests
Three regression tests added to
bundler::tests:external_bin_src_path_appends_exe_on_windows_targets— path appends.exeon every Rust Windows target triple (msvc, gnu, x86_64, aarch64).external_bin_src_path_no_extension_on_non_windows_targets— path is unchanged on Linux, macOS, wasm32 targets (no false positives).external_bin_src_path_finds_staged_windows_binary— full end-to-end against a real filesystem: stage a real.exein a tempdir, resolve through the helper, run the exactfile_name().replace(...) + std::fs::copy(...)sequence fromcopy_external_binaries, assert the destination ends up asmy_backend.exewith the original bytes.Verified locally on Windows:
cargo test bundler::tests::→ 4/4 pass (3 new + the pre-existingzip_dir_preserves_layout_and_permissions).cargo clippy --bin dx --tests -- -D warningsandcargo fmt --checkboth clean on the touched code.