Adding CLI option for cross-compiling on Scala Native

[windymelt]

Is your feature request related to a problem? Please describe.

Scala Native has its cross-compiling feature that is came from clang/LLVM.

https://scala-native.org/en/stable/user/sbt.html#cross-compilation

nativeConfig ~= { _.withTargetTriple("x86_64-apple-macosx10.14.0") }

Though Scala CLI has some CLI options that manipulates Scala Native, there is no option to handle with target triple.

(Scala CLI have --native-target, but it sets artifact type e.g. application / dynamic lib / static lib)

Describe the solution you'd like

Add --native-target-triple to provide target triple info for Scala Native (and clang/LLVM)

Describe alternatives you've considered

We can convert foobar.scala.sc into sbt project, and manually add Scala Native configurations.

Additional context

I tried building native binary via Docker Image (virtuslab/scala-cli), and that's quite easy (I wrote build stage, and copied binary to host or another thin stage). If we have cross-compiling feature, that's awesome build infrastructure for small tool (like Go, Rust).

[bynux-gh]

Commenting to get another set of eyes on this (and to remind myself to see if I can implement it somehow). A quick and easy way to turn a simple script or project into a native binary for a completely different platform would be absolutely invaluable.

For example, I do some volunteer work for a nonprofit make space and would love an easy way to build small tools for their Windows machines from the comfort of my 2-in-1 running an Arch-based system (btw).

This would also be useful for compilation to other architectures; with ARM becoming more popular for basic netbooks and Apple devices, being able to prepare multiple builds with some simple //> using directives could save some amount of time and annoyance for a multitude of use cases.

[Gedochao]

https://scala-native.org/en/stable/user/sbt.html#cross-compilation-using-target-triple
Some more documentation from the Scala Native side.

[WojciechMazur]

I don't think target triple should be supported right now in the CLI and here's why:

Cross-compilation is hard, targetTriple is rather Scala Native power-user setting. For power-users sbt/mill is recommended.

Cross compilation is hard becouse it's not just a single option switch to produce a binary working for different architecture or os. The native compilation requires libraries and include headers (used by glue layer of C sources needed by runtime or libraries) specificlly for that OS/Arch system as these can differ. This can be achived by specifing a custom sysroots containing all required depenencies, but it's still prone to the bugs in configuration.

Scala Native itself has 2 tests for testing cross compilation for linux-arm64 and linux-i386, these require:

1. Dedicated compile/link options to setup correct sysroot
2. Dedicated Docker cotaniners to build missing dependencies from sources with different config for each platform. These are based on https://github.com/dockcross/dockcross providing containers with most of system depenencies built in and accessible via env variable
3. Emulator for given platform to test it in the CI, also provided by dockcross or qemu.

Still all of this can very easily break, and we're still talking about same system, but different arch scenario. Cross building for different OS is untested and in most cases impossible.

tl;dr
If you need cross compilation for Scala Native setup a dedicated CI job to build it natively - it's faster and more reliable.
withTargetTriple should be treated as experimental power user flag, at least for now. If cross compilation support in SN would improve, then it can be reconsidered.

We can improve 1 thing on the Scala Native side - we can add detection of target triple to be used based on passed compile-options. This way power users of Scala CLI can specify LLVM flag --target=<target-triple> and it would be picked to enable target specific settings