Create rust-toolchain.toml

[JonahPlusPlus]

Just to make it easier to run the repo, I added a toolchain file to setup using nightly and rust-src, so people don't have to worry about doing it manually.

[JonahPlusPlus]

Hmm, makes the tests fail since it prevents installing the stable channel. Is there a point to installing stable if the project needs nightly to work?

[GabrielMajeri]

@JonahPlusPlus We've switched to using stable Rust for compiling the xtask task runner in CI in #399. The reason was that the nightly toolchain had a bug with compiling fatfs, a dependency of xtask.

That being said, xtask should automatically switch to the nightly toolchain when compiling the crate. Doesn't this eliminate the need for a rust-toolchain.toml file?

[JonahPlusPlus]

@GabrielMajeri Hmm, I don't think so, I tried using xtask to build and it failed (complained about missing stuff), I had to override to nightly and add the component manually.

[GabrielMajeri]

That's weird. @nicholasbishop is this expected behavior, or a possible bug in cargo xtask?

[nicholasbishop]

Does sound like a possible xtask bug. @JonahPlusPlus could you post the error you get (with the nightly override removed)?

[JonahPlusPlus]

Hmmm, actually, I guess the problem was with me running the cargo build command instead of cargo xtask (in respect to why I needed the rust-toolchain.toml), since that creates an error when I run it without any overrides. I must have conflated the two. Still, the xtask command fails, whether I am using nightly or stable:

error[E0433]: failed to resolve: could not find `sys` in `nix`
 --> xtask\src\qemu.rs:8:10
  |
8 | use nix::sys::stat::Mode;
  |          ^^^ could not find `sys` in `nix`

error[E0432]: unresolved import `nix::unistd`
 --> xtask\src\qemu.rs:9:10
  |
9 | use nix::unistd::mkfifo;
  |          ^^^^^^ could not find `unistd` in `nix`

I guess you guys use Linux? I am running Windows with WSL, but since you can build UEFI apps without xtask (cargo +nightly build --target x86_64-unknown-uefi), I have just been using Windows for programming my UEFI app.

[nicholasbishop]

Interesting! I am indeed on Linux, and not very familiar with WSL. The error messages are surprising to me though; I would have assumed nix would more or less work without issue under WSL. And I'm especially confused that the entire sys and unistd modules would be missing, because as far as I can tell those modules are not conditional in any way. Many of the nix modules are gated behind a feature flag or target triple, but it doesn't look like sys or unistd are gated:

• https://github.com/nix-rust/nix/blob/v0.24.1/src/lib.rs#L141
• https://github.com/nix-rust/nix/blob/v0.24.1/src/lib.rs#L158

[GabrielMajeri]

@nicholasbishop I think I've figured out why nix cannot be used on Windows. The root lib.rs file for the crate has a #![cfg(unix)] line right at the top, which would make the crate appear completely empty and devoid of members on non-Unix platforms.

[nicholasbishop]

Ah, that makes sense for how those errors could appear, thanks :)

I just set up a quick test with WSL2 on a Windows machine and was able to run cargo xtask build without issue. @JonahPlusPlus I'm wondering if maybe you're on WSL1 and that could explain the difference?

[JonahPlusPlus]

@nicholasbishop I guess I should clarify: I have WSL 2, but I was building on Windows, not WSL. If I run xtask from Debian on WSL, it works fine. You just can't use xtask at all on Windows itself.

Edit:
I only brought up WSL since I used to use it, but since you can go without xtask to build UEFI apps on Windows, I've just been using Windows lately. It's been a while since I last programmed UEFI, but this must have been the reason I stopped using xtask and just used cargo build.

[JonahPlusPlus]

On that note however, why are you guys using xtask to build when cargo provides targets for the same architectures? It seems cargo build --target machine-unknown-uefi works fine on both Windows and Linux, why not use that instead with a rust-toolchain.toml and .cargo/config.toml file? You only need to specify the necessary components in that config file.

[nicholasbishop]

Edit: I only brought up WSL since I used to use it, but since you can go without xtask to build UEFI apps on Windows, I've just been using Windows lately. It's been a while since I last programmed UEFI, but this must have been the reason I stopped using xtask and just used cargo build.

Thanks, makes sense. Assuming that only the qemu part of xtask is causing problems, perhaps we can use some conditional compilation there to make the rest of xtask work on Windows.

On that note however, why are you guys using xtask to build when cargo provides targets for the same architectures?

The background there is that we need tools to run a variety of commands, not just the build command. Running the qemu tests is the most notable one; it takes a fair amount of code to set that all that up. Originally this code was written in Python, but I rewrote it in Rust (to get all the usual nice checks that Rust provides). Since that xtask code needs to run under the host's target, rather than one of the UEFI targets, we can't have a single cargo.toml config for everything. And in fact even without the xtask code, we need to build for multiple targets since there are three UEFI targets we support (ia32, x86_64, and aarch64).

[JonahPlusPlus]

The background there is that we need tools to run a variety of commands, not just the build command. Running the qemu tests is the most notable one; it takes a fair amount of code to set that all that up. Originally this code was written in Python, but I rewrote it in Rust (to get all the usual nice checks that Rust provides).

Ah, makes sense. What I did for my project was use cargo make, using duckscript to create the output folder and then just run qemu as a command. Granted my bootloader doesn't work (I can't find any resources for how the boot process works in UEFI without some legacy BIOS code getting in the way), but this structure is nicely cross platform.

I'm not sure how cargo make handles arguments, but you probably could get it to compile to multiple platforms by passing a target argument or by making specific commands for each platform.

[nicholasbishop]

I've put up a PR that hopefully addresses the Windows compilation issue.