Potentially switch from cargo-xbuild to build-std

[al3xtjames]

Now that rust-lang/rust#77284 is merged, we no longer need cargo-xbuild to cross-compile.

We can now use:

cargo +nightly build -Zbuild-std=core,compiler_builtins,alloc -Zbuild-std-features=compiler-builtins-mem --target x86_64-unknown-uefi --features examples --examples

instead of:

cargo +nightly xbuild --target x86_64-unknown-uefi --features examples --examples

We can also add the build-std flags to .cargo/config.toml and use cargo +nightly build --target x86_64-unknown-uefi --features examples --examples instead:

[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
build-std-features = ["compiler-builtins-mem"]

[dvdhrm]

Very nice! Are these command-line flags still tight to unstable/nightly? Or is +nightly only required because there has not been any release with those commits, yet?

[al3xtjames]

I believe build-std is still unstable.

[dvdhrm]

I now added -Zbuild-std instructions to README.md and changed the CI to run it alongside cargo-xbuild. Sadly, it still requires a nightly compiler even though we have no other dependencies on nightly. It seems there is progress, though. Lets hope it is stabilized some time next year.

Thanks a lot for digging this out and collecting the information. It works perfectly for me, even though the documentation of the feature sounds like it is all fragile and broken. Lets see whether it works out.

Regarding .cargo/config, I did not think much about it. If you feel strongly about it, feel free to open a PR. However, if I understand correctly, it would not be tied to the crate at all, hence any dependent crates would require the same configuration, right? In this case, I think I prefer being explicit, at least as long as this is an unstable feature. I often favor a Makefile with trivial targets (or a python/shell script, fwiw) over configuration, as it hides things less and is more introspectable.