Makefile: do not hardcode GOOS in podman-remote-static target

[xduugu]

Follow-up of #22060 (comment)

Does this PR introduce a user-facing change?

None

[rhatdan]

/approve
LGTM
@containers/podman-maintainers PTAL
Thanks @xduugu

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rhatdan, xduugu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mheon]

@cevich PTAL

[baude]

please use an actual commit message on why we need to do this.

[cevich]

Yes, please write up a complete commit message and PR description. Though I'm glad to see CI passing with this, I don't recall off-hand if any CI builds exercise any of the affected targets. I can double-check once the commit message is ready.

[edsantiago]

Careful - this was added in #14444 to fix #14201, which is a Windows thing, which means it's probably not tested or exercised in CI.

[cevich]

Thanks for the archaeology and confirming Ed. Though IIRC, Windows builds are in a weird CI situation, where we test the installer using a cross-compiled binary but the official release builds come from the winmake powershell script. The later I don't believe runs a build anywhere in CI.

[xduugu]

@baude What do you have in mind? It actually never was required to restrict the OS in podman-remote-static. I just did not remove it when I added the target in #22060, so should I just write this into the commit message?

@edsantiago The podman-remote-static target in #14444 is not the same as the one that I added in #22060. The CI most likely uses the release-artifacts target which again calls make podman-remote-static-linux_amd64 and make podman-remote-static-linux_arm64 to generate the binaries.

The history is:

• Makefile: force podman-remote-static to linux #14444 sets GOOS to linux
• Make released binary names more consistent #16667 renames podman-remote-static target to podman-remote-static-linux_amd64 and adds podman-remote-static-linux_arm64
• Makefile: include release-artifacts target #18238 adds target release-artifacts which uses podman-remote-static-linux_amd64 and podman-remote-static-linux_arm64
• Makefile: add target podman-remote-static #22060 adds a new target podman-remote-static which is also used by podman-remote-static-linux_amd64 and podman-remote-static-linux_arm64

[cevich]

The CI most likely uses the

From various points CI runs:

• make podman-release
• make podman-remote-release-windows_amd64.zip (Linux cross-compile)
• make podman-release-${arch}.tar.gz GOARCH=$arch for a large set of $arch values
• make podman-remote (OSX)
• make podman-remote-release-darwin_amd64.zip and make podman-remote-release-darwin_arm64.zip

I did not track through the Makefile to see if any of those land down $(SRCBINDIR)/podman-remote-static-linux_% (with some value for %)

[TomSweeneyRedHat]

@cevich @edsantiago @baude thoughts on what to do with this one?

[cevich]

Oh sorry I completely forgot about this. IIRC this gives us the option to produce static podman-remote binaries, have I got that right? I think this change is syntactically correct, if somebody else could confirm we're actually touching the $(SRCBINDIR)/podman-remote-static-linux_% target in CI somewhere. If so then this LGTM.

[rhatdan]

/lgtm