aya-build: try to build when rustup is not found

[famfo]

In some environments, rustup is not availible but cargo and its targets are. This changes aya-build to try to continue building if rustup is not found, even with stable Rust. If the Rust channel differs from the selected toolchain, the user will be warned but a build will still be attempted.

Fixes: #1329

---

This change is 

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	dc12998
🔍 Latest deploy log	https://app.netlify.com/projects/aya-rs-docs/deploys/69778b07743d27000879bb14
😎 Deploy Preview	https://deploy-preview-1439--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[famfo]

If desired, I'd be happy to write an additional build-test for this.

[famfo]

Should I include the changes from cargo xtask public-api --bless in the commit?

[tamird]

Yes

[tamird]

@tamird reviewed all commit messages and made 6 comments.
Reviewable status: 0 of 4 files reviewed, 6 unresolved discussions (waiting on @famfo).

---

aya-build/src/lib.rs line 69 at r1 (raw file):

    let target = format!("{target}-unknown-none");

    let has_rustup = which("rustup").is_ok();

instead of using is_ok here, match on the value below (use the absolute path as input to Command::new)

---

aya-build/src/lib.rs line 92 at r1 (raw file):

                "build",
                "--package",
                name,

these are repeated in the else branch

Code quote:

                "build",
                "--package",
                name,

---

aya-build/src/lib.rs line 99 at r1 (raw file):

            cmd
        } else {
            let channel = rustc_version::version_meta()?.channel;

why are we calling this in a loop?

---

aya-build/src/lib.rs line 100 at r1 (raw file):

        } else {
            let channel = rustc_version::version_meta()?.channel;
            if toolchain != channel {

yoda condition, should be channel != toolchain

---

aya-build/src/lib.rs line 102 at r1 (raw file):

            if toolchain != channel {
                println!(
                    "cargo:warning=rustup was not found and the selected toolchain ({}) differs from the toolchain currently in use ({channel:?}), attempting to build anyways",

anyways isn't a word

---

aya-build/src/lib.rs line 252 at r1 (raw file):

        self == &Self::Nightly && other == &rustc_version::Channel::Nightly
    }
}

please remove this and just do it inline, this is more confusing than it's worth

Code quote:

impl PartialEq<rustc_version::Channel> for Toolchain<'_> {
    fn eq(&self, other: &rustc_version::Channel) -> bool {
        self == &Self::Nightly && other == &rustc_version::Channel::Nightly
    }
}

[tamird]

@tamird made 1 comment.
Reviewable status: 0 of 4 files reviewed, 7 unresolved discussions (waiting on @famfo).

---

aya-build/src/lib.rs line 222 at r3 (raw file):

/// The toolchain to use for building eBPF programs.
#[derive(Default, PartialEq)]

revert plz, then you can remove the API changes

[famfo]

aya-build/src/lib.rs line 222 at r3 (raw file):

/// The toolchain to use for building eBPF programs.
#[derive(Default, PartialEq)]

revert plz, then you can remove the API changes

That would complicate the toolchain check to an if let or string comparison, which one do you prefer?

[tamird]

@tamird made 1 comment.
Reviewable status: 0 of 4 files reviewed, 7 unresolved discussions (waiting on @famfo).

---

aya-build/src/lib.rs line 222 at r3 (raw file):

Previously, famfo (famfo) wrote…

That would complicate the toolchain check to an if let or string comparison, which one do you prefer?

Why can't you use matches!(foo, Toolchain::Nightly)?

[vadorovsky]

Is your use case packaging or working with custom toolchains build from source (but without using rustup)? If so, I think a better way would be providing a way to just disable aya-build and let the package manifests perform the build of eBPF crate manually, like:

# Build eBPF crate.
cargo build --target bpfel-unknown-none -p foo-ebpf
# Build user-space crate with aya-build disabled.
AYA_BUILD_DISABLE=1 cargo build -p foo 

The caller would have full control over which cargo toolchain is called and with which flags. I've been voicing that idea multiple times, I guess I need to finally send a PR.

I'm worried that if we start customizing aya-build for different use cases, we will end up writing a complex build system and spending maintenance effort on users reporting different issues on different configurations. I would prefer aya-build to stay small and focus purely on local development with rustup and nightly, where it "just works" and is convenient for 99% developers. Using different toolchains is where complexity starts and IMO it's better to be not opinionated.

[famfo]

I am not using rustup to manage my toolchains, completely disabling aya-build would be annoying as well because I'd have to write a custom build script again.

[vadorovsky]

OK, your PR is small enough that I'm fine with it (after rebase)

[tamird]

@tamird reviewed 4 files and all commit messages, made 2 comments, and resolved 7 discussions.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @famfo).

