Add support for cross-compiled extensions

[danielpclark]

I'll be adding thermite to the faster_path project soon. I was wondering about cross-compile support with Rust. Here's a list of Rust's target systems they support:

rustc --print target-list | pr -tw100 --columns 3
aarch64-linux-android		 i686-unknown-freebsd		  thumbv6m-none-eabi
aarch64-unknown-freebsd		 i686-unknown-haiku		  thumbv7em-none-eabi
aarch64-unknown-fuchsia		 i686-unknown-linux-gnu		  thumbv7em-none-eabihf
aarch64-unknown-linux-gnu	 i686-unknown-linux-musl	  thumbv7m-none-eabi
arm-linux-androideabi		 i686-unknown-netbsd		  wasm32-unknown-emscripten
arm-unknown-linux-gnueabi	 i686-unknown-openbsd		  x86_64-apple-darwin
arm-unknown-linux-gnueabihf	 le32-unknown-nacl		  x86_64-pc-windows-gnu
arm-unknown-linux-musleabi	 mips-unknown-linux-gnu		  x86_64-pc-windows-msvc
arm-unknown-linux-musleabihf	 mips-unknown-linux-musl	  x86_64-rumprun-netbsd
armv5te-unknown-linux-gnueabi	 mips-unknown-linux-uclibc	  x86_64-sun-solaris
armv7-linux-androideabi		 mips64-unknown-linux-gnuabi64	  x86_64-unknown-bitrig
armv7-unknown-linux-gnueabihf	 mips64el-unknown-linux-gnuabi64  x86_64-unknown-dragonfly
armv7-unknown-linux-musleabihf	 mipsel-unknown-linux-gnu	  x86_64-unknown-freebsd
asmjs-unknown-emscripten	 mipsel-unknown-linux-musl	  x86_64-unknown-fuchsia
i586-pc-windows-msvc		 mipsel-unknown-linux-uclibc	  x86_64-unknown-haiku
i586-unknown-linux-gnu		 powerpc-unknown-linux-gnu	  x86_64-unknown-linux-gnu
i686-apple-darwin		 powerpc64-unknown-linux-gnu	  x86_64-unknown-linux-musl
i686-linux-android		 powerpc64le-unknown-linux-gnu	  x86_64-unknown-netbsd
i686-pc-windows-gnu		 s390x-unknown-linux-gnu	  x86_64-unknown-openbsd
i686-pc-windows-msvc		 sparc64-unknown-linux-gnu	  x86_64-unknown-redox
i686-unknown-dragonfly		 sparc64-unknown-netbsd

I was wondering if it was possible for this to have these made available through the Github Release system?

Also if checksums are too difficult at the moment how about just signing it with GPG. I'm okay with creating a new Github account just for TravisCI to GPG sign package releases.

[malept]

This should be possible. The caveat here is that Travis will obviously not have binaries for any of those Rubies, so you'd have to build them yourself and host them somewhere to avoid incurring the cost of building Ruby each time CI runs.

I would suggest doing Windows builds on Windows (AppVeyor CI), though. (With the mingw ABI Rust, because I'm not aware of any builds that use MSVC.)

I would be happy to review a design and/or PR for this. Otherwise, I don't know when I'd get around to this, because it's not something I immediately need.

[stereobooster]

GPG not recommended per RubyGems guides. There is discussion for this.

[malept]

FYI, GPG signing (and checksums) would be for the native extension, not the gem. They are separate.

[stereobooster]

Ah I see. It seems like doubling gem download system:

1. Binary gems (which can be signed)
2. Gem with Thermite + compiled binary files (which can be signed)

Though not sure if it is bad or good

See also:

• Rustup and validation of gpg signatures
• Rust builds on Travis
• crates.io + TUF

[malept]

I'm aware of TUF.

The use of GPG for Thermite would be so that I don't have to write checksum code myself, not primarily for "trust". Using the "trust" part of GPG would have to be a decision on a per-consumer-of-Thermite-project basis. The downside to GPG support is that it's a gigantic pain to deal with cross-platform, particularly when you're trying to use it as an API. That downside is why I'm generally not inclined to do it, and not for the "packages shouldn't be GPG signed" reason.

[danielpclark]

From the one who created the information at the above "cross-compile" link he also created a multi system cross-compiler for Rust that also works with CI (for compilation and testing) by using Docker. See the crate: cross ... using this method would likely mean spinning up a separate CI cycle for each OS to be generated. It boasts of "zero setup"