aya-build should not require rustup or a nightly compiler

[SuperSandro2000]

When packaging things for NixOS, there is no rustup in the build environment and it cannot be simply added because it needs networking to properly function. Nixpkgs provides a rust compiler and cargo with crates prefetched in an earlier step and hashed.
It would make things a lot easier if no patching would be required to remove rustup and nightly requirements around here https://github.com/aya-rs/aya/blob/main/aya-build/src/lib.rs#L62 .
A build command constructed like the following works for us without any issues.

    let mut cmd = Command::new("cargo");
    cmd.args([
        "build",
        "--bins",
        "--message-format=json",
        "--release",
        "--target",
        &target,
    ]);

[vadorovsky]

I think the solution for OS distributions and packages is to actually avoid using aya-build entirely and let the package maintainers do everything by hand, so they have full control over how and with which toolchain everything is built. Perhaps we could add some environment variable to skip the execution of the most of build.rs body in the main crate.

Do you enable the BPF targets (bpfel-unknown-none and bpfeb-unknown-none) in stable Rust toolchains in NixOS?

I'm trying to help out Gentoo folks in that topic already. It's far away from done, but the first step I proposed is adding the BPF targets: gentoo/gentoo#42060. I think the same needs to be done in NixOS.

After that, bpf-linker can be installed with support of the specific LLVM version, down to 19. If you want to use LLVM 20 (used in the latest stable Rust), you can do so with these feature flags:

cargo build --release --no-default-features --features llvm-20

Then you can build the eBPF crate separately:

cargo build --target bpfel-unknown-none -p my-ebpf

I didn't document any of these yet, since I literally added the support of stable Rust and LLVM versions in bpf-linker literally a week ago, just to play around with this in Gentoo. But given your interest in the same topic, I probably need to wrap up that faster and document stuff.

[SuperSandro2000]

Do you enable the BPF targets (bpfel-unknown-none and bpfeb-unknown-none) in stable Rust toolchains in NixOS?

Yep, https://github.com/NixOS/nixpkgs/blob/a421ac6595024edcfbb1ef950a3712b89161c359/pkgs/development/compilers/rust/rustc.nix#L159-L160

After that, bpf-linker can be installed with support of the specific LLVM version, down to 19. If you want to use LLVM 20 (used in the latest stable Rust), you can do so with these feature flags:

cargo build --release --no-default-features --features llvm-20

That should already be available in the build https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/mitmproxy-linux/default.nix#L34 and mitmproxy is checking for that https://github.com/mitmproxy/mitmproxy_rs/blob/main/mitmproxy-linux-ebpf/build.rs

But their build script is hardcoded to call aya-build https://github.com/mitmproxy/mitmproxy_rs/blob/main/mitmproxy-linux/build.rs#L21

and here my understanding of how to properly fix this ends 😅

Until the last update they ran cargo themselves based on some template where we also removed the rust nightly requirement mitmproxy/mitmproxy_rs@504139f#diff-7b932abc48a6031e65e0d04ccc96bddc4b5eb1f198a3f514e534ec08dfb4c7bbL52-L62

[vadorovsky]

Sorry for letting it stale. I think the path forward is to provide an environment variable (AYA_BUILD_SKIP) which will let people that dislike cargo-in-cargo/build.rs (me 🙋 ) and package maintainers to skip it and just do the eBPF build separately.

[tamird]

FWIW I think this issue is not about "not using aya-build" (because that would require inventing a separate build system).

[vadorovsky]

FWIW I think this issue is not about "not using aya-build" (because that would require inventing a separate build system).

Well, Gentoo already removes build.rs of mitmproxy-ebpf, because getting aya-build to work with custom Rust toolchains is just too hard / impossible:

https://github.com/gentoo/gentoo/blob/92336448a860a7f1cae457c9f8b0924b338e7040/net-proxy/mitmproxy-linux/mitmproxy-linux-0.12.7.ebuild#L96-L98

(It still uses -Zbuild-std=core below, but I'm cooking a PR which will remove that as well and use prebuilt BPF sysroot, which is already in the newest Rust packages, making the build fully offline)

The eBPF part (mitmproxy-linux) and user-space part (mitmproxy-rs) are shipped in separate packages, so the dependency is handled by the package manager.

And I think package maintainers from other distros/systems will also prefer doing:

cargo build --target bpfel-unknown-none --release -p xxx-ebpf
AYA_BUILD_SKIP=1 cargo build --release -p xxx

It'd be that simple, no separate build system needed.

On a side, there are developers who prefer inventing a separate build system as well. @pythops is using xtask in his projects. At my job, we use a script. But that's completely separate topic (aya-rs/aya-template#150)