On Thu, Aug 8, 2024 at 9:58 AM Manos Pitsidianakis
<manos.pitsidiana...@linaro.org> wrote:
>
> On Thu, 08 Aug 2024 09:10, Paolo Bonzini <pbonz...@redhat.com> wrote:
> >On 8/4/24 23:04, Manos Pitsidianakis wrote:
> >> Changes
> >> =======
> >>
> >> - Setting MSRV to 1.77.0:
> >> * cstr crate MSRV is 1.64, which is more recent than Debian bookworm
> >> (1.63.0) <https://github.com/upsuper/cstr/blob/master/Cargo.toml>
> >>
> >> * pl011's dependencies (mostly proc-macro2) don't support 1.63.0
> >
> >proc-macro2 is listed as supporting 1.56.0, and in general I don't see
> >particularly high MSRVs for any of your dependencies.
>
> The issue was with transitive deps, proc-macro-error crates etc stopped
> compiling when lowering the version, which means we'd have to patch the
> dependency's dependency to see if that'd work; otherwise, yes!
Ah, I see now - you have to set the right cfg for proc-macro2 to
compile with 1.63.0. Normally (including with "method = cargo") they
are detected by build.rs:
if rustc < 66 {
println!("cargo:rustc-cfg=no_source_text");
}
if rustc < 79 {
println!("cargo:rustc-cfg=no_literal_byte_character");
println!("cargo:rustc-cfg=no_literal_c_string");
}
(Meson's support for build.rs is very limited, but it does handle some
simple cases and parses rustc-cfg from the output).
And bilge-impl uses let...else; we can patch it locally via the .wrap
file's "diff_files" entry. Not great, but it's good that we can do it
and that we have an example for similar issues in the future.
I updated my rust-for-manos branch with these discoveries. Of course
it doesn't compile with 1.63.0 but it does at least configure
successfully with
../configure --rustc=$(rustup +1.63.0 which rustc) --enable-rust
and build the subprojects' rlibs.
> >The automatic Cargo.toml support in Meson is promising [...]
> >My suggestion is to name our manually-managed subprojects with
> >the same convention that is used by "method = cargo" in Meson 1.5.0+,
> >i.e. name-APIVER-rs:
>
> Yes that makes sense!
Good!
> >- for patch 2, the only issue is that you are specifying
> >--no-include-path-detection and that breaks for me on Fedora. I have
> >not finished testing but it seems that it's enough to remove that line.
>
> I had added that when trying to debug bindgen failing to find headers
> when dependencies were added (e.g. linux io_uring) or when compiling on
> macos, let's test again to see if it's indeed unnecessary!
Ok, crossing fingers.
Paolo
