Enhance distribution channel

[chrysn]

Getting c2rust is, by Rust standards, comparatively hard to install, as it requires a particular nightly Rust, and even then, occasional workarounds.

If at some point the particular-nightly dependency is dropped, not only would cargo install work, but also all optimizations based on it (like cargo-quickinstall) would work.

Until then, could you establish release builds that are downloadable at least for the most common platform(s)? In particular, not having to build c2rust inside the CI of any project that needs it would be quite helpful.

[thedataking]

Going from nighty to the stable channel is a long ways off in part because the Rust folks are gating compiler internals that we depend critically on behind the unstable rustc_private feature flag. See rust-lang/rust#27812

I agree that having downloadable release builds is worth looking into. Thanks for suggesting this to us! Happy to hear what platforms people are most interested in.

[chrysn]

This is becoming more acute now that in RIOT-OS/riotdocker#141 it's adding another half-hour-or-so to the RIOT build system. (For this particular use case, working from the built docker files may be a simpler shortcut.)

AIU there are already some builds done in CI, but a) they're debug builds, and b) the builds don't become part of the artifacts.

Would it be sufficient to set the build to release (again, probably, as the first cargo build in the .travis script is for running the tests, and we want debug_assert, wraps etc to trigger there), and make target/release/c2rust available as an artifact? (Not sure how that'd be done, as the build happens in Travis but the artifacts that are here now come from .github/workflows/internal-testsuite.yml). The result would not be fully statically linked, but only depend on the libc and it may be sufficient to assume that most systems these days have a libc compatible with the Bionic one used in CI.

[chrysn]

Looks like at least for the concrete use case at hand indeed the Docker images are good enough -- if they are recent. @thedataking, could you upload the ubuntu-bionic-latest image again? It seems this doesn't happen automatically when a new C2Rust version is released: https://hub.docker.com/r/immunant/c2rust/tags?page=1&ordering=last_updated shows the latest to be from April 2020.

[chrysn]

I've mistaken the immunant/c2rust images for containers that include c2rust, whereas they actually contain the build environment for c2rust (and thus doesn't need an update for the 2020-04 version can still compile c2rust).

For the RIOT use case we'll probably build an own image that contains pending PRs (#302, #311), but the script is really easy (especially in the form I tested earlier before pulling in the PR branch):

FROM immunant/c2rust:ubuntu-bionic-latest as c2rust
RUN cargo install --locked c2rust --root /usr

I'm not sure how useful this is on its own, given it has an "ancient" Rust version installed; current usage in the RIOT PR is as

FROM our/c2rust-built as c2rust
FROM our/regular-base
... install a lot of stuff, including nightly rust for the target systems
COPY --from=c2rust /usr/bin/c2rust /usr/bin/c2rust-refactor /usr/bin/c2rust-transpile /usr/bin

[zamazan4ik]

I've uploaded the Docker image with already built c2rust binary - https://hub.docker.com/r/zamazan4ik/c2rust-built-ubuntu-bionic-latest

@chrysn maybe will be a good idea at least to mention it somewhere. I think this Docker image can be helpful to someone.
It's just a

FROM immunant/c2rust:ubuntu-bionic-latest as c2rust
RUN cargo install --locked c2rust --root /usr

[chrysn]

For those considering Debian-style packages for c2rust (not likely going to happen in Debian unless it builds on stable, but that doesn't keep anyone from building .deb or hosting files): The branch referenced in RIOT-OS/riotdocker#173 (or its master branch once merged) contains, in its c2rust-built directory, a debian directory with which it is relatively straightforward to build c2rust .deb packages. These are easy to distribute and ensure (using the shlibdeps mechanism) that the required llvm libraries are always present. (It's still also a Docker container built on Ubuntu 20.04 LTS, and the image contains packages for that).

(Anyone looking at this from a Debian PoV: they wouldn't cut it in the archive, among other things because they depend on an unpackaged Rust nightly -- and therefore also don't use dh-cargo, because that appears not to be cut for non-distro rustc versions)

[chrysn]

With 0.16 out this has drastically improved; I'm in the process of updating the referenced Debian package, and somewhere down the road this could become well eligible for inclusion in distributions.

But maybe now this is also becoming less important: rather than installing c2rust as a binary, c2rust-transpile could also be used more like a library, making the dependency visible to cargo at build time rather than requiring the user to explicitly cargo install something beforehand.

[kkysen]

As you noted, this is fixed in 0.16.0. cargo install c2rust and derivatives like cargo quickinstall c2rust now work.

[kkysen]

c2rust-transpile is actually a separate library crate: https://crates.io/crates/c2rust-transpile. It does have a public c2rust_transpile::transpile function, though you have to be careful with that, because clang stores a lot of global data. For example, it often crashes when trying to parallelize c2rust_transpile::transpile within the same process.