proposal: add fyne cross command

[lucor]

This PR introduces a new fyne cross command that brings cross-compilation directly into the Fyne tools, replacing the need for fyne-cross while using containerized build environments.
If adopted, this will effectively deprecate the standalone fyne-cross tool.

Requires: https://github.com/lucor/fyne-cross-images/pull/68

Notable Changes

• Build-only focus: Cross-compilation only; packaging remains with fyne package.
  This also means the Docker images do not need to include Fyne tools anymore.
• Integrated into Fyne tools as a new fyne cross command.
• Docker images do not require fixuid.
• S3 upload not yet implemented (requires a decision).
• Go 1.24+ required due to the Docker client dependency.

Note: at writing time only Linux and Windows have been ported.

Open Questions

• Is Go 1.24+ acceptable for fyne-tools?
• Should we explore alternative approaches to support both Go 1.19 and 1.24?
• Should S3 upload be a separate command?

Testing

Build images:

Requires container images from:
https://github.com/lucor/fyne-cross-images (branch feat/cross)

make linux
make windows

Cross compile

# Linux AMD64
fyne cross --target linux/amd64 --image fyneio/fyne-cross-images:tools-dev-linux ./cmd/myapp

# Windows AMD64 release build
fyne cross --target windows/amd64 --image fyneio/fyne-cross-images:tools-dev-windows --release -o myapp.exe

AI Disclosure: AI was used to generate many tests and assist with this work. Everything has been manually reviewed.

[andydotxyz]

Build-only focus: Cross-compilation only; packaging remains with fyne package.

This is cool - but does this mean that cross-platform package now uses cross by default, or that we need a new parameter to the package command to instruct it to use cross instead of build in preparation?

[lucor]

The idea with this first version is to have a dedicated command for cross-building, leaving packaging to the fyne tool. This should make testing and porting easier.

For packaging, fyne package <binary> should still be used.

If the new flags are acceptable, we could integrate this directly into package or build later.

At the moment the following flags are used:

NAME:
   fyne cross - Cross-compile Fyne applications using containers

USAGE:
   fyne cross [command options] [arguments...]

OPTIONS:
   --target value, --os value           set operating system to target (android, android/arm, android/arm64, android/amd64, android/386, darwin, freebsd, ios, linux, netbsd, openbsd, windows)
   --src value, --source-dir value      set directory to package, if executable is not set
   --release                            enable installation in release mode, disable debug, etc (default: false)
   --output value, -o value             specify name for the output file (default: based on current directory)
   --image value                        specify custom container image (overrides default)
   --pull                               pull latest container image (default: false)
   --cache-dir value                    directory for Go build and Zig compiler caches (default: /Users/lucor/Library/Caches/fyne-tools)
   --no-cache                           disable Go build and Zig compiler caching (default: false)
   --ldflags value [ --ldflags value ]  specify linker flags to pass to go build (can be used multiple times)
   --tags value [ --tags value ]        specify build tags (can be used multiple times)
   --verbose, -v                        show details when running (default: false)
   --help, -h                           show help```

[andydotxyz]

The idea with this first version is to have a dedicated command for cross-building, leaving packaging to the fyne tool. This should make testing and porting easier.

For packaging, fyne package should still be used.

Sounds like a good first step, thanks. Perhaps it should hint that packaging is not complete (as it would have been for fyne-cross before).
Maybe a message that includes the hint that "fyne package --os targetOS --executable fyne-cross/outPath" completes the package step?

[sdassow]

Nice, I like where this is going.

• Is Go 1.24+ acceptable for fyne-tools?
• Should we explore alternative approaches to support both Go 1.19 and 1.24?

Should be the same as the main Fyne repo I think.
In this particular case, can we make the cross command conditional on the Go version and leave the decision to the compiler (version)?

• Should S3 upload be a separate command?

That does sound more like general file distribution, which makes me wonder if a vendor/protocol specific command makes sense as part of our CLI/API or if it should be a type of a broader upload command or similar.