Allow AOT executables to be cross-compiled

[nex3]

Currently application snapshots (as described here) can only be compiled for the architecture of the machine doing the compilation. This makes releasing cross-platform apps using these snapshots much more difficult, requiring multiple machines (including at least one physical machine, since OS X isn't virtualizable) to compile for all platforms.

It seems that the compilation process could do the initial run on the current platform, but then preserve the profiling information and use it to cross-compile the result to other platforms.

---

Admin note: This is being implemented gradually via new --target-os and --target-arch flags on dart compile exe.

The current status is as follows:

Developer OS (OS where the compiler is run)	Target OS (OS where the exe is run)	Status
macOS	macOS	Supported in 2.15 and later
macOS	Windows	Not supported
macOS	Linux	Supported in 3.8 and later
Windows	macOS	Not supported
Windows	Windows	Supported in 2.15 and later
Windows	Linux	Supported in 3.8 and later
Linux	macOS	Not supported
Linux	Windows	Not supported
Linux	Linux	Supported in 2.15 and later

[rmacnak-google]

App snapshots are tied to the target ABI of the VM, not the host OS and not the host ABI. If you create an app snapshot using an IA32 VM, you can run the same snapshot on Windows, Mac or Linux. If you create an app snapshot using an X64 VM on Mac or Linux, you run it on the other (they share the sysv ABI), but not Windows (which has its own ABI). If you create an app snapshot using a SIMARM VM on your desktop, you can run it with an ARM VM on, say, an Android device (this is how Flutter works).

We will not produce VMs that target multiple ABIs. The assumption of a single target ABI as a build-time decision is quite deep in the VM.

[nex3]

I want to push back strongly on this. Startup performance is very important for providing my users with a good experience, and the Dart VM's startup performance without using application snapshots compares poorly to just about any other language (including Ruby, whose Sass implementation we're in the process of deprecating because of performance issues).

Other languages are able to do this. Easy cross-compilation is a major reason that Go is so popular for writing command-line tools, and if Dart provided it with similar ease it would make the server-side Dart world very compelling. But without it, Dart users are forced to deal with sub-par performance when they could easily get performance and portability with another language.

[nex3]

Ping... efficient startup speeds across all platforms are a very important customer feature.

[nex3]

I haven't received any response, so I'm re-opening this. It's a pressing customer issue.