Investigate: can a Linux host with Windows export templates actually cross-export a working Windows build? nf-158n ← Beads

closed priority 2 task unassigned activesession:cut-release

Twinned from https://github.com/cfsh/ninefold/issues/1031 by tools/beads/import_github.py's reconcile pass.

Split out from PR #1028's review (ninefold-reviewer, sha 2c6f6c2), which asked for this as its own tracked issue rather than prose in a merged PR body.

While setting up --linux-only releases (#570, #1028), found that this Linux box's Godot 4.7.1-stable mono export-templates package (Godot_v4.7.1-stable_mono_export_templates.tpz) bundles BOTH platforms' binaries in one archive — windows_release_x86_64.exe sits right next to linux_release.x86_64. That undersells the old framing ("Windows export templates are Windows-side") — the templates themselves aren't platform-pinned, only release.py's engine-lookup glob was.

Open question, genuinely unverified: does a Linux-hosted Godot editor, with those templates installed, actually produce a WORKING Windows .exe via --export-release Windows? Godot's .NET export does a `dotnet publish -r win-x64 --self-contained` under the hood for the C# assemblies, which is normally cross-host-safe — but real edge cases (icon embedding, rcedit-style resource patching, self-contained single-file publish quirks) are known to sometimes need the target OS's own tooling. Nobody has actually run this export and tried the resulting .exe.

If it works, release.py could drop the --linux-only restriction (or default platforms to ALL_PLATFORMS from any box) and #570 closes for real, not just half. If it doesn't, that's worth knowing precisely (which step fails, or produces a binary that doesn't run) rather than assumed.

Suggested approach: export the Windows preset from a Linux box into a throwaway directory (never publish it), then hand the .exe to Aedan or a Windows box to actually run. Not urgent — --linux-only covers today's need.

Unclaimed.

Dependencies

None.

Comments

No comments.

Add a comment