.exe could be added to custom builds if the extension is missing

[alexanderjophus]

Testing out cargo dist on a basic Go project here: https://github.com/alexanderjophus/hello-world-go/tree/005e332f775dd79568c3a94ae192045b786741f2

Note: I haven't developed anything for windows before, so not sure how I should handle .exe, however I think that cargo dist should handle renaming the binary from my_binary to my_binary.exe.

This was the error from that run: https://github.com/alexanderjophus/hello-world-go/actions/runs/10433209110/job/28894711643

[Gankra]

Ah I see, because you're using a custom dist command, you need to manually specify to go what the output file should be, extension and all, but cargo-dist is mandating here that you have to give a static command, which is impossible when the output file name is platform-specific.

The immediate workaround is to go full makefile and reimplement exe ext logic yourself but nobody wants that, so I'm just mentioning it for the sake of context. I do wonder if go has some way to ask for this in a way where it picks the ext properly, though.

cargo-dist fudging .exe is certainly a way to handle that, although I worry it could cause exciting accidents (although those accidents would already happen on linux so maybe it's fine actually?).

another option would be for us to finally add templating to some of these inputs so you could write "go -o example{exe_ext}" and cargo-dist would substitute it, although that seems like a pretty heavy hammer here.

...kinda coming around to the "we do exe fudging" solution, strange as it is.

[alexanderjophus]

Could you expand on the templating option?

I'm backtracking a little on the original ask. Should I the author of the binary not ensure exactly how my application is spelt? Might be bad practice, but should I be able to call it on; mac, my_cli; linux, my_super_cli; windows, my_amazing_cli.exe?

The point I'm trying to make is I think cargo dist should package whatever I call it, but it could/should lint for the .exe extension in windows (especially if it's looking for it). I'm happy to close this ticket and follow the Makefile here, unless you think the templating option is the way to go?

[Gankra]

Breaking this up into parts

binary extensions

As far as the final file name we package in archives / unpack to systems: extension isn't really negotiable, and if we were to attempt to let you mess with it we'd just be letting you shoot yourself in the foot for no reason.

On windows the OS relies on the .exe extension to know that it's a runnable executable, unlike macos/linux. If you omit it the binary won't run. Also if my-app.exe is on path my-app will invoke it.

Conversely, on linux/macos if you were to try to install it as my-app.exe to behave uniformly, then my-app would not invoke it, because that's not a convention on those platforms that gets auto-resolved.

binary names

We have several features for renaming/aliasing binaries but none of them are configurable per-platform, because, well, that would be confusing. As you say, it's not a good practice. People want stuff to work the same on different platforms, and they're relying on us to ensure that.

wrt go

In this specific case, the go compiler actually is aware of this and automatically adds .exe to the end of outputs but apparently when -o is passed a filename and not a dir name it gives up on the .exe auto-insertion. So the actual specific recommendation I would make is to have the name the go compiler wants to spit out agree with the one cargo-dist spits out, and avoid the makefile stuff altogether.

wrt future work

If there's something to do in this issue for cargo-dist I would maybe consider an implicit internal rule in cargo-dist that if it's looking for foo.exe and doesn't find it, that it also looks for foo as a last desperate attempt. The templating thing is probably overkill here.