What's the benefit of this compared to "local" that is accepted by docker build(x) ? Also, "platform" is not a good name for this. Eg. build's default platform is the platform of the server that is definitely more common. Building for a local CLI system is more like an edge case and only works reliably in cross-compile dockerfiles as most users are on macos/windows..

What's the benefit of this compared to "local" that is accepted by docker build(x) ? Also, "platform" is not a good name for this. Eg. build's default platform is the platform of the server that is definitely more common. Building for a local CLI system is more like an edge case and only works reliably in cross-compile dockerfiles as most users are on macos/windows..

I have a edge case where I want to be able to know the current local platform in order to use it in an HCL function. It's not for purely dedicated build usage. But yeah it can be confusing with this name. Something like localplatform lgty?

Something like localplatform lgty?

I guess that is fine. Could also be builtin var. We already added one for remotes and want to add another for --install. Probably more in the future.

@tonistiigi

Could also be builtin var. We already added one for remotes and want to add another for --install. Probably more in the future.

Yes a builtin var looks better. BAKE_LOCAL_PLATFORM lgty?