---

aya-build/src/lib.rs line 71 at r4 (raw file):

    let rustup_path = which("rustup");
    let rustc_channel = rustc_version::version_meta()?.channel;

We don't need to do this if rustup is on the PATH, right? In other words, this should be a lazy thing declared up here but called in the else branch below.

---

aya-build/src/lib.rs line 86 at r4 (raw file):

        println!("cargo:rerun-if-changed={root_dir}");

        let mut cmd = if let Ok(path) = &rustup_path {

in the case that which failed we should emit the error as a warning. as above, we should do that only once.

[famfo]

We don't need to do this if rustup is on the PATH, right? In other words, this should be a lazy thing declared up here but called in the else branch below.

That would either require some Option or executing it in every loop, not sure if that is much better.

[tamird]

I pushed a commit with what I had in mind. How does it look to you?

[SuperSandro2000]

I did not try it but looks promising. Thanks!

[tamird]

I did not try it but looks promising. Thanks!

Would be great if you could try it :)

[famfo]

I pushed a commit with what I had in mind. How does it look to you?

Ah, I get the idea now, lost the bigger picture slightly. Not sure when I have time to clean up the code properly and retest in the next few days though.

[tamird]

What cleanup is needed? Can you test as-is?

[famfo]

Yes, it does work as-is.

[tamird]

@codex review

@tamird reviewed 2 files and all commit messages, made 1 comment, and resolved 2 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @famfo).

[Copilot]

Pull request overview

This PR modifies aya-build to support environments where rustup is unavailable by attempting to build with the current toolchain instead of requiring rustup to manage toolchain selection. The change makes the build process more flexible while maintaining compatibility with existing rustup-based workflows.

Changes:

• Adds dynamic detection of rustup availability and falls back to using cargo directly when rustup is not found
• Conditionally applies -Z build-std=core only on nightly toolchains to avoid build failures on stable
• Introduces rustc_version and which crates as dependencies to enable toolchain detection

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
aya-build/src/lib.rs	Implements rustup detection logic, command builder abstraction, and conditional nightly-only flags
aya-build/Cargo.toml	Adds rustc_version and which dependencies
Cargo.toml	Adds rustc_version to workspace dependencies

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When rustup is unavailable and the user specified a nightly toolchain, but the current toolchain is stable, this code will skip the -Z build-std=core flag silently. Consider warning the user when the detected channel doesn't match the requested toolchain parameter to make this mismatch explicit.

Suggested change

	cmd.args(["-Z", "build-std=core"]);
	cmd.args(["-Z", "build-std=core"]);
	} else {
	// If the user requested a nightly toolchain but the detected channel is not nightly,
	// and rustup is unavailable, warn that we're skipping the `-Z build-std=core` flag.
	if let Ok(toolchain) = env::var("RUSTUP_TOOLCHAIN") {
	let requested_is_nightly = toolchain.contains("nightly");
	if requested_is_nightly && channel != Channel::Nightly {
	let rustup_unavailable = Command::new("rustup")
	.arg("--version")
	.stdout(Stdio::null())
	.stderr(Stdio::null())
	.status()
	.is_err();
	if rustup_unavailable {
	println!(
	"cargo:warning=Requested nightly toolchain `{}` but detected rustc channel `{:?}` and `rustup` is not available; skipping `-Z build-std=core`.",
	toolchain, channel
	);
	}
	}
	}

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".