Open nicholasbishop opened 3 months ago
Sounds good to me overall!
This differs from the previous approach of putting the binaries directly in the crates.io release. I couldn't find any specific policy about uploading prebuilts on crates.io, but this discussion makes it sound at least discouraged.
Yeah, I wasn't sure about that either. I'm fine with trying a GitHub download instead, but that approach has drawbacks too (network connection required, no longer self-contained, forking more difficult, etc).
Implement functionality in
ovmf-prebuilt
similar to what we have in uefi-rs: https://github.com/rust-osdev/uefi-rs/blob/ccdfb66cd073442e3dc08412a7c18369d906aff7/xtask/src/qemu.rs#L95.
For the crate, we could do the downloading in a build script and place the artifacts in OUT_DIR
. Then we don't need to do any hash checks as the build script is only run on the first compile.
As mentioned in https://github.com/rust-osdev/ovmf-prebuilt/issues/37#issuecomment-1963047858, I'd like to add a library crate here, essentially an upgrade to https://crates.io/crates/ovmf-prebuilt to make it easy to get the new prebuilts.
Filing an issue here to lay out a quick plan:
build-edk2
, containing the code that's currently insrc/
.build-edk2
will not be published.ovmf-prebuilt
package to the workspace. This can start at version 0.2.0 to supersede the currently-published versions.ovmf-prebuilt
similar to what we have in uefi-rs: https://github.com/rust-osdev/uefi-rs/blob/ccdfb66cd073442e3dc08412a7c18369d906aff7/xtask/src/qemu.rs#L95. This differs from the previous approach of putting the binaries directly in the crates.io release. I couldn't find any specific policy about uploading prebuilts on crates.io, but this discussion makes it sound at least discouraged.