Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/houseabsolute/actions-rust-cross below:

houseabsolute/actions-rust-cross: GitHub Action to compile Rust with cross

This action lets you easily cross-compile Rust projects using cross.

Here's a simplified example from the test and release workflow for my tool ubi:

jobs:
  release:
    name: Release - ${{ matrix.platform.os-name }}
    strategy:
      matrix:
        platform:
          - os-name: FreeBSD-x86_64
            runs-on: ubuntu-24.04
            target: x86_64-unknown-freebsd

          - os-name: Linux-x86_64
            runs-on: ubuntu-24.04
            target: x86_64-unknown-linux-musl

          - os-name: Linux-aarch64
            runs-on: ubuntu-24.04
            target: aarch64-unknown-linux-musl

          - os-name: Linux-riscv64
            runs-on: ubuntu-24.04
            target: riscv64gc-unknown-linux-gnu

          - os-name: Windows-x86_64
            runs-on: windows-latest
            target: x86_64-pc-windows-msvc

          - os-name: macOS-x86_64
            runs-on: macOS-latest
            target: x86_64-apple-darwin

          # more targets here ...

    runs-on: ${{ matrix.platform.runs-on }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build binary
        uses: houseabsolute/actions-rust-cross@v1
        with:
          command: build
          target: ${{ matrix.platform.target }}
          args: "--locked --release"
          strip: true
      - name: Publish artifacts and release
        uses: houseabsolute/actions-rust-release@v0
        with:
          executable-name: ubi
          target: ${{ matrix.platform.target }}

Note that for Linux or BSD targets, you should always set the runs-on key to a Linux x86-64 architecture runner.

If you only want to do native ARM compilation, for example using the ubuntu-24.04-arm runner, then there's no need to use this action. However, if you want to compile for many platforms, including Linux ARM, using this action will simplify your config. This action is only tested on Ubuntu x86-64, Windows, and macOS runners.

This action takes the following parameters:

By default, cross passes most rust-related environment variables through when it runs cargo in a Docker image. This means you can simply set an env key in the workflow step that uses this action.

- name: Run build command
  uses: houseabsolute/actions-rust-cross@v1
  env:
    CARGO_LOG: debug
    RUSTFLAGS: "-g"
  with:
    command: build

If you want to pass other environment variables through, you will need to configure cross to do see. See the cross docs for more details.

Under the hood, this action will compile your binaries with either cargo or cross, depending on the host machine and target. For Linux builds, it will always use cross except for builds targeting an x86 architecture like x86_64 or i686.

On Windows and macOS, it's possible to compile for all supported targets out of the box, so cross will not be used on those platforms.

If it needs to install cross, it will install the latest version by downloading a release using my tool ubi. This is much faster than using cargo to build cross.

When compiling on Windows, it will do so in a Powershell environment, which can matter in some corner cases, like compiling the openssl crate with the vendored feature.

When running cargo on a Linux system, it will also include the output of running lsb_release --short --description in the cache key. This is important for crates that link against system libraries. If those library versions change across OS versions (e.g. Ubuntu 20.04 to 22.04), then the cache will be broken for these cases.

When running cross, the hash of the cross binary will be included in the cache key. This is done because the Docker images that cross uses can change when cross is updated. We want to make sure that we do not re-use the cache across changes when these images change.

Finally, it will run strip to strip the binaries it builds if the strip parameter is true. This is only possible for builds that are not done via cross. In addition, Windows builds for aarch64 cannot be stripped either.

By default, this action will use the Swatinem/rust-cache@v2 action to cache compiled dependencies for a crate. Note that per the documentation for the rust-cache action, it has fairly limited value for crates without a Cargo.lock file. The key parameter passed to this action will always include the value of the target input. If you specify a key parameter in rust-cache-parameters, then the target input will be appended to the value you specify.

In my testing, it seemed like in some cases restoring the cache would delete existing files in a target directory. This manifested with this sequence of actions:

1. Run actions-rust-cross to compile a crate in a top-level directory.
2. Run actions-rust-cross to compile a crate in a subdirectory.

After step 2, the compiled binaries from step 1 were no longer present, sometimes. I'm not sure exactly what's going on here, but my recommendation is to structure your workflows so that this cannot affect you.

For example, if you have multiple crates, each of which builds a binary you want to release, then you can avoid this issue by structuring your workflow as follows:

1. Run actions-rust-cross to compile crate A.
2. Run the release steps for crate A.
3. Run actions-rust-cross to compile crate B.
4. Run the release steps for crate B.

When structured this way, it does not matter if the output of crate A is deleted in step 3.

In theory, this should work, and this action does implement some of the necessary work for this. However, there are a couple issues with this:

1. As of 2025-02-17, the cross project does not publish Linux ARM binary releases. That means that in order to use cross on a Linux ARM runner as part of this action, you must set cross-version to a more recent commit from the cross repo.
2. There is a bug in cross that means you must use a custom Docker image when cross-compiling from a Linux ARM runner. See this other cross issue for more details.

The code in this repo is linted and tidied with precious. This repo contains a mise.toml file. Mise is a tool for managing dev tools with per-repo configuration. You can install mise and use it to run precious as follows:

# Installs mise
curl https://mise.run | sh
# Installs precious and other dev tools
mise install

Once this is done, you can run precious via mise:

# Lints all code
mise exec -- precious lint -a
# Tidies all code
mise exec -- precious tidy -a

If you want to use mise for other projects, see its documentation for more details on how you can configure your shell to always activate mise.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4